【入門編】トリガーの基礎 – PostgreSQL

こんにちは！データベースの世界へようこそ。

現場でバリバリとSQLを書いていると、「あ、この作業、いちいち手動でやるの面倒だな…」「もしデータを更新した時に、ついでに別の記録も残せたら楽なのに」なんて思うこと、ありませんか？

そんな時、私たちエンジニアが頼りにするのが「トリガー（Trigger）」という仕組みです。名前からして何だか強そうですよね。今日は、このトリガーが一体何をしてくれるものなのか、初心者の方にもスッとイメージできるように解説していきますね。

—

日常の出来事で例えるなら、「自動販売機」をイメージしてみてください。

お金を入れてボタンを押す（これが「データの更新」）。すると、自動的にジュースが出てきて、お釣りが返ってくる（これが「トリガーによる自動処理」）。

データベースにおけるトリガーも全く同じです。「誰かがデータを書き込んだら、ついでにこれもやっておいて！」と、あらかじめ命令をセットしておける「自動化のスイッチ」のことなんです。

—

トリガーには、どのタイミングで動くかという「合図」がいくつかあります。

「データが入ってくる直前にチェックしたい」時。
例えば、入力された数字が変じゃないか確認したり、勝手に書き換えたりする「門番」のような役割です。

「処理が終わったついでに何かしたい」時。
「更新しましたよ」というログを別の場所に残したり、通知を送ったりするのにぴったりです。

「直接やるんじゃなくて、代わりにこれやって！」という代理人。
ちょっと複雑なビュー（表の見せかけ）を操作する時に使います。

—

次に大切なのが、「何回動くか」という設定です。

例えば、100人分のデータを一度に更新したとします。この設定だと、100回分きっちりトリガーが働きます。「一人ずつ丁寧に対応する」イメージですね。

100人分更新しても、トリガーは「1回だけ」動きます。「作業全体が終わった後に、一言だけ報告する」ような使い方です。

—

構文と聞くと身構えてしまうかもしれませんが、パズルのように組み立てるだけです。

CREATE TRIGGER 自動記録のトリガー
AFTER INSERT ON ユーザーリスト
FOR EACH ROW
EXECUTE FUNCTION ログを残す関数();

これだけで、「ユーザーリストに新しい人が追加されたら（AFTER INSERT）、一人ずつ（FOR EACH ROW）、自動的にログを残す（EXECUTE FUNCTION）」という仕組みが完成です！

—

最後に、ベテランからのアドバイスをひとつだけ。

トリガーは魔法のように便利ですが、「やりすぎ注意」です。あちこちにトリガーを仕込みすぎると、どの処理がどこで動いているのか分からなくなり、「データが更新された原因はどれだっけ？」と迷子になってしまいます。

「ここぞ！」という自動化のポイントに絞って使うのが、スマートなデータベース設計のコツですよ。

—

いかがでしたか？「トリガー」という言葉の響きは難しそうですが、要は「頑張るデータベースのお手伝いさん」なんです。

まずは小さなテーブルで試してみて、「お、本当に勝手に動いた！」という感動をぜひ味わってみてください。それがエンジニアとしての第一歩です。

それでは、また次回の記事でお会いしましょう！