私と私の友人は、データベースの設計について互いに議論しました。
彼は、複雑なデータベースの整合性を確保するには、トリガーを使用する方がよいと主張しています。
この目的には、キー（プライマリ、一意）、および制約を使用する方がよいと思います。
トリガーの使用は「舞台裏」で機能し、コマンドの実行後に何が起こるかを言うのは簡単ではないため、危険だと思います。さらに、トリガーにバグがある場合、DBの整合性を損なう可能性があります。
あなたはそれについてどう思いますか？
4 に答える
9
「これがこのトピックに関するAskTomの議論です。この問題に関する厳格なルールはありません（そうでなければ議論はありません！）...」
はいあります。宣言型は、手続き型で実装するよりも常に優れています。宣言型はエラーを起こしにくいです。宣言型は保守が簡単です。宣言型は、手続き的に実装されるよりも自己文書化されます。宣言型は、DBMSが最適化するための最良の機会を提供し、DBMSは、ほとんどの場合、プログラマーよりも優れたオプティマイザーです。
手続き型実装の唯一の利点は、SQLから得られる貧弱なPK + FKだけでなく、真の宣言型制約が利用可能である場合にそれがない人のための仕事を意味することです。
于 2009-09-15T23:45:28.147 に答える
6
あなたは実際にあなたの友人が彼の考えを考える理由を言いませんが、いずれにせよ、制約/キーは、2つの理由から、データの整合性を確保するための標準的で定義された適切な方法です。
誰もがそれらを知っているので、それらを使用することで驚き最小の原則に違反することを避けられます。
それらはすでに実装され、テストされ、機能しています。
独自のデータ整合性コードをローリングすることによる実際のメリットはありません。トリガーは、（たとえば）すべての挿入のログを保持するなどの他のユースケースを対象としています。
于 2009-09-15T23:11:41.570 に答える
2
どのデータベースを指定していませんが、ANSI標準のOracleやSQLServerなどのリレーショナルDBMSを想定しています。
私はそれがあなたが誠実さによって何を意味するかによると思います。子レコードと親レコードをすべて一緒に保持し、孤立を防止しようとしている場合は、主キーと外部キーの制約を使用する組み込みのRIが最適です。
RIがより複雑な場合、たとえば、親レコードのフィールド1が100を超える場合、子レコードのフィールド2は200未満である必要があります。トリガーを使用する必要があります。
単純なRIを強制するためにトリガーを使用することはありません。そのホイールは、すでに発明されています。
于 2009-09-15T23:15:42.467 に答える
0
どちらか一方が明確だとは思いませんが、fwiw、DRI制約で実行できるものにはすべて、DRI制約を使用し、DRIでは実行できないもののトリガーを保存する傾向があります。制約（日付範囲の重複の防止など）
于 2009-09-15T23:22:40.720 に答える