参照整合性が適切でないのはどのような場合ですか?

Question

エントリ時に特定の値を制限したり、場合によっては削除要求時にそれらの値が削除されないようにするために、参照整合性が必要であることを理解しています。ただし、このメカニズムが常に使用されないようにする有効な使用例については不明です。

これはいくつかの下位質問に分類されると思います。

1. 参照整合性が適切でないのはどのような場合ですか?
2. 外部キーのリストの複数のサブセットや不完全な可能性のあるサブセットをフィールドに含めることは適切ですか?
3. 通常、これはスキーマ構造設計の決定であるべきでしょうか、それともインターフェイス設計の決定であるべきでしょうか?(あるいはどちらも、あるいは両方とも可能性があります)

考えは？

Answer 1

参照整合性が適切でないのはどのような場合ですか?

参照整合性 (通常、データがトランザクション データベースの読み取り専用コピーであるデータ ウェアハウスでは使用されません)。RI が必要ないもう 1 つの例は、行 ID を含む情報をログに記録する場合です。読み取り専用ログ テーブルの参照整合性を維持することは、データベースのオーバーヘッドの無駄です。

外部キーのリストの複数のサブセットや不完全な可能性のあるサブセットをフィールドに含めることは適切ですか?

データの品質よりもデータのキャプチャを重視する場合があります。それぞれがデータ品質の問題を抱えている異種システムから大量のデータを集約していると想像してください。場合によっては、データ品質の向上や、キーが壊れている場合でもすべてを 1 か所にまとめることを求める場合があります。真のデータ品質を目指すための出発点を表します。これは理想的ではありませんが、利益がトレードオフを上回る可能性があるため、実際に起こります。

通常、これはスキーマ構造設計の決定であるべきでしょうか、それともインターフェイス設計の決定であるべきでしょうか?(あるいはどちらも、あるいは両方とも可能性があります)

システム開発のすべては情報セキュリティを中心としており、その重要な要素はデータの整合性です。データベース構造は、可能な限りこれらのことを強制する方向に傾くべきですが、多くの場合、最新のデータベース システムを扱っていません。データ ソースが、長い間時代遅れのアプリを備えた古い学校の AS400 である場合があります。場合によっては、データの整合性を提供するデータ層とビジネス層を構築する必要があります。

ただ私の考えです。

Answer 2

あなたは、データベースへのデータの膨大な量をロードしようとしている場合は、私は聞いたことがある唯一のケースです。その場合には、それは限り、あなたが知っているように、特定のデータが有効であることを、参照整合性をオフにしても意味があります。あなたのロード/移行が完了すると、参照整合性がオンに戻す必要があります。

データベース対コードをプログラミングでデータ検証ルールを置くことについての議論がありますが、私はそれがあなたのソフトウェアのユースケースに依存だと思います。単一のアプリケーションがデータベースへの唯一の道である場合は、プログラム自体に検証を入れ、おそらく大丈夫である可能性があります。いくつかの異なるプログラムが同じ時間（例えば、アプリケーションとあなたの友人のアプリケーション）でデータベースを使用している場合は、あなたのデータが常に有効になるように、しかし、あなたは、データベース内のビジネス・ルールをお勧めします。

「検証ルール」とは、私はこのような「カート> 0でアイテム」などのルールについて話しています。あなたは、または検証ルールをたくない場合があります。しかし、私は、主キー/外部キーは常に重要な（またはあなたがあなたがそれらを持っていた希望していることに後で見つけることができる）と思います。私はあなたには、いくつかの時点でレプリケーションを行いたい場合、彼らが必要とされていると思います。

Answer 3

1. 参照整合性が適切でないのはどのような場合ですか?

   大量のレコードを大量にコピーしたり、ある種のバックアップからデータを復元したりすると、参照整合性の制約を一時的にオフにすると便利です。

2. 外部キーのリストの複数のサブセットや不完全な可能性のあるサブセットをフィールドに含めることは適切ですか?

   この方法でのデータの複製は、正規化の概念に反します。このアプローチには利点と短所があります。

3. 通常、これはスキーマ構造設計の決定であるべきでしょうか、それともインターフェイス設計の決定であるべきでしょうか?(あるいはどちらも、あるいは両方とも可能性があります)

   私はそれをスキーマ設計の決定と考えます。関係用語で問題をモデル化する最良の方法を考えてください。データベースを意図した方法で使用します。

Answer 4

それは、パフォーマンスを犠牲にしてきスケーラビリティ、および/または他の機能していない場合は、

参照整合性は、常に適切であろう。

一部のアプリケーションでは、参照整合性は、データの品質よりも重要なものと交換することができる。

Answer 5

1. NoSQL、複数値、および oo-db 領域の少数の人々は、決して異なる感情を抱くことはありません。彼らの言うことは聞かないでください、彼らは間違っています。
2. はい。たとえば、車両が (lotid,vin) として一意に識別される場合、lotid はロット テーブルの外部キーになります。ロットのすべての写真を検索したい場合は、 vehicle_pictures キーのサブセット (lotid in (lotid,vin)) を使用して、 vehicle_pictures テーブルをロット テーブルに結合できます。それとも、私はあなたのことを理解できていないのでしょうか？
3. スキーマ、インターフェースは二番目です。スキーマが悪い場合、優れたインターフェイスを実現することは長期的な目標にはなりません。