Составные первичные ключи по сравнению с полем ID уникального объекта

71
задан Brian 16 February 2012 в 15:05
поделиться

14 ответов

Большинство наиболее часто используемых механизмов (SQL Server MS, Oracle, DB2, MySQL, и т.д.) не испытало бы значимые проблемы с помощью системы суррогатного ключа. Некоторые могут даже испытать повышение производительности от использования суррогата, но проблемы производительности являются очень определенными для платформы.

В общих чертах, естественный ключ (и следовательно, составной ключ) дебаты суррогатного ключа стихов имеют долгую историю без вероятного “right answer” в поле зрения.

аргументы в пользу естественных ключей (исключительный или составной) обычно включают некоторых следующее:

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

2) Они избавляют от необходимости определенные соединения. , Например, если у Вас есть клиенты с потребительскими кодами и счета с номерами счетов-фактур (оба из которых являются "естественными" ключами), и Вы хотите получить все номера счетов-фактур для определенного потребительского кода, можно просто использовать "SELECT InvoiceNumber FROM Invoice WHERE CustomerCode = 'XYZ123'". В классическом подходе суррогатного ключа выглядел бы примерно так SQL: "SELECT Invoice.InvoiceNumber FROM Invoice INNER JOIN Customer ON Invoice.CustomerID = Customer.CustomerID WHERE Customer.CustomerCode = 'XYZ123'".

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

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

1) Они включают более легкие изменения в атрибутах, когда бизнес-требования/правила изменяются. Это вызвано тем, что они позволяют атрибутам данных быть изолированными к единственной таблице. Это - прежде всего, проблема для механизмов SQL, которые эффективно не реализуют стандартные конструкции SQL, такие как ДОМЕНЫ. Когда атрибут определяется оператором DOMAIN, изменения в атрибуте могут быть выполнены использование всей схемы оператора ALTER DOMAIN. Различные механизмы SQL имеют различные рабочие характеристики для изменения домена, и некоторые механизмы SQL не реализуют ДОМЕНЫ вообще, таким образом, средства моделирования данных компенсируют эти ситуации путем добавления суррогатных ключей для улучшения способности внести изменения в атрибуты.

2) Они включают упрощенные внедрения параллелизма, чем естественные ключи. В естественном ключевом случае, если два пользователя одновременно работают с тем же информационным набором, таким как потребительская строка, и один из пользователей изменяет естественное значение ключа, то обновление вторым пользователем перестанет работать, потому что потребительский код, который они больше не обновляют, существует в базе данных. В случае суррогатного ключа обновление обработает успешно, потому что неизменные Значения идентификаторов используются для идентификации строк в базе данных, не изменяемых потребительских кодов. Однако не всегда желательно позволить второе обновление †“, если потребительский код изменился, возможно, что второму пользователю нельзя разрешить возобновить их изменение, потому что фактический “identity” строки изменился, †“второй пользователь может обновлять неправильную строку. Ни суррогатные ключи, ни естественные ключи, собой, не решают эту проблему. Всесторонние решения для параллелизма должны быть обращены за пределами реализации ключа.

3) Они работают лучше, чем естественные ключи. Производительность наиболее непосредственно затронута механизмом SQL. Та же схема базы данных, реализованная на тех же аппаратных средствах с помощью различных механизмов SQL, будет часто иметь существенно различные рабочие характеристики, из-за хранения данных механизмов SQL и механизмов извлечения. Некоторые механизмы SQL тесно приближают системы плоского файла, где данные на самом деле хранятся избыточно, когда тот же атрибут, такой как Потребительский Код, появляется в нескольких местах в схеме базы данных. Этот накопитель большой емкости механизмом SQL может вызвать проблемы производительности, когда изменения должны быть внесены в данные или схему. Другие механизмы SQL обеспечивают лучшее разделение между моделью данных и устройством хранения данных/поисковой системой, допуская более быстрые изменения данных и схемы.

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

я склонен падать на сторону естественных ключей (очевидно), но я не фанатичен об этом. Из-за среды я работаю в, где любая данная база данных, которую я помогаю разработать, может использоваться множеством приложений, я использую естественные ключи для большинства моделирования данных, и редко представляю суррогаты. Однако я don’t стараюсь изо всех сил пытаться повторно реализовать существующие базы данных то использование суррогаты. Системы суррогатного ключа работают просто великолепно †“никакая потребность изменить что-то, что уже функционирует хорошо.

