リレーションシップなし/リレーションシップとのデータベース設計外部キーを使用する必要がありますか？

Question

決定的な状況私は来ました。 RDBMS、特にSQL Serverに関連しています。

私の思うように、どのデータベースにも複数のテーブルがあり、これらのテーブルはクエリ時に直接キーまたはジョインを介して相互に接続されています。今私の理解ごとに、データベースの設計には2つの選択肢があります。

1 - RELATIONSなし（外部キーなし）

私はテーブル間の外部キー関係を提供していない場合は、私が参照整合性を持っていないかもしれないが、私はPKと親レコードを削除し、まだすることができます子供の記録をそのまま残す。そして私が親でPKレコードを再作成すると、再び参加時にその子供を参照し始めます。それが1つの利点です。しかし、私はすべてのテーブルレコードを更新する必要があります私は親PKレコードを更新する場合。それは欠点です。

2 - （外部キーを持つ）RELATIONS

WITH私はテーブル間に確立FKSを持っている場合、私は、更新のための余分なコーディングを行う必要があり、それらのレコードを削除しないでください。しかし、問題は、私がPKレコードまたは親レコードだけを削除したいときです。そこで、各テーブルにIsActiveカラムを提供する必要があります。次に、使用するすべてのクエリでIsActiveカラムを検索する必要があります。そしてそれは非常に厄介で長い。だから、完璧ではない。

このジレンマの中で、私のデータベース設計パターンをどうすべきか教えてください。

Answer 1

リレーショナルデータベースを使用する主な利点はデータの整合性です。そのため、参照整合性の制約を適切に維持することをお勧めします。外部キーのないデータベースで作業していたため、孤立したデータを特定し修復することは、雑用を避けるのに最善の方法です。

Answer 2

最初のものが最初です。外部キー制約がスキーマ内で宣言されていない場合でも、外部キーは外部キーです。そのように宣言されていない外部キーを持つ結果として、DBMSは、無効なキー値の挿入や以前に有効な値の孤立に対する保護を提供していません。その責任は、アプリケーションプログラマーまたは対話ユーザーに当てはまります。

第2に、外部キーが宣言されていても、呼び出されたときにクエリで結合を使用します。結合をいつ、どのように使用するかを学ぶことは、リレーショナルデータベースからデータを取り出す方法を学ぶことの基本です。

第3に、「関係」という用語は、外部キーはデータの関係モデルの不可欠な部分ですが、外部キーよりもはるかに多くを指します。 SQLデータベースを構築する場合、初心者であっても、データのリレーショナルモデルに基づいて設計されている可能性は圧倒的です。それが良い関係モデルであろうとなかろうと、別の問題です。

次に、削除や更新にCASCADEオプションを使用しなくても、外部キーを宣言することができます。だから、あなたはまだそれらの事件に対処するためにいくつかの余分なプログラミングを行う必要があります。

最後に、子供の1人を削除せずに親レコードを削除したい場合は、あなたの責任で、プログラマやユーザーとして、関係を解除する必要があります親レコードを削除する前にFK値をNULLに設定します）。

DBMSがあなたのために大変な作業をしていても、データの管理を少しして、正しく行う必要があります。それは不完全な世界です。