トリガーを嫌う人は非常に多い。
トリガーはレコードの更新を起点(トリガーにして)に自動的に動くので、アプリケーション側のプログラムソースからは追いかけられず、プログラマが意図しない結果になることがある。というのが嫌われる一番の理由でしょう。
しかし、「自動的に動く」というのは非常に便利で、多くのアプリケーションや、OS、IDE、(メタ)プログラミング言語が目指すところです。
では、なぜトリガーは異常に嫌われるのでしょうか。
「自動的にやってくれる」と「勝手に変わった」
トリガーは自動的に動くので非常に便利で、当たり前の制限はありますが何でもできます。「何でもできる」というのは曲者で、トリガーは作っている(コーディングしている)ときは非常に便利ですが「後で訳が分からなくなる」という「諸刃の剣」になる典型のテクニックです。
実際にプロジェクトで使わなくても、試しに使ったぐらいで「諸刃の剣」ぶりが分かってしまう。つまり「典型的なバッドテクニック」と認識できてしまうものなので「これはダメだ」とレッテルを貼られるのは無理がないかも知れません。
アプリケーションや OS などが「自動的にやってくれる」ことは、ともすれば「勝手に変わった」となります。「勝手に変わった」という認識になれば、その機能はお節介で使いにくいものという認識になります。「自動的にやってくれる」機能というのは、常に「諸刃の剣」になるという危険性をはらんでいるのです。
例えば、有名どころでは、多くの SE が嫌う「Wordの自動段落番号機能」でしょうか。(私にとっては非常に便利でそれがなくなったら Word を使う意味がないとすら思うのですが)
「Wordの自動段落番号機能」は非常に便利なのですが、それが「お節介で不便で仕方がない」と感じる。仕様書や文章を書くのを「Wordで」と指定しても、拒否してExcel方眼紙で書き始める SE は非常に多いです(苦笑)。
同じものを使って、真逆に感じる人がいるというのはどういうことかというと、便利だと感じる人は「どのように自動的に番号が振られるか」ルールが分かっているから便利なのであって、「勝手に変わる」と感じる人達は、ルールが分かってないから「勝手に変わるお節介機能」となってしまいます。
同様に、Ruby On Rails はルール(規則)によって大幅にコーディング量を減らすことができます。自動的に多くのソースを作ってくれるメタプログラミングです。しかし、ルールを知らなければソースは全く追いかけられませんし、書けません。ルールがあってこそのメタプログラミングです。
いずれも、ルール(規則)が分かれば便利、分からなければ不便となります。ルールが合理的で徹底的に周知できるかというのがポイントになります。
トリガーは自動的に動きます。「自動的に動く」≒「勝手に動く」と判断するのは SE として優れた危険察知能力なのですが、もう一歩踏み込めば、「自動的に動く」と「勝手に動く」の境界線は「ルールがあるかどうか」ということで、「ルールを決めればいい」ということが分かるでしょう。
トリガーは何でもできます。自由度が高いからこそ「勝手に動く」になりやすく、何をやっているか分からないバッドテクニックになりがちですが、それは、作るべきルールを作っていないから、ルールを徹底していないから、バッドテクニックになるだけの話です。
トリガーの適応範囲(ルール)
私が決めているトリガーの適応範囲は簡単です。
おそらく、80〜90%以上のプロジェクトでテーブル定義書はエクセルで作られていることでしょう。エクセルからCreate(Table)文を書くプロジェクトも多いと思います。同様に、トリガーを使うのはテーブル定義書から Create(Trigger)文を出力できる範囲。というのがトリガーの適応範囲になります。
トリガーはテーブル定義書から出力される範囲までとすれば、ルールはプロジェクト毎に違って当然ですが、トリガーでできる範囲は、必然的に、ログの出力や、整合性のチェック、整合性の維持に関する処理に限られるようになるでしょう。
テーブル定義書にトリガーの出力に必要な情報が書き出されるわけですから、その時点でルールが明確になります。
ルールが明確にすることによって「勝手に動く」ではなく「自動的にやってくれる便利機能」に昇華できる訳です。
何度か書いている、サロゲートキーとナチュラルキーの併用運用も、エクセルから出力されるトリガーで可能です。
http://d.hatena.ne.jp/Sikushima/20111129/1322579225
http://d.hatena.ne.jp/Sikushima/20111125/1322187990
「トリガーは使うべきではない」という思考停止はすべきではないです。