Productテーブル、Orderテーブル、および（ジャンクションテーブル）ProductOrderがあるとします。
ProductOrderには、ProductIDとOrderIDがあります。
ほとんどのシステムでは、これらのテーブルにはIDと呼ばれる自動番号列もあります。
主キー（およびそのためにクラスター化されたキー）を配置するためのベストプラクティスは何ですか？
IDフィールドの主キーを保持し、外部キーペア（ProductIDとOrderID）の非クラスター化インデックスを作成する必要があります
または、外部キーペアの主キー（ProductIDとOrderID）を配置し、ID列に非クラスター化インデックスを配置する必要があります（必要な場合でも）
または...（あなたの一人による賢い発言:)）
私はこれらの言葉があなたをうんざりさせるかもしれないことを知っています、しかし「それは依存します」。
自動番号はデータベースで自然な意味を持たないため、自動番号（代理）列ではなく、ProductIDまたはOrderId、あるいはその両方に基づいて注文することが最も可能性があります。親テーブルと同じフィールドで結合テーブルを並べ替えることができます。
まず、代理キーIDを使用している理由と方法を最初に理解します。多くの場合、インデックスを作成する方法が決まります。単一列キーで適切に機能するフレームワークを使用しているため、代理キーを使用していると思います。特定の設計上の理由がない場合は、結合テーブルの場合、問題を単純化し、自動番号IDを削除するだけで、他にメリットがない場合は削除します。主キーは（ProductID、OrderID）になります。そうでない場合は、少なくとも（ProductID、OrderID）タプルのインデックスが一意であることを確認して、データの整合性を維持する必要があります。
クラスター化インデックスは、クエリがインデックスの順序と同じ順序で結果を必要とする場合の順次スキャン/結合に適しています。したがって、アクセスパターンを確認し、シーケンシャルな複数行の選択/スキャンを実行するキーと、ランダムな個別の行アクセスを実行するキーを特定し、クラスター化されたインデックスを作成します。最もスキャンするキー、およびランダムアクセスに使用するキーの非クラスター化キーインデックス。両方をクラスター化することはできないため、どちらか一方を選択する必要があります。
注：要件が矛盾する場合は、役立つ可能性のある手法（「トリック」）があります。クエリのすべての列がインデックスで見つかった場合、そのインデックスは、クエリの要件を満たすために使用するデータベースエンジンの候補テーブルです。このファクトを使用して、データが互いに競合している場合でも、データを複数の順序で格納できます。インデックスにフィールドを追加することの長所と短所に注意し、処理されるクエリの性質と頻度を理解した後、意識的に決定してください。
正解は次のとおりです。
('orderid' , 'productid')('productid' , 'orderid')なぜなら：
orderidインデックスをオンにする必要はありませんproductid。オプティマイザーはインデックスの1つを使用します。これは、多くの注文が追加される動的システムの場合のようです。したがって、クラスター化インデックスは自動番号付けされた列にある必要があります。
インデックスを主キーにして、列のペアに別の一意のインデックスを付けることができます。または、列のペアをプライマリ（ただしクラスター化されていない）キーにすることもできます。
主キーまたは一意のインデックスキーのどちらを使用するかはあなた次第です。ただし、クラスター化されているのは自動番号列用であることを確認します。
私の好みは常に主キーの自動番号を作成することでした。次に、2つの外部キーに一意のインデックスを作成して、それらが重複しないようにします。
これを行う理由は、データを正規化すればするほど、結合で使用する必要のあるキーが増えるためです。最終的にデザインの深さは6〜7レベルになり、あるレベルから別のレベルに流れるキーを使用すると、結合にn^2個のキーが含まれる可能性があります。
私のSQL開発者に、それらすべてを1つのクエリに使用するように説得してみてください。そうすれば、彼らは私を本当に気に入ってくれるでしょう。
シンプルにしています。