хорошо ли иметь первичные ключи в качестве поля идентификации

Question

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

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

Answer 1

Пробелы не должны иметь значения: столбец идентификаторов является внутренним и не предназначен для использования или распознавания конечным пользователем.

GUID снизит производительность, даже последовательную, из-за ширины 16 байт.

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

Или вы используете ORM и позволяете клиентскому хвосту вилять собакой базы данных ...

Answer 2

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

Answer 3

Я хотел бы сказать, что это зависит от ваших потребностей. Мы используем только Guids в качестве первичных ключей (с установленным по умолчанию NewID), потому что мы разрабатываем распределенную систему со многими экземплярами Sql Server, поэтому мы должны быть уверены, что каждый Sql Server генерирует уникальные значения первичного ключа. Но при использовании столбца Guid в качестве PK убедитесь, что не использует его в качестве кластерного индекса (спасибо marc_s за ссылку)

Преимущество типа Guid:

• Вы можете создавать уникальные значения в разных местах без синхронизации

Недостатки:

• Это большой тип данных (16 байт), который требует значительно больше места
• Создает фрагментацию индекса (по крайней мере, при использовании функции newid ())

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

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

Вам нужен первичный ключ типа int без пробелов? Обычно это не должно быть проблемой.

Answer 4

"да, это УБИВАЕТ производительность - полностью. Я перешел от устаревшей системы с GUID в виде PK / CK и фрагментации индекса 99,5% ежедневно к использованию INT IDENTITY - ОГРОМНАЯ разница. лучше. Идентификаторы GUID в качестве индекса кластеризации в вашей таблице SQL Server BAD BAD BAD - точка. "

Возможно, это правда, но я не вижу логических рассуждений, согласно которым это приводит меня к выводу, что GUID PER SE также являются BAD BAD BAD.

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