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