DBにおけるトリガーについて

Question

データベースにおけるトリガーについての質問です。
ミック著「達人に学ぶDB設計徹底指南書」(2012)にトリガーについての記述があります。（331P)
「トリガーは非常に危険なので、使うべきではありません。代わりにストアドプロシージャを使うべきです。この理由は次の４つです。
理由１：実装ごとに文法がバラバラで統一性がない。
理由２：オプティマイザによる最適化を受けられない。
理由３：エラーハンドリングが難しい。
理由４：アプリケーション以外の更新でも発射されるため、開発が難しくなる。

理由１は、程度に差こそあれストアドプロシージャについても当てはまるもので、トリガーをプロシージャで代用せよ」と説く理由としては少し弱いものですが、残りの三つの理由は極めて重大です。
トリガーで実行されるコードは、DBMS内部のブラックボックス処理であるため、通常のSQLチューニングができません。（以下略）」

理由２がよく分かりません。著者の意味するところはストアドプロシージャであればオプティマイザによる最適化を受けることができるということだと思うのですが、ストアドプロシージャもまたオプティマイザによる最適化を受けることはできないと思うのですが、どうなのでしょうか？
DBMSのオプティマイザはそもそもSQLのアクセスパスを最適化をするのが仕事であって、DBMS内に保存されている手続き型のコードであるストアドプロシージャやトリガーなどとは関わりはないと考えていたのですが、本の記述にあるということは関係あるということなのでしょうか？
（検索してもめぼしい情報は見つけられませんでしたが）
ご存知の方、回答お願いします。

Answer 1

「トリガーは非常に危険なので、使うべきではありません。代わりにストアドプロシージャを使うべきです。この理由は次の４つです。

サーバのメモリが64GBytes〜ある現状で、トリガーとストアドプロシジャで比較されても、五十歩百歩としかいえません。もともとロジック層とデータ層を分離するほうがアーキテクチャとして優れているに決まっていて、インデックスでさえデータベースに持たせたくないところを、性能を確保するために仕方なく、トリガーやストアドプロシジャを使ってロジック層の一部をDBMSに実装していたと理解しています。
トリガーのようにロジック（業務要件に密着したもの）を特定のDBMSの窮屈な環境で実装するよりも、DBMSは単にデータを保持することに特化し、アプリケーションサーバのロジック層（できるかぎり設定ファイルによるインジェクションで）でデータの整合性を確保すべきです。トリガーやストアドプロシジャを性能のために利用しようとする前に全件をアプリケーションサーバのメモリに保持しておくことはできないかを検討すべきです。
1Kbytes のデータであれば、1Gbytes で100万件保持できます。この計算をした上でストアドプロシジャやトリガの必要性を考えるべきです。もし、もうひとつ上の桁（１０億〜）のデータを扱おうとするならば、それは map reduce などの技術になってきます。

と、まったく質問に対する回答になっていないことが先行しましたが、

DBMSのオプティマイザはそもそもSQLのアクセスパスを最適化をするのが仕事であって、DBMS内に保存されている手続き型のコードであるストアドプロシージャやトリガーなどとは関わりはないと考えていたのですが、本の記述にあるということは関係あるということなのでしょうか？

bill さんのご認識のとおりであると思います。アプリケーションの実装車から見れば、トリガーもストアドプロシジャの一種でしか無いと思います。

それで、私なりに原文の主張を翻訳しますと、「DBMSを徹底的に使いこなそうとするのはいいけど、トリガーまで含めて徹底的に使っちゃうとやっぱり不自由だし拡張性もなくなっちゃうんだからストアドプロシジャ程度に留めておいたほうがいいよ（この本は「徹底指南書」だからはっきりとは言いにくいけど）」ってことだと思います。

Comments

[退会済みユーザー]

回答ありがとうございました。

[kantomi]

お話にならないw