外部キーとしての複合主キーの効率
テーブルに重複が入力されないようにするために使用される複合主キー（4列で構成される）を持つテーブルがあります。現在、このテーブルのキーを外部キーとして参照する必要がある新しいテーブルが必要です。
私の質問は、どのアプローチがルックアップ速度に対してより効率的であるかです：
1）4つの列すべてを含む新しいテーブルを作成し、それらすべてを外部キーで参照しますか？.
または
2）主キーテーブルに新しいID列を作成し、これを新しいテーブルの外部キーとして使用しますか？.
このデータベースは非常に大量のデータを保持すると予想されるため、各テーブルに保持されるデータの量を最小限に抑えるために、これまでに構築してきました。これを念頭に置いて、すべての行に2つのint列とdatetime列を保存するので、オプション2が最善のアプローチですが、不要な場合はルックアップ時間の増加を避けたいです。
単純な合成整数PKを使用するコストは小さく、この場合の利点はおそらくかなり大きいでしょう。
- ご指摘のとおり、FK関係はより単純になります。
- 小さなPKは、小さな（そして高速な）インデックスを作成します。このような列を追加することで、テーブルスペースの合計が少なくなる可能性があります。
- ビジネスルールが変更されても、テーブルを並べ替える必要はありません。
頭に浮かぶ唯一の重大な欠点は、複合PKでのクラスタリングの恩恵を受けたクエリのパフォーマンスが低下する可能性があることです。それが重要であると思われる場合は、複合候補キーでクラスタリングを続行しますが、合成キーにはPKを配置します。
SQLの世界ではよくあることですが、答えは「状況によって異なります」です。
いくつかのポインタについてこの質問をご覧ください： ナチュラルキーは、サロゲート整数キーよりもSQL Serverのパフォーマンスが高くなったり低くなったりしますか？
自然キーを外部キーとして使用すると、パフォーマンスが向上する場合があります。ただし、ほとんどの場合、キーは小さい方が適切です（参照：代理キー）。
そのIDENTITY列を導入した場合、それを主キーにして、「自然な」列をUNIQUE CONSTRAINTに変更します。