121

この例は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。これは正しいです？

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

9 に答える 9

128

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

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

別の方法は、たとえばこの場合、生成された（インテリジェントではない）主キーを使用することOrderDetailIdです。しかし、そうすると、関係が必ずしも簡単にわかるとは限りません。一部の人々は一方向を好みます。他の方法を好む人もいます。

于 2010-04-12T23:53:55.860 に答える
29

複合主キーのもう1つの例は、関連付けテーブルの使用法です。一連の人を含む個人テーブルと、一連のグループを含むグループテーブルがあるとします。今、あなたは人とグループに多対多の関係を作りたいと思っています。つまり、各人は多くのグループに属することができます。複合主キーを使用すると、テーブル構造は次のようになります。

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))
于 2010-04-13T00:11:47.147 に答える
10

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

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

1234     Jobs
1234     Gates

参考資料：主キーに関する優れた討論、またはGoogleだけでなく、このSOの質問meaningless primary keysを熟読することもできます。

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

于 2010-04-14T22:33:14.437 に答える
4

複数の属性の組み合わせの一意性を確保したい場合は常に、複合キー（複数の属性を持つキー）を使用します。単一の属性キーでは同じことはできません。

于 2010-11-23T14:09:09.837 に答える
3

はい、両方とも主キーを形成します。特に代理キーがないテーブルでは、各レコードの一意の識別子として複数の属性を指定する必要がある場合があります（悪い例：名と姓の両方を持つテーブルでは、それらの組み合わせが必要になる場合があります）個性的）。

于 2010-04-12T23:54:56.980 に答える
3

一般に、キー内の複数の列は、代理キーよりもパフォーマンスが低下します。代理キーを使用してから、複数列のキーに一意のインデックスを作成することをお勧めします。そうすれば、パフォーマンスが向上し、必要な一意性が維持されます。さらに良いことに、そのキーの値の1つが変更された場合、215個の子テーブルの100万個の子エントリを更新する必要もありません。

于 2010-11-22T20:16:01.867 に答える
3

2番目の質問

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

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

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

于 2017-01-19T11:47:28.053 に答える
2

リレーショナルデータベースで中間テーブルを使用している場合は、複数のテーブルで主キーを使用すると便利です。

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

2番目の表は「文字」でした—それらの名前と簡単な説明。主キーは「charname」にありました。

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

于 2016-09-11T12:02:55.553 に答える
1

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

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

于 2019-08-08T20:14:39.133 に答える