Почему не стоит использовать идентификатор сущности как первичный ключ в базе?

Question

[Tetragramatron]

Вопрос появился при проектировании БД, хранящей некоторые объекты. Каждый из этих объектов (некоторое устройство) имеет свой глобально уникальный идентификатор (назовём его domain id), представляющий собой строку длины символов в 40, и этот идентификатор содержит в себе определённое знание предметной области.
Интуитивно я понимаю что при хранении набора этих объектов в таблице лучше использовать отдельное целочисленное поле в качестве primary key, но при обсуждениях с напарником аргументов кроме
1. семантика primary key и domain id разная, не надо её путать,
2. база будет быстрее оперировать целочисленными ключами а не строковыми (но это заявление не проверялось) и
3. копчиком чую это плохая идея
у меня нет.
Объекты создаются довольно редко, запрашиваются весьма часто, идентификаторы используются и в других службах этой системы и в других таблицах.

Коллеги, подкиньте аргументов или опровергните мои доводы (особенно третий).

Comments

[Tetragramatron]

Да, это django-модель поэтому мы не особо ограничены ORM-соглашением по именованию первичных ключей.

Answer 1

[nekipelov]

Primary key должно быть то поле, которое явлется идентификатором, используемым для выборки. Зачем делать в качестве primary key целочисленный идентификатор, если строка идентифицируется и запрашивается по domain id? Только лишний идекс. Если же можно делать выбору по целому числу, то конечно же его следует добавить и использовать вместо domain id.

Answer 2

[trerums]

www.ozon.ru/context/detail/id/7598812
Глава 4

Answer 3

[artyomst]

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

Answer 4

[svd71]

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

Замечания @sebres очень даже имеют место. Многие СУБД конструируются на оптимальную работу именно с числовыми полями целого типа (хотя некоторые и позволяют использовать при желании в качестве ключа так называемый GUID - именно символьного типа). Сомневаюсь, что например MySQL имеет оптимизацию при работе с целочисленным типом: достаточно посмотреть на представление его целочисленных данных в таблице - они представлены в виде текста, а не конвертированы в 8 или 16 байтовое значение. Соотвествено сервер либо сам проводит посимвольное сравнение, либо предварительно конвертирует значение в "истинный", машинный int, что тоже сказывается на скорости. Вывод: нужно узнать, что производительней использовать для вашей СУБД.

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