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

этот пример взят от 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. Правильно ли это?

  • почему кто-то хочет использовать несколько столбцов в качестве первичных ключей вместо одного столбца?
  • сколько столбцов можно использовать вместе в качестве первичного ключа в данной таблице?
90
database-design database-table ddl primary-key relational-database

8 ответов

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

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

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

101

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

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

их выбор примера, возможно, вводит вас в заблуждение, комбинируя бессмысленный ключ (P_Id) и естественный ключ (LastName). Этот нечетный выбор первичного ключа говорит о том, что следующие строки действительны в соответствии со схемой и необходимы для уникальной идентификации учащегося. Интуитивно это не делает чувство.

1234     Jobs
1234     Gates

Читайте Далее: великий первичный ключ дебаты или просто Google meaningless primary keys или даже прочитать это и

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

10

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

2

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

2

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

2

второй вопрос

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

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

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

2

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

Я буду использовать базу данных, которую я когда-то сделал для примера, и, в частности, три таблицы в этой таблице. Я creäted базы данных несколько лет назад на комикс. Одна таблица называется "комиксы"-список всех комиксов, их названия, имя файла и т. д. Первичным ключом был "comicnum".

вторая таблица была "символы"- их имена и краткое описание:. Первичный ключ был на "charname".

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

0