SQLサーバーと最適化の関係

Question

私はSQL Serverと.NETで開発された特定のプロジェクトの開発者でしたが、テーブル間の物理的な関係は使用しませんでしたが、論理的な「論理的な外部キー」を使用します。

私は彼らに何らかの理由で「より最適です」と尋ねました。

私が本当に知りたいことは、それは本当に最適なのでしょうか、それとも神話ですか？

Answer 1

データベースからの読み込みに関しては、外部キーが定義されているかどうかは、その中に入っていません。外部キーと読み取りのパフォーマンスとの間には関係がありません。

パフォーマンスに影響を及ぼすことは、テーブルの格納方法、テーブルに定義されているインデックス、格納されている統計情報です。

これは、データベースの参照整合性がない（特にテストするのが些細な場合があるため）、正当な理由ではありません。

Answer 2

「実際の」外部キーと「論理」外部キーとの間には物理的な違いはありません。それらはテーブル内の単なる列であり、テーブルがディスクに格納される方法には影響しません。私が最初に学んだとき、これは実際に私を驚かせました。

唯一の違いは、「実際の」外部キーがある場合、テーブルで削除、更新、または挿入ステートメントが実行されるたびに、データベースサーバーは値が正当な値に更新されていることを確認する必要があります。更新、挿入、削除、またはマージのステートメントの実行計画を見ると、実際には外部キーを持つすべてのテーブルをスキャンまたはシークする必要があります。

多くの外部キーがある場合や有用なインデックスがない場合は、パフォーマンス上のオーバーヘッドになります。

写真会社にはテーブルがあり、従業員には別のテーブルがあります。 employees表には、companyIdという列があります。

あなたが実行します。

delete from Companies where companyId = 123; 

データベースサーバがその企業IDのための任意の従業員が存在しないことを確認する必要があります。

insert into Employees (companyId, name) values (123, 'John'); 

データベースサーバは企業ID 123が存在することを確認するために、企業のテーブルを検索する必要があります。同じことは、あなたが実行したときに適用されます。

はい「論理」外部キーのみを持つ方が高速です。ただし、データ破損の可能性を犠牲にしており、バグやその他のデータ破損の原因を突き止めるのに時間がかかる可能性があります。価値があるかどうかはあなた次第です。考慮すべき点の1つは、読み取り専用クエリに影響しないことです。

編集マーティン・スミスが指摘したように、私は外出していたため、外来キーが高速になるケースがあります。外部キーを持つテーブルに内部結合があり、2番目のテーブルで列が参照されていない場合、クエリは外部キーを信頼できるので、2番目のテーブルにヒットする必要はありません。

Answer 3

「論理的な外部キー」は、constraintsで物理的なリンクを持たない別のテーブルのキーを参照する値であるという前提を使用して、物理リンクの利点を教えてください。

まず、「物理」外部キーは制約であり、2つの値の間に参照整合性を強制します。たとえば、他のテーブルに存在しない外部キーを使用する場合は、エラーが発生します。別のテーブルの制約によって外部キーであるキーを削除しようとすると、同じことが起こります。

第2に、外部キーの制約にインデックスを付けることができ、たとえばジョインを使用するときなどに恩恵を受けることができるため、より最適であると言えるでしょう。この上

より：http://msdn.microsoft.com/en-us/library/ff647793.aspx