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

Question

Почему отказ от составных ключей в пользу всех таблиц с использованием одного первичного ключа с именем id? Потому что вообще все ORM следуют этому.

EDIT

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

EDIT2 Также проверьте эту ссылку. Я получаю все больше и больше запутывается об этой вещи: --- Composite primary keys versus unique object ID field

Из приведенной выше ссылке: -

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

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

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

EDIT: есть дополнительная проблема, более практичная, чем философская. Во многих случаях вы каким-то образом найдете определенную строку, затем позже обновите ее или снова найдете (или и то, и другое). С составными ключами есть больше данных, чтобы отслеживать и больше ограничений в предложении WHERE для повторного поиска или обновления (или удаления). Также возможно, что один из ключевых сегментов может измениться за это время !. С суррогатный ключ, всегда существует только одно значение, чтобы сохранить (суррогатной ID) и по определению, он не может изменить, что значительно упрощает ситуацию. *

Answer 1

Я не думаю, что есть общее утверждение, что вы должны использовать только один первичный ключ с именем id.

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

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

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

Answer 2

1. Для ОРМ единой идентификации колонки с Такое согласованное имя, как table_id проще, чем составной ключ. Но каждая хорошая поддержка ORM составные клавиши.

2. Простой PK может быть легко 'autoincremented' от базы данных. Это не относится к составной клавише .

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

Это не означает, что простые PK лучше, чем композитные.

Answer 3

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

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

Answer 4

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

Answer 5

Ну, это в основном о сохранении JOIN и просто - какой из них проще понять:

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!

Answer 6

Единственное реальное ограничение, с которым я столкнулся, используя составные ключи, используя выражение 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 */ 
      ) 

Всегда есть обходные пути, но иногда это может быть неприятно.

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

Answer 7

Ваш вопрос сильно связан с альтернативой surrogate (or artificial) keys vs natural keys. Я думаю, что дело не в том, что составные ключи менее используются, но что натуральный ключей (будь то композитный или простой) менее предпочтительны, чем искусственный ключей.

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

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

Answer 8

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

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

Answer 9

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

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

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