テーブルのすべての列を含む主キーの利点はありますか？

4つの列がすべてNULL不可のテーブルがあり、一意のレコードを区別するには4つすべてが必要なデータです。これは、主キーを作成する場合、すべての列を構成する必要があることを意味します。テーブルに対するクエリは、ほとんどの場合、単一のレコードをプルバックします。つまり、クエリですべての列がフィルタリングされます。

すべての列を検索する必要があるため、主キーを持つことは（レコードの一意性を強制することに加えて）まったく私に利益をもたらしますか？

あなたの場合、これらのフィールドは自然なキーです。

代理キー：

代理キーは、「ビジネス」の意味を持たないキーであり、テーブル内のレコードを識別するためにのみ使用されます。このようなキーは、データベース生成（例：SQL ServerのID、Oracleのシーケンス、DB2 UDBのシーケンス/ IDなど）またはシステム生成値（スキーマのテーブルを介して生成されるなど）です。

ナチュラルキー：

キーが表す属性がデータベーススキーマとは無関係に識別に使用される場合、キーは自然です。これが基本的に意味することは、人々がそれらを使用する場合、キーは自然であるということです。例：請求書番号、納税者番号、SSNなど。

主キーの代理キーと自然キー

サロゲートキーを追加して、ビジネスモデル管理とデータベースモデル管理を分離することを好みます。他の質問は、主キーでクラスター化インデックスと非クラスター化インデックスを使用することです。テーブルを変更する場合（非静的テーブル、集中的に挿入または更新する）、非単調増加キーでクラスター化インデックスを使用する場合、パフォーマンスの問題が発生します。

通常、このような状況ではサロゲートキーを使用することをお勧めします。そのため、他のテーブルの外部キー（および、http（s）要求が参照するクエリ文字列で実行される場合など、外部に保存されるレコード参照）行のデータが変更されても変更されません。これを行うと、それが主キーになります。

このようなサロゲートキーを追加しない場合、4つの列すべてを主キーとしてアクセスするデータをどのように記述するかを考えると不利ではありません。キーをテーブルのクラスター化インデックスにすると、特定の行のデータを検索するためにディスク上のBツリーに1つのレベルがあるため、そのような要求に役立ちます。

主キーとしての複合キーは、ディスク使用量、io速度、およびバックアップに影響を与える可能性のあるインデックスサイズの問題にも直面します。主キーとクラスター化インデックスに関するKimberly Trippの投稿をここで確認できます。http：//www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again！.aspx

私もこの場合、自然なキーの代わりに代理キーを提案します。

2列だけの多対多のリレーションシップを表すテーブルがある場合、それは妥当なようです。

Cf. このSO質問

ただし、そのような場合でも代理キーを追加することは認めます。