web-dev-qa-db-ja.com

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

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

私の質問は、どのアプローチがルックアップ速度に対してより効率的であるかです:

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

または

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

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

12
aaroncatlin

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

  • ご指摘のとおり、FK関係はより単純になります。
  • 小さなPKは、小さな(そして高速な)インデックスを作成します。このような列を追加することで、テーブルスペースの合計が少なくなる可能性があります。
  • ビジネスルールが変更されても、テーブルを並べ替える必要はありません。

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

11

SQLの世界ではよくあることですが、答えは「状況によって異なります」です。

いくつかのポインタについてこの質問をご覧ください: ナチュラルキーは、サロゲート整数キーよりもSQL Serverのパフォーマンスが高くなったり低くなったりしますか?

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

そのIDENTITY列を導入した場合、それを主キーにして、「自然な」列をUNIQUE CONSTRAINTに変更します。

5
Sebastian Meine