外部キーとしての複合主キーの効率

重複がテーブルに入力されないようにするために使用される複合主キー（4列で構成される）を持つテーブルがあります。このテーブルのキーを外部キーとして参照する必要がある新しいテーブルが必要になりました。

私の質問は、どのアプローチがルックアップ速度にとってより効率的かです：

1）4列すべてを含む新しいテーブルを作成し、それらをすべて外部キーで参照しますか。

または

2）主キーテーブルに新しいID列を作成し、これを新しいテーブルの外部キーとして使用しますか。

このデータベースは非常に大量のデータを保持することが期待されているため、各テーブルに保持されるデータ量を最小限に抑えることを目的として、これまで構築してきました。これを念頭に置いて、すべての行に2つのint列とdatetime列を保存するため、オプション2が最適なアプローチになりますが、不要な場合はルックアップ時間の増加を避けたいと思います。

単純な合成整数PKを使用するコストは小さく、この場合の利点はおそらくかなり大きいでしょう。

• あなたが指摘するように、あなたははるかに単純なFK関係を持つことになります。
• 小さいPKは、小さい（および高速の）インデックスになります。おそらく、このような列を追加することで、合計表スペースが少なくなります。
• ビジネスルールが変更された場合、テーブルを並べ替える必要はありません。

頭に浮かぶ唯一の重大な欠点は、複合PKでのクラスタリングの恩恵を受けたクエリのパフォーマンスが低下する可能性があることです。それが重要だと思われる場合は、複合候補キーでクラスタリングを続行するが、合成キーにPKを置くよりも。

SQLの世界ではよくあることですが、答えは「それは依存します」です。

いくつかのポインターについては、この質問をご覧ください。自然キーは、代理整数キーよりも高いまたは低いパフォーマンスをSQL Serverで提供しますか？

自然キーを外部キーとして使用すると、パフォーマンスが向上する場合があります。ただし、ほとんどの場合、より小さいキーを使用する方が適切です（代理キーを参照）。

そのIDENTITY列を導入する場合、私はそれを主キーにし、代わりに「自然な」列をUNIQUE CONSTRAINTに変更します。