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



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




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

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

886   8  

8 ответов:

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

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

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

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

1234     Jobs
1234     Gates

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

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

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

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

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

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

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

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

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


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

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

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

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

Comments

    Ничего не найдено.