入力時に特定の値を制限したり、削除の要求時にそれらが削除されないようにするために、参照整合性が必要であることを理解しています。ただし、このメカニズムが常に使用されることを排除する有効なユースケースについては不明です。
これはいくつかのサブ質問に分類されると思います。
考え？
参照整合性が適切でないのはどのような場合ですか?
通常、データがトランザクション データベースの読み取り専用コピーであるデータ ウェアハウスで使用されない場合の参照整合性。RI が不要な場合のもう 1 つの例は、行 ID を含む情報をログに記録する場合です。読み取り専用ログ テーブルの参照整合性を維持することは、データベース オーバーヘッドの無駄です。
外部キーのリストの複数のサブセットおよび/または不完全なサブセットを含むフィールドを持つことは適切ですか?
場合によっては、データの品質よりもデータの取得に関心があることがあります。それぞれが独自にデータ品質の問題を抱えている異種システムから大量のデータを集約していると想像してください。より良いデータ品質を求めている場合があり、キーが壊れていてもすべてを 1 か所にまとめることは、真のデータ品質への移行の出発点となります。これは理想的ではありませんが、利点がトレードオフを上回る可能性があるため、実際に起こります。
通常、これはスキーマ構造の設計上の決定であるか、それともインターフェイスの設計上の決定であるか? (または両方またはどちらでもない可能性があります)
システム開発のすべては情報セキュリティに集中しており、その重要な要素はデータの完全性です。データベース構造は、可能な限りこれらのことを強制する方向に傾く必要がありますが、多くの場合、最新のデータベース システムを扱っていません。場合によっては、データ ソースが、時代遅れのアプリを含む古い学校の AS400 である場合があります。場合によっては、データの整合性を提供するデータおよびビジネス レイヤーを構築する必要があります。
ちょうど私の考え。
私が聞いた唯一のケースは、膨大な量のデータをデータベースにロードする場合です。その場合、データが有効であることが確実にわかっている限り、参照整合性をオフにすることが理にかなっています。読み込み/移行が完了したら、参照整合性をオンに戻す必要があります。
データ検証規則をプログラミング コードとデータベースのどちらに置くかについては議論があり、それはソフトウェアのユース ケースに依存すると思います。単一のアプリケーションがデータベースへの唯一のパスである場合は、検証をプログラム自体に入れることができ、おそらく問題ありません。ただし、いくつかの異なるプログラムが同時にデータベースを使用している場合 (たとえば、自分のアプリケーションと友人のアプリケーション)、データが常に有効になるようにデータベースにビジネス ルールが必要です。
「検証ルール」とは、「カート内のアイテム > 0」などのルールのことです。検証ルールが必要な場合と不要な場合があります。しかし、主キー/外部キーは常に重要であると思います (または、それらがあればいいのにあとでわかるかもしれません)。ある時点でレプリケーションを行いたい場合は、それらが必要だと思います。
参照整合性は、パフォーマンス、スケーラビリティ、および/またはその他の機能を犠牲にすることがなければ、常に適切です。
一部のアプリケーションでは、参照整合性と引き換えに、データの品質よりも重要な何かが得られる場合があります。
参照整合性が適切でないのはどのような場合ですか?
大量のレコードをまとめてコピーしたり、ある種のバックアップからデータを復元したりする場合、参照整合性の制約を一時的にオフにすると便利な場合があります。
外部キーのリストの複数のサブセットおよび/または不完全なサブセットを含むフィールドを持つことは適切ですか?
このようにデータを複製することは、正規化の概念に反します。このアプローチには、長所と短所があります。
通常、これはスキーマ構造の設計上の決定であるか、それともインターフェイスの設計上の決定であるか? (または両方またはどちらでもない可能性があります)
私はそれをスキーマ設計の決定と考えています。リレーショナルな観点から問題をモデル化する最善の方法を考えてください。データベースを意図したとおりに使用してください。