[解決済み] SQL - 多対多のテーブルの主キー

質問

この質問に対するコメントを読んでの質問です。

データベース設計

多対多のテーブルを作成する場合、2 つの外部キー列に複合主キーを作成すべきか、または自動インクリメントの代理主キー "ID"を作成し、2 つの FK 列にインデックスを置くだけ（そしておそらくユニーク制約も）でしょうか。 それぞれのケースで、新しいレコードの挿入や再インデックス付けのパフォーマンスにはどのような影響があるのでしょうか？

基本的には、これです。

PartDevice
----------
PartID (PK/FK)
DeviceID (PK/FK)

vs これ

PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)

とコメントされています。

2つのIDをPKにすることは、テーブルがディスク上で物理的にソートされることを意味します。 テーブルがディスク上で物理的にソートされることを意味します。 でソートされることを意味します。つまり、もし (Part1/Device1)、(Part1/Device2), (Part2/Device3)、(Part1/Device3)の順で挿入すると を挿入すると、データベースはテーブルを分割して テーブルを分割し、最後の1つを挿入する必要があります。 を挿入する必要があります。多くの 多くのレコードでは、これは非常に問題になります。 数百、数千、数百万のレコードをシャッフルすることになるので 何百、何千、何万というレコードを シャッフルすることになる。これに対して 自動インクリメントのPKでは、新しいレコードを最後に追加することができます。 のレコードは最後に追加されます。

私が質問している理由は、サロゲート自動インクリメント列のない複合プライマリキーを常に行うように傾いているからです。

どのように解決するのですか?

単純な2列の多対多のマッピングでは、代理キーを持つことの本当の利点はないと思います。に主キーを持つことは (col1,col2) に主キーを持つことは、一意性が保証されます (あなたの col1 と col2 の値は一意です)。 (col2,col1) に対する別のインデックスは、逆の順序の方が速く実行されるようなケースを捕捉します。サロゲートはスペースの無駄です。

テーブルは参照される2つのテーブルを結合するためだけに使用されるため、個々のカラムに対するインデックスは必要ありません。

あなたが質問で言及したそのコメントは、私の意見では、それが使用する電子の価値がありません。著者は、テーブルが非常に高いパフォーマンスのバランスのとれた多方向木構造ではなく、配列に格納されていると考えているように聞こえます。

まず第一に、テーブルを格納したり、あるいは テーブル をソートする必要はなく、インデックスだけです。そして、インデックスが 格納される に格納されるのではなく、素早く取り出せるように効率的な方法で格納されます。

さらに、データベースのテーブルの大部分は、読み込まれた はるか よりも頻繁に読み込まれます。そのため、select 側で行うことは、insert 側で行うことよりもはるかに関連性が高くなります。