Использовать uuid в качестве первичного и / или суррогатного ключа?

Question

Мы должны добавить UUID в большинство наших объектов и таблиц базы данных.

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

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

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

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

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

В этом смысле UUID не является типичнымсуррогатный ключ (?).

Answer 1

Вы немного все перепутаете.

1) Есть два определения суррогатных ключей

Суррогат (1)

Это определение основано на том, что дано Холлом, Оулеттом и Тоддом (1976). Здесь суррогат представляет собой сущность во внешнем мире. Суррогатный внутренне генерируется системой, но тем не менее виден пользователю или приложение.

Суррогатное (2)

Это определение основано на определении Wieringa and De Jonge (1991). Здесь суррогат представляет объект в самой базе данных. Суррогат внутренне генерируется системой и невидим для пользователя или применение.

Суррогатное (1) определение определяет его использование в модели данных скорее чем модель хранения и используется в Эта статья. См. Дата (1998).

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

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

2) Ваша логика для рассмотрения естественных ключей UUID очень скользкая

цитата из вашего вопроса:

Я бы посмотрел UUID больше как естественный ключ, потому что он может служить та же цель, что и номер счета: обратиться к конкретному аккаунту в уникальный и неизменный способ.

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

Естественный ключ - это ключ-кандидат, который имеет логическое отношение к атрибуты в этой строке. Естественный ключ иногда называют ключом домена.

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

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

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