Описание тега surrogate-key

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

Терминология

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

Свойства суррогатных ключей

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

Таким образом, инженерное решение заключается не в сравнении суррогатного ключа и естественного ключа, а в сравнении с суррогатным + естественным ключом и одним естественным ключом.

Наличие суррогатного ключа + естественный ключ:

  • Может сделать ИНОСТРАННЫЕ КЛЮЧИ в дочерних таблицах более тонкими. 2
  • Суррогат никогда не нужно менять, и поэтому он никогда не подвергается ссылочному действию ON UPDATE CASCADE.
  • Может быть более дружественным к инструментам объектно-реляционного сопоставления (ORM).

Имея только естественный ключ:

  • Делает родительский стол тоньше. 3
  • Может лучше работать с кластеризацией.4
  • В некоторых ситуациях может сделать JOIN ненужным. 5
  • Может понадобиться для корректного моделирования некоторых видов ромбовидных зависимостей. Например, следующая модель гарантирует, что если B и C подключены к одному D, они также должны быть подключены к одному A:

    введите описание изображения здесь

    Обратите внимание на то, как A_ID распространяется от вершины "ромба" вниз по обеим сторонам, а затем объединяется внизу.

Типичные реализации суррогатных ключей

Чаще всего суррогатный ключ реализуется как автоматически увеличивающееся целое число. Примеры:

  • Oracle поддерживает объект SEQUENCE, который можно использовать либо непосредственно в операторе INSERT, либо через триггер ON INSERT.
  • MS SQL Server имеет тип данных IDENTITY, а с версии 2012 года также явный объект SEQUENCE.
  • PostgreSQL поддерживает явный объект SEQUENCE, а также последовательные типы, которые неявно используют последовательности.
  • MySQL имеет атрибут AUTO_INCREMENT.

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


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

2 Суррогаты обычно используют "более тонкие" типы данных, такие как целые числа, по сравнению с "более толстыми" типами, такими как строки, которые часто используются в естественных ключах. Кроме того, хотя составной ключ не является необычным, почти никогда не бывает причин для создания составного суррогатного ключа. Как следствие, FOREIGN KEY, ссылающийся на суррогатный ключ, имеет тенденцию быть тоньше, чем FK, ссылающийся на естественный ключ.

3 Нет необходимости в дополнительном индексе "под" суррогатным ключом. Каждый новый индекс требует затрат на обслуживание операций INSERT/UPDATE/DELETE и может быть особенно дорогостоящим в кластеризованных таблицах, где вторичные индексы обычно должны содержать копию ключа кластеризации (который часто совпадает с первичным ключом) и может повлечь за собой двойное копирование. поиск во время запроса.

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

5 Мы можем получить перенесенный естественный ключ прямо из дочерней таблицы, без СОЕДИНЕНИЯ с родительской.