Причины не использовать автоинкрементное число для первичного ключа

Question

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

Каковы преимущества использования такого метода (или просто создания идентификатора GUID) вместо простого использования идентификатора / автоматического номера?

Я не говорю о первичных ключах, которые на самом деле «означают» что-то вроде ISBN или кодов продуктов, просто уникальные идентификаторы.

Спасибо.

Answer 1

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

Answer 2

Единственная причина, по которой я могу думать, это то, что код был написан до того, как sequences был изобретен, и код забыл догнать;)

Answer 3

Ответ Галвегяна не обязательно верен.

С MySQL вы можете установить смещение ключа для каждого экземпляра базы данных. Если вы объедините это с достаточно большим приращением, это будет хорошо. Я уверен, что у других поставщиков будут какие-то похожие настройки.

Допустим, у нас есть 2 базы данных, которые мы хотим скопировать. Мы можем настроить его следующим образом.

increment = 2
db1 - offset = 1
db2 - offset = 2

Это означает, что

db1 будет иметь ключи 1, 3, 5, 7 ....

db2 будет иметь ключи 2, 4, 6, 8 ....

Поэтому у нас не будет столкновения клавиш на вставках.

Answer 4

Моя основная проблема с автоматически увеличивающимися клавишами заключается в том, что у них нет никакого значения.

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

Answer 5

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

Одним из недостатков GUID PK является то, что соединения в поле GUID выполняются медленнее (если только это не изменилось в последнее время). Еще одним преимуществом использования идентификаторов GUID является то, что забавно попытаться объяснить нетехническому менеджеру, почему конфликт GUID маловероятен.

Answer 6

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

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