существуют некоторые превосходные ресурсы, обсуждая достоинства каждого подхода:

http://www.google.com/search?q=natural+key+surrogate+key

http://www.agiledata.org/essays/keys.html

http://www.informationweek.com/news/software/bi/201806814

88
ответ дан PhD 24 November 2019 в 12:55
поделиться

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

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

Таким образом Вы могли бы иметь:

CREATE TABLE dbo.Invoice (
  CustomerId varchar(10),
  CustomerOrderNo varchar(10),
  InvoiceAmount money not null,
  Comments nvarchar(4000),
  RowId uniqueidentifier not null default(newid()),

  primary key(CustomerId, CustomerOrderNo)
)

, Таким образом, Ваш DBA счастлив, Ваш архитектор ORM счастлив, и Ваша целостность БД сохраняется!

1
ответ дан Keith Williams 24 November 2019 в 12:55
поделиться

спасибо @JeremyDWill

за обеспечение некоторого весьма необходимого баланса к дебатам. В частности, благодарит за информацию о DOMAIN с.

я на самом деле использую суррогатные ключи в масштабе всей системы ради непротиворечивости, но там включенные компромиссы. Наиболее распространенная причина для меня для проклятия суррогатных ключей использования состоит в том, когда у меня есть таблица поиска с коротким списком канонического values—, я использовал бы меньше пространства, и все мои запросы будут короче/легче/быстрее, если я только что сделал значения PK вместо того, чтобы иметь необходимость соединить с таблицей.

1
ответ дан Hank Gay 24 November 2019 в 12:55
поделиться

..., как база данных обрабатывает поля ID неэффективным способом и когда она создает индексы, древовидные виды испорчены...

Это было почти наверняка ерундой, но, возможно, имело отношение к выпуску индексной конкуренции блока при присвоении постепенного увеличения чисел PK на высоком показателе от различных сессий. Раз так тогда ОБРАТНЫЙ КЛЮЧЕВОЙ индекс там для помощи, хотя за счет большего индексного размера из-за изменения в разделенном на блок алгоритме. http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref998

Идет синтетический продукт, особенно если он помогает более быстрой разработке с Вашим комплектом инструментальных средств.

2
ответ дан David Aldridge 24 November 2019 в 12:55
поделиться

Я собираюсь быть коротким и милым здесь: Составные первичные ключи не хороши в эти дни. Добавьте в суррогатных произвольных ключах, если Вы можете и поддерживать текущие ключевые схемы через ограничения на уникальность данных. ORM счастлив, Вы - счастливый, исходный программист not-so-happy, но если он не Ваш босс тогда, он может просто иметь дело с ним.

3
ответ дан MattC 24 November 2019 в 12:55
поделиться

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

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

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

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

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

2
ответ дан Richard Harrison 24 November 2019 в 12:55
поделиться

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

4
ответ дан 24 November 2019 в 12:55
поделиться

Я в основном - член команды суррогатного ключа, и даже если я ценю и понимаю аргументы, такие как те представленные здесь JeremyDWill, я все еще ищу случай, где "естественный" ключ лучше, чем суррогат...

Другие сообщения, занимающиеся этой проблемой обычно, обращаются к теории реляционной базы данных и производительности базы данных. Другой интересный аргумент, о котором всегда забывают в этом случае, связан с [1 122] нормализация таблицы и производительность кода :

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

  1. идентификация его первичного ключа и его физических характеристик (тип, размер)
  2. запоминание этих характеристик каждый раз, когда я хочу обратиться к нему в своем коде?
  3. объяснение моего выбора PK другим разработчикам в команде?

Мой ответ не ко всем этим вопросам:

  1. я не имею ни одной лишней секунды, пытаясь определить "лучший Первичный ключ" при контакте со списком людей.
  2. я не хочу помнить, что Первичный ключ мой" computer" таблица является 64 длинными строками символов (делает Windows, признает что много символов для имени компьютера?).
  3. я не хочу объяснять свой выбор другим разработчикам, где один из них наконец скажет "Да человека, но полагать, что необходимо управлять компьютерами по различным доменам? Эти 64 строки символов позволяют Вам хранить доменное имя + имя компьютера?".

