Зачем использовать несколько столбцов в качестве первичных ключей (составной первичный ключ)

Этот пример взят из 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. Это верно?

• Зачем кому-то нужно использовать несколько столбцов в качестве первичных ключей вместо одного столбца?
• Сколько столбцов можно использовать вместе как первичный ключ в данной таблице?

Ваше понимание правильное.

Вы бы сделали это во многих случаях. Один пример - такие отношения, как OrderHeaderи OrderDetail. ПК OrderHeaderможет быть OrderNumber. PK в OrderDetailможет быть OrderNumberAND LineNumber. Если бы это был один из этих двух, он не был бы уникальным, но их комбинация гарантированно уникальна.

Альтернативой является использование сгенерированного (неинтеллектуального) первичного ключа, например, в этом случае OrderDetailId. Но тогда вы не всегда будете видеть отношения так легко. Некоторые люди предпочитают один путь; некоторые предпочитают другой путь.

Другой пример составных первичных ключей - использование таблиц ассоциаций. Предположим, у вас есть таблица людей, содержащая набор людей, и таблица групп, содержащая набор групп. Теперь вы хотите создать отношения «многие-ко-многим» как для человека, так и для группы. Это означает, что каждый человек может принадлежать ко многим группам. Вот как будет выглядеть структура таблицы с использованием составного первичного ключа.

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 цента - избежать использования первичных ключей с несколькими столбцами и использовать одно сгенерированное поле идентификатора (суррогатный ключ) в качестве первичного ключа и добавить дополнительные (уникальные) ограничения, где это необходимо.

Вы используете составной ключ (ключ с более чем одним атрибутом) всякий раз, когда хотите гарантировать уникальность комбинации нескольких атрибутов. Один ключ атрибута не приведет к тому же самому.

Да, они оба образуют первичный ключ. В частности, в таблицах, где у вас нет суррогатного ключа , может потребоваться указать несколько атрибутов в качестве уникального идентификатора для каждой записи (плохой пример: таблица с именем и фамилией может потребовать, чтобы их комбинация была уникальный).

Несколько столбцов в ключе, как правило, будут работать хуже, чем суррогатный ключ. Я предпочитаю иметь суррогатный ключ, а затем уникальный индекс для многоколоночного ключа. Таким образом вы можете повысить производительность и сохранить необходимую уникальность. И даже лучше, когда одно из значений в этом ключе изменяется, вам также не нужно обновлять миллион дочерних записей в 215 дочерних таблицах.

Ваш второй вопрос

Сколько столбцов можно использовать вместе как первичный ключ в данной таблице?

зависит от реализации: он определен в реальной используемой СУБД. ^{[1], [2], [3]} Вам необходимо ознакомиться с технической спецификацией используемой вами системы баз данных. Некоторые из них очень подробны, некоторые нет. Поиск в Интернете таких ограничений может быть затруднен, поскольку терминология меняется. Термин составной первичный ключ должен быть обязательным;)

Если вы не можете найти явную информацию, попробуйте создать тестовую базу данных, чтобы убедиться, что вы можете ожидать стабильной (и конкретной) обработки нарушений пределов (которых и следовало ожидать). Будьте осторожны, чтобы получить правильную информацию об этом: иногда ограничения накапливаются, и вы увидите разные результаты с разными макетами базы данных.

• ^[1] sql - ограничение составного первичного ключа? - Переполнение стека
• ^[2] SQL Server - максимальное количество столбцов на первичный ключ
• ^[3] Сколько максимальное количество столбцов может быть частью первичного ключа в таблице в Oracle 9i и 10g?

Использование первичного ключа для нескольких таблиц удобно, когда вы используете промежуточную таблицу в реляционной базе данных.

Я буду использовать базу данных, которую я когда-то сделал, в качестве примера и, в частности, три таблицы в этой таблице. Несколько лет назад я создал базу данных для веб-комикса. Одна таблица называлась «комиксы» - список всех комиксов, их названия, имена файлов изображений и т. Д. Первичный ключ - «комиксы».

Во второй таблице были «персонажи» - их имена и краткое описание. Первичный ключ был на charname.

Поскольку в каждом комиксе - за некоторыми исключениями - было несколько персонажей, и каждый персонаж появлялся в нескольких комиксах, было непрактично помещать столбец в «персонажи» или «комиксы», чтобы отразить это. Вместо этого я создал третью таблицу под названием «comicchars», и это был список того, какие персонажи появлялись в каких комиксах. Поскольку эта таблица по существу объединяла две таблицы, ей требовалось всего два столбца: charname и comicnum, и первичный ключ был на обоих.

Мы создаем составные первичные ключи, чтобы гарантировать уникальность значений столбцов, составляющих единую запись. Это ограничение, которое помогает предотвратить вставку данных, которые не должны дублироваться.

то есть: если все идентификаторы учащихся и номера свидетельств о рождении однозначно присвоены одному человеку. Тогда было бы неплохо сделать первичный ключ для человека, состоящим из идентификатора студента и номера свидетельства о рождении, потому что это предотвратит случайную вставку двух людей с разными идентификаторами учащихся и одним и тем же свидетельством о рождении.