トリガーとは？基本とメリット・デメリットを解説

2025.07.29 株式会社システムインテグレータ

データベースオブジェクトの1つ、トリガーはテーブルへのデータ操作をトリガーとして自動的に処理を実行できる仕組みです。監査ログの自動記録や関連データの整合性維持など、業務を効率化しミスを防ぐために多くのシステムで活用されています。しかし、トリガーは乱用するとパフォーマンスや運用に影響を及ぼす可能性もあるため注意が必要です。

本記事では、トリガーの基本から主要DBでの定義例、メリット・デメリットまで詳しく解説します。これからトリガーを使おうと考えている人は、ぜひ本記事をご活用ください。

トリガーの概要

トリガーの仕組み

トリガーは、テーブルに対するデータ操作（DML）をトリガーポイントとして起動し、事前に定義したアクション（SQL）を自動的に実行します。例えば、社員テーブル（employees）に新規データをINSERTした際、別の履歴テーブル（log_table）にその情報を自動登録する、といった使い方があります。

このトリガー（after_trigger_insert_test）を実際にOracle Databaseで作成すると、以下の構文となります。

CREATE OR REPLACE TRIGGER after_trigger_insert_test

AFTER INSERT ON employees

FOR EACH ROW

BEGIN

INSERT INTO log_table (message, created_date)

VALUES ('レコードが登録されました', SYSDATE);

END;

多くのDBMSでは、条件（WHEN 句）を指定できるため、特定列の値が変わった場合のみ作動する複雑な制御も可能です。これにより、業務ロジックの一部をアプリから切り離し、データベース側でデータの整合性を担保できます。

BEFORE と AFTER の違い

トリガーには主に BEFORE トリガーと AFTER トリガーの2種類があります。

BEFORE トリガーは『データ変更処理が実行される前』に起動し、値の検証・修正や、処理の中断（ROLLBACK）ができます。一方 AFTER トリガーは『データが確定して書き込まれた後』に動作し、監査ログや履歴データへの登録などに適しています。

例えば、商品発注データの登録時に在庫数のチェックを行い、条件を満たさない場合は BEFORE、逆に正常に処理が完了したことを履歴データに残したい場合は AFTER を使います。

トランザクションとの関係

トリガーはトランザクション制御とも関連しています。通常、トリガー内で行われた処理も呼び出し元のSQLと同一トランザクションに含まれます。そのため、途中でエラーが発生すれば全体がロールバックされます。ただし、DB製品や設定によっては自動コミット動作があったり、トリガー内でのコミットは禁止されるケースもあったりするので、注意が必要です。

主要DBでの定義例

データベースのトリガーは多くの主要RDBMSでサポートされており、基本概念は共通していますが、構文や細かい仕様には製品ごとの違いがあります。ここでは代表的な3種類のデータベースでのトリガー定義方法を紹介します。

Oracle Database

【トリガー作成SQLの例】

CREATE OR REPLACE TRIGGER after_trigger_insert_test

AFTER INSERT ON employees

FOR EACH ROW

BEGIN

INSERT INTO log_table (message, created_date)

VALUES ('レコードが登録されました', SYSDATE);

END;

Oracle Databaseではトリガーの機能が非常に充実しており、BEFORE/AFTER はもちろん、INSTEAD OF（ビューへの操作を代替して実行する）トリガーも利用できます。基本的な構文は CREATE OR REPLACE TRIGGER から始まり「BEFORE INSERT OR UPDATE ON テーブル名」といった形でトリガーポイントを定義します。

PostgreSQL

【トリガー作成SQLの例】

-- ストアドファンクション定義

CREATE OR REPLACE FUNCTION log_insert()

RETURNS TRIGGER AS $$

BEGIN

INSERT INTO log_table (message, created_date) VALUES ('レコードが登録されました', CURRENT_TIMESTAMP);

RETURN NEW;

END;

$$ LANGUAGE plpgsql;

-- トリガー定義

CREATE TRIGGER after_insert_trigger_test

AFTER INSERT ON employees

FOR EACH ROW

EXECUTE FUNCTION log_insert();

PostgreSQLでは、トリガー自体とトリガー関数（ストアドファンクション）を分けて作成します。まず「CREATE FUNCTION 関数名 RETURNS TRIGGER」で関数を作成します。その後 CREATE TRIGGER を使ってテーブルに関連付け、どの操作（BEFORE / AFTER / INSTEAD OF）、どのタイミングで起動するかを設定します。

この分離構造により、複数のトリガーから同じ処理を呼び出したり、メンテナンス性を高めたりできるのが大きな利点です。

MySQL

【トリガー作成SQLの例】

CREATE TRIGGER after_insert_trigger_test

AFTER INSERT ON employees

FOR EACH ROW

BEGIN

INSERT INTO log_table (message, created_date) VALUES ('レコードが登録されました', NOW());

END;

MySQLでは比較的シンプルな構文でトリガーを定義できます。CREATE TRIGGER に続き、BEFORE または AFTER、さらに INSERT / UPDATE / DELETE を指定し、ON テーブル名 FOR EACH ROW と書きます。MySQLも NEW.カラム名や OLD.カラム名を使ってレコードの変更前後の値を直接参照可能です。

ただし、MySQLのバージョンによっては INSTEAD OF トリガーがサポートされておらず、複雑なビュー更新に直接使えない点は注意が必要です。またトリガー内でのトランザクション操作（COMMIT や ROLLBACK）は禁止されているため、例外処理は呼び出し側のアプリケーションでカバーする設計が重要です。

トリガーを利用するメリット、デメリット

ここではトリガーを導入する際に押さえておくべき代表的なメリットとデメリットを解説します。

メリット

トリガーのメリットとして、以下が挙げられます。

複数テーブル間のデータ更新を自動で行える
履歴データや変更ログの記録が自動で行える
データ更新に応じた処理を自動的に実行し、人為的なエラーを減らせる

一度設定すれば自動で処理を行うことができ、アプリケーションでの作り込みを減らすことができます。

デメリット

トリガーのデメリットとして、以下が挙げられます。

トリガーを複数設定すると処理が複雑化し、パフォーマンスが低下する
他の開発者から見て動作が分かりにくい
障害が発生した際の原因切り分けが難しくなる

トリガーはデータベース内での処理であるため、システム全体の挙動がブラックボックス化しがちです。この問題を避けるためには、トリガーはシンプルかつ必要最小限に設計し、十分なテストを行うことが重要です。

まとめ

本記事では、データベーストリガーについて解説しました。データベーストリガーは、データ操作に伴う処理を自動化し、データの一貫性確保や人為的ミスの削減などのメリットが得られる強力な機能です。しかし、いくつもトリガーを設定すると処理の流れが見えにくくなり、パフォーマンスや障害調査の面で課題が生じることも少なくありません。トリガーを導入する際は、メリット・デメリットを正しく理解し、シンプルかつ最小限に設計することが肝心です。