, Таким образом, я работал в течение прошлых пяти лет с очень простым правилом: каждая таблица (позволяют нам назвать его' myTable') имеет свое первое поле, названное' id_MyTable', который имеет uniqueIdentifier тип. Даже если эта таблица поддерживает "many-many" отношение, такой как' ComputerUser' таблица, где комбинация' id_Computer' и' id_User' формы очень приемлемый Первичный ключ, я предпочитаю создавать этот' id_ComputerUser' поле, являющееся uniqueIdentifier, только придерживаться правила.

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

я не уверен, что мое правило является лучшим. Но это - очень эффективное!

5
ответ дан Michiel de Mare 24 November 2019 в 12:55
поделиться

Используя 'уникальный (объектный) идентификатор' поля упрощает соединения, но необходимо стремиться иметь другой (возможно составной объект), ключ, все еще уникальный - НЕ ослабляет не - пустые ограничения и ДЕЙСТВИТЕЛЬНО поддерживает ограничение на уникальность данных.

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

5
ответ дан Jonathan Leffler 24 November 2019 в 12:55
поделиться

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

я никогда не слышал ни о каких проблемах с B-деревьями на полях ID, но я также не изучил его ни в какой большой глубине...

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

11
ответ дан Powerlord 24 November 2019 в 12:55
поделиться

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

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

  • , если ключ не будет бессмыслен, то это, более вероятно, изменится, т.е. не будет постоянно; посмотрите выше

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

РЕДАКТИРОВАНИЕ: существует дополнительная проблема, которая более практична, чем философский. Во многих случаях Вы собираетесь найти конкретную строку так или иначе, тогда более позднее обновление это или найти его снова (или оба). С составными ключами существует больше данных, чтобы отслеживать и больше ограничений в операторе Where для перенаходки или обновления (или удалить). Также возможно, что один из ключевых сегментов, возможно, изменился тем временем!. С суррогатным ключом всегда существует только одно значение для сохранения (суррогатный идентификатор), и по определению это не может измениться, который значительно упрощает ситуацию.

22
ответ дан Steven A. Lowe 24 November 2019 в 12:55
поделиться

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

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

33
ответ дан Darrel Miller 24 November 2019 в 12:55
поделиться

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

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

естественные pk имеют свою мотивацию и сценарий использований и не являются плохой вещью (TM), они просто имеют тенденцию не быть в хороших отношениях с ORM.

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

3
ответ дан Lorenzo Boccaccia 24 November 2019 в 12:55
поделиться

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

Формат внешние данные могут изменяться со временем. Например, вы можете подумать, что ISBN книги будет хорошим первичным ключом в таблице книг. В конце концов, номера ISBN уникальны. Но пока пишется эта конкретная книга, издательская индустрия в Соединенных Штатах готовится к серьезным изменениям, поскольку ко всем ISBN добавляются дополнительные цифры. Если бы мы использовали ISBN в качестве первичного ключа в таблица книг, нам придется обновить каждую строку, чтобы отразить это изменение. Но тогда у нас возникнет другая проблема. В базе данных будут и другие таблицы, которые ссылаются на строки в таблице books через первичный ключ. Мы не сможем изменить ключ в таблице книг, пока не пройдем и не обновим все эти ссылки. И это будет включать в себя снятие ограничений внешнего ключа, обновление таблиц, обновление таблицы книг и, наконец, восстановление ограничений. В общем, это что-то вроде боли. Проблемы исчезнут, если мы будем использовать собственное внутреннее значение в качестве первичного ключа. Никакая третья сторона не может прийти и произвольно сказать нам изменить нашу схему - мы контролируем собственное пространство ключей. И если что-то, например, ISBN, действительно необходимо изменить, это может измениться, не затрагивая ни одну из существующих взаимосвязей в базе данных. По сути, мы отделили объединение строк от внешнего представления данных в этих строках.

Хотя объяснение довольно книжное, но я думаю, что оно объясняет вещи проще.

2
ответ дан 24 November 2019 в 12:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: