Какой тип идентификатора является наиболее распространенным в базах данных SQL Server, а какой лучше?

Question

Лучше ли использовать Guid (UniqueIdentifier) ​​в качестве столбца первичного / суррогатного ключа или сериализованного целочисленного столбца «идентификатор»; и почему лучше? При каких обстоятельствах вы бы предпочли одно другому?

Answer 1

Я лично использую INT IDENTITY для большинства моих первичных ключей и ключей кластеризации.

Вам необходимо отделить первичный ключ , который является логической конструкцией - он уникально идентифицирует ваши строки, он должен быть уникальным, стабильным и НЕ ПУСТО. GUID также хорошо работает для первичного ключа - поскольку он гарантированно будет уникальным. GUID в качестве первичного ключа является хорошим выбором, если вы используете репликацию SQL Server, поскольку в этом случае вам все равно необходим уникальный идентификатор столбца GUID.

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

Смотрите ее статьи по индексации здесь:

• GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключа кластеризации
• Дебаты по кластерным индексам продолжаются ...
• Постоянно увеличивающийся ключ кластеризации - дебаты по кластерному индексу .......... снова!

GUID - это действительно плохой выбор для ключа кластеризации, поскольку он широкий, абсолютно случайный и, следовательно, приводит к плохой фрагментации индекса и низкой производительности. Кроме того, строки ключей кластеризации также хранятся в каждой записи каждого некластеризованного (дополнительного) индекса, так что вы действительно хотите сохранить его небольшим - GUID равен 16 байтам, тогда как INT равен 4 байтам, и с несколькими некластеризованными индексами и несколькими миллионами строк это делает ОГРОМНОЕ различие.

В SQL Server ваш первичный ключ по умолчанию является вашим ключом кластеризации, но это не обязательно. Вы можете легко использовать GUID в качестве первичного ключа, не относящегося к кластеру, и INT IDENTITY в качестве ключа кластеризации - для этого достаточно немного осознать его.

Answer 2

Используйте GUID в реплицируемой системе, где вам нужно гарантировать уникальность.

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

Answer 3

Очень редко используйте GUID.

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

Также это облегчит взаимодействие человека с данными.

Создание индексов также будет намного более эффективным.

См

• Как влияет использование GUID в SQL Server Индекс производительности
• Влияние производительности на использование GUID в качестве первичных ключей

Answer 4

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

Например, если вы не уверены, что подойдет 32-разрядное целое число, используйте 64-разрядное целое число.

Вам также могут пригодиться эти другие обсуждения SO:

Как вам ваши первичные ключи?

Как лучше всего использовать первичные ключи в таблицах?

Выбор лучшего первичного ключа + система нумерации.

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

Answer 5

Я считаю, что это почти всегда сериализованное целое число идентификаторов, но некоторые не согласятся. Это зависит от ситуации.

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

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

Answer 6

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

Руководства могут быть очень полезны, когда у вас есть распределенная система (например, реплицированные базы данных), где нетривиальный объем работы должен включать механизм генерации ключей, который не вызовет коллизии между частями системы. , Аналогично, целые числа полезны, потому что они просты в использовании (у каждого языка есть целочисленный тип, не у каждого языка есть тип Guid) и могут быть последовательными (Guids тоже может, но это не их предназначенное использование ).

Это все о том, что вы храните и как. Люди, которые говорят "никогда не используйте Guid's!" просто распространяют FUD, но они также не являются решением всех проблем.

Answer 7

Это часто обсуждаемая тема, но я склонен больше склоняться к идентичности по нескольким причинам. Во-первых, целое число составляет всего 4 байта против 16-байтового GUID. Это означает более узкие индексы и более эффективные запросы. Во-вторых, мы используем @@IDENTITY и SCOPE_IDENTITY много в хранимых процессах и т. Д., Что выходит из окна с GUID.

Вот хорошая маленькая статья Джеффа Этвуда .

Answer 8

Используйте GUID, если считаете, что вам когда-нибудь понадобится использовать данные вне базы данных, то есть в других базах данных). Некоторые утверждают, что это всегда так, но это призыв к суждению.