これは、DB 設計に関する一般的な質問のようなものです。基本的に 2 つの FK 参照だけで構成されるレコードを含む関連エンティティ テーブル、つまり相互参照がある場合、何らかの方法でインデックスを作成する必要がありますか? 関連付けられたテーブルの PK は定義により既にインデックス付けされているため、そのテーブルに明示的にインデックス付けする必要がありますか? インデックスを付ける必要がある場合、2 つの FK フィールドを一緒に構成する組み合わせインデックスにする必要がありますか?
2 に答える
他のテーブルで参照されている pk 列のインデックスは、それをカバーしていません。
2 つの fk 列を「連想エンティティ」テーブルの複合主キーとして定義することにより(ほとんどの場合、関連付けが一意である場合)、複数列のインデックスを暗黙的に作成します。
これにより、両方または最初の列を含むすべてのクエリが最適にカバーされます。2 番目の列
のクエリについても説明しますが、効果的ではありません。
2 番目の列のみを含む重要なクエリがある場合は、その列にも追加のインデックスを作成します。
dba.SEのこの関連する質問で、トピックに関するすべての詳細をお読みください。
またはSO に関するこの質問 、このトピックもカバーしています。
連想テーブルに次のようなスキーマがあるとします。
CREATE TABLE Association
(
ReferenceA INTEGER NOT NULL REFERENCES TableA CONSTRAINT FK1_Association,
ReferenceB INTEGER NOT NULL REFERENCES TableB CONSTRAINT FK2_Association,
PRIMARY KEY(ReferenceA, ReferenceB) CONSTRAINT PK_Association
);
DBMS がいくつかのインデックスを自動的に作成する可能性があります。
一部の DBMS は、2 つの外部キーのそれぞれに対してインデックスを作成し、主キーに対しても一意のインデックスを作成します。PK インデックスは ReferenceA へのアクセスにも使用できるため、これは少し無駄です。
理想的には、参照 B の PK (一意) インデックスと (重複が許可されている) FK インデックスの 2 つだけのインデックスが存在することになります。PK インデックスの最初の列が ReferenceA であると仮定します。
参照整合性制約を適用するために DBMS が自動的にインデックスを作成しない場合は、RI または FK の重複許可インデックスを作成する必要があります。PK 制約を適用するためのインデックスが自動的に作成されない場合は、その一意のインデックスも作成する必要があります。利点は、理想的なケースのインデックスのみを作成することです。
DBMS によっては、制約なしでテーブルを作成し、次にインデックスを追加し、次に制約を追加する方が効果的である場合があります (作成したインデックスが使用されます)。断片化スキームなどもこれに影響を与える可能性があります。上記は無視しました。
概念はシンプルのままです。合計 2 つのインデックスが必要です。1 つは両方の列に一意性を適用し、先頭の列に高速アクセスを提供し、末尾の列には一意でないインデックスまたは重複が許可されたインデックスを提供します。