Который является наиболее распространенным идентификационным типом в базах данных SQL Server, и который лучше?
Лучше использовать Гуид (UniqueIdentifier) в качестве Вашего столбца Primary / Surrogate Key или сериализированного целочисленного столбца "идентификационных данных"; и почему это лучше? Под которыми обстоятельствами Вы выбрали бы один по другому?
8 ответов
Я лично использую INT IDENTITY для большинства моих первичных и кластерных ключей.
Вам необходимо разделить первичный ключ, который является логической конструкцией - он уникально идентифицирует ваши строки, он должен быть уникальным и стабильным, а НЕ НУЛЬШИМ. GUID хорошо работает и для первичного ключа - так как он гарантированно будет уникальным. GUID в качестве первичного ключа - хороший выбор, если вы используете репликацию SQL Server, так как в этом случае вам все равно потребуется колонка с уникальной идентификацией GUID.
Кластерный ключ в SQL Server - это физическая конструкция, которая используется для физического упорядочивания данных, и которую намного сложнее получить правильно. Как правило, Королева индексирования на SQL Server, Кимберли Трипп, также требует хорошего ключа кластеризации, чтобы быть uniqe, стабильным, как можно более узким, а в идеале постоянно увеличивающимся (что является INT IDENTITY).
См. ее статьи по индексированию здесь:
- GUID в качестве ПРАЙМАРНЫХ ключей и/или кластерингового ключа
- Дебаты о кластеринговом индексе продолжаются...
- Постоянно увеличивающийся кластеринговый ключ - Дебаты о кластеринговом индексе..........again!
GUID - это действительно плохой выбор для кластерингового ключа, так как он широкий, абсолютно случайный, и, таким образом, приводит к плохой фрагментации индекса и плохой производительности. Кроме того, строка(и) ключа кластеризации также хранится в каждой записи каждого некластеризованного (дополнительного) индекса, так что вы действительно хотите, чтобы он был небольшим - GUID - 16 байт против INT - 4 байта, а с несколькими некластеризованными индексами и несколькими миллионами строк, это делает огромную разницу.
В SQL Server, ваш первичный ключ по умолчанию ваш кластеризованный ключ - но это не обязательно должно быть. Вы можете легко использовать GUID в качестве вашего некластеризованного первичного ключа, и INT IDENTITY в качестве вашего кластеризирующего ключа - для этого нужно только немного знать об этом.
В SQL Server, ваш первичный ключ по умолчанию является вашим кластерируемым ключом - но это не обязательно.Используйте GUID в реплицированной системе, где необходимо гарантировать уникальность.
Использовать ints, где у вас есть не реплицированная база данных и вы хотите максимизировать производительность.
.Очень редко используют GUID.
Используют скорее первичный ключ/заменитель ключа при хранении.
Также это облегчит взаимодействие человека с данными.
Создание индексов также будет намного эффективнее.
Смотрите
При рассмотрении использования целых чисел обязательно учитывайте максимально возможное значение. Часто из-за удаления пропускаются числа, поэтому фактический максимальный ID может быть значительно больше, чем общее количество записей в таблице.
Например, если вы не уверены, что 32-битное целое число подойдет, используйте 64-битное целое число.
Вы также можете найти эти другие обсуждения SO полезными:
Как вам нравятся ваши первичные ключи?
Какова лучшая практика использования первичных ключей в таблицах?
Выбор лучшего первичного ключа + система нумерации.
И если вы найдете здесь, в SO, "первичный ключ", то вы найдете эти и многие другие очень полезные обсуждения.
.На это нет ни одного ответа. Проблемы, которые люди быстро решают с помощью Guid's (что их случайная природа в сочетании с поведением первичного ключа по умолчанию , также действующего как кластерный ключ), могут быть легко смягчены. Guids имеют больший диапазон, чем целые числа, но когда вы начинаете заполнять этот диапазон значениями, вы увеличиваете риск столкновения.
Guids может быть очень полезен, когда у вас распределенная система (например, реплицированные базы данных), в которой нетривиальный объем работы должен пойти в механизм генерации ключей, который не вызовет столкновений между частями системы. Точно так же целые числа полезны, потому что они просты в использовании (каждый язык имеет интегральный тип, не каждый язык имеет тип Guids) и могут быть последовательными (Guids тоже может, но это не их предназначение использование).
Всё дело в том, что и как вы храните. Люди, которые говорят "никогда не используйте Guid's!", просто распространяют FUD, но они также не являются ответом на каждую проблему.
.Я думаю, что это почти всегда сериализованное целое число, но некоторые не согласятся. Это зависит от ситуации.
Причины идентичности - эффективность и простота. Она меньше. Проще индексировать. Он делает большим кластерным индексом. Меньше фрагментации по мере того, как новые записи сохраняются в порядке. Отлично подходит для индексов по соединениям. Легче, когда глазные записи в дб
Определенно есть место для Индексов при определенных обстоятельствах. При слиянии разрозненных данных или при необходимости создания записей в определенных местах. Рекомендации должны быть в вашем пакете трюков, но обычно не являются вашим первым выбором
.Используйте GUID, если вы думаете, что вам когда-нибудь понадобится использовать данные вне базы данных, т.е. других баз данных). Кто-то будет спорить, что это всегда так, но это вызов суда.
Эта тема часто обсуждается, но я склонен больше склоняться к личностям по нескольким причинам. Во-первых, целое число составляет всего 4 байта против 16-байтного GUID. Это означает более узкие индексы и более эффективные запросы. Во-вторых, мы используем @@IDENTITY и SCOPE_IDENTITY много в хранимых проках и т.д., которые выходят в окно с GUID.
Вот небольшая хорошая статья Джеффа Атвуда.
.