複数の列を主キーとして使用する理由（複合主キー）

この例はw3schoolsからの引用です。

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

私の理解では、両方の列（P_IdおよびLastName）は一緒にテーブルの主キーを表しますPersons。これは正しいです？

• なぜ誰かが単一の列ではなく複数の列を主キーとして使用したいのですか？
• 特定のテーブルで主キーとして一緒に使用できる列の数はいくつですか？

あなたの理解は正しいです。

多くの場合、これを行います。1つの例は、OrderHeaderおよびのような関係OrderDetailです。のPKはかもOrderHeaderしれませんOrderNumber。PKの中にはOrderDetailあるかもしれないOrderNumberとLineNumber。これらの2つのうちのいずれかである場合、それは一意ではありませんが、2つの組み合わせは一意であることが保証されます。

代わりに、この例では、生成された（インテリジェントではない）主キーを使用しますOrderDetailId。しかし、その関係を常に簡単に理解できるとは限りません。一部の人々は一方通行を好みます。一部は他の方法を好む。

複合主キーのもう1つの例は、関連テーブルの使用です。一連の人々を含むpersonテーブルと一連のグループを含むgroupテーブルがあるとします。次に、人とグループに多対多の関係を作成します。各人が多くのグループに属することができることを意味します。複合主キーを使用した場合のテーブル構造は次のようになります。

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

W3Schoolsの例は、複合主キーをいつ使用するべきかを示しておらず、他のキーと同じサンプルテーブルを使用した構文例のみを示しています。

それらの例の選択は、おそらく無意味なキー（P_Id）と自然キー（LastName）を組み合わせることによって、誤解を招く可能性があります。主キーのこの奇妙な選択は、次の行はスキーマに従って有効であり、学生を一意に識別するために必要であることを示しています。これは直感的には意味がありません。

1234     Jobs
1234     Gates

参考資料：優れた主キーの討論、または単にGoogle、meaningless primary keysまたはこのSOの質問を熟読する

FWIW-私の2セントは、複数列の主キーを回避し、単一の生成されたIDフィールド（代理キー）を主キーとして使用し、必要に応じて（一意の）制約を追加することです。

複数の属性の組み合わせの一意性を確保する必要がある場合は常に、複合キー（複数の属性を持つキー）を使用します。単一の属性キーは同じことを達成しません。

はい、どちらも主キーを形成します。特にサロゲートキーがないテーブルでは、各レコードの一意の識別子として複数の属性を指定する必要がある場合があります（悪い例：名と姓の両方を持つテーブルでは、ユニーク）。

キーの複数の列は、通常、代理キーよりもパフォーマンスが低下します。私は代理キーを用意し、次に複数列キーに一意のインデックスを作成することを好みます。これにより、パフォーマンスが向上し、必要な独自性が維持されます。さらに、そのキーの値の1つが変更された場合、215の子テーブルの100万の子エントリを更新する必要もありません。

2番目の質問

特定のテーブルで主キーとして一緒に使用できる列の数はいくつですか？

実装固有です。使用されている実際のDBMSで定義されています。^{[1]、[2]、[3]}使用するデータベースシステムの技術仕様を検査する必要があります。非常に詳細なものもあれば、そうでないものもあります。用語が異なるため、このような制限についてウェブを検索するのは難しい場合があります。複合主キーという用語は必須です;）

明示的な情報が見つからない場合は、テストデータベースを作成して、制限違反（予想される）の安定した（および特定の）処理を期待できることを確認してください。これに関する正しい情報を取得するように注意してください。制限が累積される場合があり、データベースレイアウトが異なると、異なる結果が表示されます。

• ^[1] sql-複合主キーの制限？- スタックオーバーフロー
• ^[2] SQL Server-主キーごとの最大列
• ^[3] Oracle 9iおよび10gのテーブルの主キーに含めることができる列の最大数はいくつですか？

複数のテーブルで主キーを使用すると、リレーショナルデータベースで中間テーブルを使用するときに便利です。

例として作成したデータベース、具体的にはそのテーブル内の3つのテーブルを使用します。数年前にウェブコミック用のデータベースを作成しました。1つのテーブルは「コミック」と呼ばれ、すべてのコミック、それらのタイトル、画像ファイル名などのリストです。主キーは「コミック」でした。

2番目のテーブルは「キャラクター」で、その名前と簡単な説明です。主キーは「charname」でした。

いくつかの例外を除いて、各コミックには複数のキャラクターがあり、各キャラクターは複数のコミックに登場したため、「キャラクター」または「コミック」のいずれかに列を入れてそれを反映することは実際的ではありませんでした。代わりに、"comicchars"と呼ばれる3つ目のテーブルを作成しました。これは、どのキャラクターがどのコミックに登場したかを示すリストでした。このテーブルは基本的に2つのテーブルを結合したため、charnameとcomicnumの2つの列が必要でしたが、主キーは両方にありました。

単一のレコードを構成する一意性の列値を保証するために、複合主キーを作成します。これは、重複してはならないデータの挿入を防ぐための制約です。

例：すべての学生IDと出生証明書番号が1人に一意に割り当てられている場合。次に、個人の主キーを学生IDと出生証明書番号の組み合わせにすることをお勧めします。これにより、異なる学生IDと同じ出生証明書を持つ2人を誤って挿入することが防止されるためです。