Почему единственный первичный ключ лучше, чем составные ключи?

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

Как правило, я использую сгенерированные идентификаторы для сущностей и составные ключи для отношений.

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

Традиционная теория реляционных баз данных в основном имеет дело с «естественными» ключами (теми, которые имеют значение с точки зрения бизнес-области), и в этом сценарии часто встречаются составные ключи ... естественно.

Но в более поздние годы при проектировании базы данных предпочтение было отдано (хотя и не исключительно) «искусственному» (суррогатному) ключевому шаблону, обычно последовательному номеру, не имеющему никакого коммерческого значения, только служащему для однозначной идентификации записи в таблице (и возможно объект в верхнем слое).

1. Для ORM проще использовать один идентифицирующий столбец с постоянным именем, например table_id, чем составной ключ . Но каждая хорошая ORM поддерживает составные ключи .

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

3. Простой PK также проще использовать в запросах . Когда вам нужно присоединиться, вы должны использовать только один столбец обоих отношений .

Это не означает, что простые ПК лучше составных.

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

Ну, в основном речь идет о том, чтобы СОЕДИНЕНИЯ оставались простыми - какой из них проще понять:

SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c on c.ParentID = p.ID

или

SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c ON c.ParentName = p.Name
     AND c.ParentCity = p.City
     AND c.ParentCountry = p.Country

Если у вас есть составные первичные ключи, любой присоединяющийся в вашу таблицу из дочерней таблицы должны «перетаскивать» все эти столбцы, и все эти столбцы также будут присутствовать в дочерней таблице, а операторы JOIN довольно беспорядочные. Намного лучше иметь единственный (даже суррогатный) ключ для JOIN!

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

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

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

Единственное реальное ограничение, которое я столкнулись с использованием составных ключей относительно использования выражения IN с подзапросом. Это проблема, потому что подзапрос в выражении IN должен возвращать один столбец (по крайней мере, в T-SQL).

SELECT
    emp.Name,
    emp.UserDomain,
    emp.UserID
FROM
    employee emp
WHERE
    ???? IN (SELECT e.UserDomain, e.UserID FROM ... /* some complex 
                                                       non-correlated subquery 
                                                       or CTE */
            )

Конечно, всегда есть обходные пути, но иногда это может раздражать.

Это вряд ли повод избегать составного ключа там, где его имеет смысл использовать.

Я работал над приложением с первичным ключом из 11 столбцов. Всегда было очень весело набирать список снова и снова, каждый раз, когда я хотел гарантировать, что обновляю одну строку.Это был драйвер ошибок, MS-Access не мог справиться с более чем 10 столбцами в PK и т. Д.

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