Почему бы не всегда использовать GUID вместо целочисленных идентификаторов?

Question

Каковы недостатки использования GUID? Почему бы не всегда использовать их по умолчанию?

Answer 1

Целые числа присоединяются намного быстрее, например. Это особенно важно при работе с миллионами строк.

Для двоих GUID занимают больше места, чем целые числа. Опять же, очень важно иметь дело с миллионами строк.

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

Более подробное описание можно найти здесь и в блоге Джеффа .

Answer 2

GUID прекрасны с точки зрения программиста - они гарантированно (почти) уникальны, так почему бы не использовать их повсюду, верно?

Если вы посмотрите на это с точки зрения администратора баз данных и с точки зрения базы данных, по крайней мере, для SQL Server, есть несколько вещей, которые следует учитывать:

• Идентификаторы GUID в качестве первичного ключа (который отвечает за уникальную идентификацию одной строки в вашей таблице) могут быть в порядке - в конце концов, они уникальны, верно?
• однако, SQL Server также имеет концепцию ключа кластеризации, который физически упорядочивает данные в вашей таблице; если вы не знаете об этом и ничего не делаете явно, ваш первичный ключ становится вашим ключом кластеризации.

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

В частности, ее лучшие практики для ключа кластеризации:

• узкая
• статические
• уникальный
• постоянно увеличивающийся

GUID, как правило, являются статическими и уникальными, но они не являются ни узкими (16 байт против 4 байт для INT), ни постоянно увеличивающимися. Из-за своей природы они уникальны и (псевдо) случайны.

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

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

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

Марк

Answer 3

1. GUID в четыре раза больше, чем int, и в два раза больше, чем bigint.

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

Answer 4

Кимберли Л. Трипп: GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключа кластеризации

Читали ли вы соответствующие ссылки с правой стороны?

Answer 5

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

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

Answer 6

Этот ответ НЕ исключает идею использования INT в качестве первичного ключа. Это в основном предназначено, чтобы указать, КОГДА гид полезен.

ЗДЕСЬ БОЛЬШАЯ (КОРОТКАЯ) СТАТЬЯ:
http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html

Разъяснения ...
Я использую направляющие для любого (общего) типа сущности БД, который может потребоваться экспортировать или использовать совместно с другим экземпляром БД. Таким образом, у меня есть ДНК-маркер (то есть гид), который можно использовать для различения «похожих» объектов одного и того же типа сущности.

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

Answer 7

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

Answer 8

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

Answer 9

Самый большой удар по производительности, который вы увидите с GUID в качестве первичного / кластерного ключа, - это вставка записей в большие таблицы. Переиндексация может быть сложной задачей, так как ваш ключ упадет где-то посередине