鏡の中: CreatedAtにトリガーで対応するという技（？）についてAIに教わりました

2025年9月10日水曜日

あるツール的なWEB APIを作っていたのですが、

テーブルを定義していて、いつものようにCreatedAt、UpdatedAt、などを作っていました。

わたしはこのやり方はあまり好きではなく、テーブルにいつ誰が作ったか、更新したかを見るのであれば、ログに残せばいいと考えています。

しかしながら、ある現場でCreatedAt、UpdatedAt、CreatedUser、UpdatedUserのようなカラムを全テーブルに持っているプロジェクトがあったので、今回はそれに倣ってやってみようと気軽に考えて、コードの生成をAIにお願いしてみました。

わたしはVSC+Geminiの組み合わせでやってますが、いつものようにGemini君はReadme.mdに書かれた通りの仕様で大体一発でコードを生成してくれました。

で、気になったのがこれ

-- updated_atを自動更新するためのトリガー

CREATE OR REPLACE FUNCTION update_updated_at_column()

RETURNS TRIGGER AS $$

BEGIN

NEW.updated_at = NOW();

RETURN NEW;

END;

$$ language 'plpgsql';

CREATE TRIGGER update_products_updated_at

BEFORE UPDATE ON products

FOR EACH ROW

EXECUTE FUNCTION update_updated_at_column();

ようするにトリガーでupdated_atにNOWを設定するトリガーを作り

productsのUpdateがあった際に動くようにしているという点です。

これを見たときに、INSERTではトリガーが動かないなと思ったのですが、INSERT時には、テーブル定義でDEFAULT CURRENT_TIMESTAMPが設定されているため、Created_AtもUpdated_Atも同じ時刻が入ります

で、実際更新するときは、管理画面的なところから更新するのでしょうが、

その際は、トリガーが動いて更新日付が更新されるという挙動になります。

更新する際にプログラム側から日付を入れればいいじゃんと思うのですが、トリガーとして動く仕組みのいいところ悪いところをAIに聞いてテーブルを作ってもらいました

結論として、created_atやupdated_atのようなメタデータの管理には、データベースのトリガー（またはDEFAULTやON UPDATE句）を使用するアプローチが強く推奨されます。

データの整合性を担保できるというメリットは、他のデメリットを大きく上回ります。現在のプロジェクトの実装は、このベストプラクティスに従っており、非常に堅牢な設計と言えます。

ぶっちゃけですね、アプリケーション側でやった方が◎が多いんです

しかも△の数も同じです

これでなぜAIがトリガーを強く推しなのかというと、データの整合性の◎はちょっとレベルが違うくらいな◎だということらしいです。

なお、このようにPros/Consをまとめて、同じレベルのものはPros/Consから削除するという手法は、フランクリンがやっていた手法です

まぁ納得いかない人もいるし、別の考えの人もいることでしょう

わたしはモヤッてます

鏡の中