Почему использование несколько столбцов как первичные ключи (составляют первичный ключ),
Этот пример взят от 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 ответа
Вы правильно поняли.
Вы поступили бы так во многих случаях. Одним из примеров является взаимосвязь типа OrderHeader и OrderDetail . PK в OrderHeader может быть OrderNumber . PK в OrderDetail может быть OrderNumber И LineNumber . Если бы это был один из этих двух, он не был бы уникальным, но их комбинация гарантированно уникальна.
Альтернативой является использование сгенерированного (неинтеллектуального) первичного ключа, например, в этом случае OrderDetailId . Но тогда вы не всегда будете видеть отношения так легко. Некоторые люди предпочитают один путь; некоторые предпочитают другой путь.
Да, они оба образуют первичный ключ. Особенно в таблицах, где у вас нет суррогатного ключа , может потребоваться указать несколько атрибутов в качестве уникального идентификатора для каждой записи (плохой пример: таблица с именем и фамилией может потребовать их сочетание должно быть уникальным).
В примере W3Schools не говорится, когда следует использовать составные первичные ключи, а дается только пример синтаксиса с использованием той же примерной таблицы, что и для других ключей.
Их выбор примера, возможно, вводит вас в заблуждение, комбинируя бессмысленный ключ (P_Id) и естественный ключ (LastName). Этот странный выбор первичного ключа говорит о том, что следующие строки действительны в соответствии со схемой и необходимы для однозначной идентификации учащегося. Интуитивно это не имеет смысла.
1234 Jobs
1234 Gates
Дополнительная литература: Великие дебаты о первичных ключах или просто Google бессмысленные первичные ключи или даже внимательно изучите этот SO вопрос
FWIW - Мои 2 цента - избегать многостолбцовые первичные ключи и использовать одно сгенерированное поле идентификатора (суррогатный ключ) в качестве первичного ключа и при необходимости добавлять дополнительные (уникальные) ограничения.
Другим примером составных первичных ключей является использование таблиц Association. Предположим, у вас есть таблица 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))