Неплохо ли использовать GUID в качестве первичных ключей в MS SQL?

Ответ 1

Есть плюсы и минусы:

Эта статья охватывает все.

GUID Pros

• Уникально для каждой таблицы, каждой базы данных, каждого сервера
• Позволяет легко объединять записи из разных баз данных.
• Позволяет легко распределять базы данных на нескольких серверах.
• Вы можете создавать идентификаторы в любом месте, вместо того, чтобы совершать кругооборот в базу данных
• В большинстве сценариев репликации требуются столбцы GUID в любом случае

Недостатки GUID

• Это 4 раза больше, чем традиционное 4-байтовое значение индекса; это может иметь серьезные последствия для производительности и хранения, если вы не будете осторожны.
• Громоздко отлаживать (где userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Сгенерированные идентификаторы GUID должны быть частично последовательными для обеспечения максимальной производительности (например, newsequentialid() в SQL 2005) и для включения кластеризованных индексов

Ответ 2

Я написал сообщение об этой прошлой неделе с некоторым кодом, чтобы показать вам, что происходит: Простой код, чтобы показать разницу между Newid и Newsequentialid

В принципе, если вы используете newid() вместо Newsequentialid(), вы получаете ужасные разбиения страниц, если ваш PK является кластеризованным индексом (который будет по умолчанию)

Ответ 3

Лично я использую int или bigint для PK, но просто помещаю в другой столбец "Guid" для тех ситуаций, где вам нужен неопознанный "ключ" для этой записи, и генерировать Guid, когда вы вставляете строку.

Ответ 4

Это будет плохо, если вам нужно будет присоединяться к большим наборам (скажем, 100 000-х). Был там, пострадал.

Позднее Edit: я также столкнулся с еще худшей ошибкой (не могу назвать это "подход" ): сохранение GUID в столбцах char (36)!

Ответ 5

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

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

Ответ 6

Джимми Нильссон написал фантастическую статью о GUIDs против INTs и комбинированных GUIDS. Выводы... не бойтесь GUID... а также составных гидов в любом случае.

Ответ 7

Это "плохая" идея. Это может быть медленным. Вы не очень хороши для быстрого поиска с индексами. Единственное реальное время, когда мы используем GUID или UniqueID, - это когда мы должны хранить элементы данных, связанные между базами данных, как правило, когда у нас есть серверная база данных и локальная база данных для приложения (для отключенных систем). У вас действительно нет другого способа держать вещи вместе, кроме гидов. Для индексов и первичных ключей вы хотите использовать целочисленное значение и пытаться связать вещи с таблицами ассоциаций, а не использовать подсказки повсюду.

Ответ 8

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

Ответ 9

Плохо, если вы хотите быстро записывать в базу данных. Если вы собираетесь делать массивные вставки, лучше использовать другой тип данных.

Ответ 10

Он также может действительно замедлить чтение базы данных, поскольку первичные ключи создаются с помощью кластеризованных индексов, если не указано иное. Гид - худший тип, который будет иметь ваш кластеризованный индекс, а int или bigint будет служить лучшим первичным ключом или кластеризованным индексом

Ответ 11

Я бы не сказал его bad, как таковой. Я говорил со многими людьми, которые клянутся этим, хотя я нахожу это немного подробным. Я бы согласился с routeNpingme и сказал, что вы должны использовать регулярное целое число для ID, но также включать GUID (который вам нужен для репликации в любом случае) "на всякий случай"

Ответ 12

Если вы делаете какие-либо репликации базы данных, то GUID - ваш лучший друг!