DBの整合性：トリガーとキー/制約

Question

私と私の友人は、データベースの設計について互いに議論しました。
彼は、複雑なデータベースの整合性を確保するためにトリガーを使用する方が良いと主張しています。

この目的のためには、キー（プライマリ、ユニーク）、および制約を使用する方が良いと思います。
トリガーは<！> quot; behind the scene <！> quot;で動作するため、トリガーの使用は危険だと思います。また、コマンドの実行後に何が起こるかを言うのは簡単ではありません。さらに、トリガーにバグがある場合、DBの整合性が損なわれる可能性があります。

あなたはそれについてどう思いますか？

Answer 1

<！> quot;このトピックに関するAskTomのディスカッションです。この問題に関する厳格なルールはありません（そうでなければ議論はありません！）... <！> quot;

はい。宣言型は、手続き的に実装されるよりも常に優れています。宣言型はエラーを起こしにくいです。宣言型は保守が簡単です。宣言型は、手続き的に実装されるよりも自己文書化されます。宣言型はDBMSが最適化する最適な機会を提供し、DBMSはほとんどの場合プログラマよりも優れたオプティマイザです。

手続き的に実装された場合の唯一の利点は、SQLから得られる貧弱なPK + FKだけでなく、真の宣言的制約が利用可能であれば、それがない人のためのジョブを意味することです。

Answer 2

実際には、友人が自分の考えを考える理由を言うことはありませんが、いずれにしても、制約/キーはデータの整合性を確保するための標準的で定義された適切な方法です：

• 誰もがそれらを知っているので、それらを使用することにより、最も驚きの原則に違反することを避けることができます。

• これらはすでに実装され、テストされ、動作しています。

独自のデータ整合性コードをロールしても、実際の利点はありません。トリガーは、（たとえば）すべての挿入のログを保持するなど、他のユースケースを対象としています。

Answer 3

データベースは指定しませんでしたが、OracleやSQL ServerなどのANSI標準のリレーショナルDBMSを想定しています。

それは整合性の意味に依存すると思います。子レコードと親レコードをすべて一緒に保持し、孤児を防止しようとしている場合は、主キー制約と外部キー制約を使用した組み込みRIが最適です。

RIがより複雑な場合、たとえば親レコードのフィールド1が<！> gt;の場合100の場合、子レコードのフィールド2は<！> ltでなければなりません。 200.トリガーを使用する必要があります。

単純なRIを実施するためにトリガーを使用することはありません。そのホイールは既に発明されています。

Answer 4

私はそれが何らかの方法で明確にカットされているとは思わないが、ちなみに、私はDRI制約で行うことができるすべてのものにDRI制約を使用する傾向があり、実行できないことのトリガーを保存するDRI制約で（日付範囲の重複を防ぐなど）