GUID против INT IDENTITY [копия]

Question

  

Возможный дубликат:
   Как вам нравятся ваши первичные ключи?

Я знаю о преимуществах использования GUID, а также о преимуществах использования и INT в качестве PK в базе данных. Учитывая, что GUID - это, по сути, 128-битный INT, а нормальный INT - 32-битный, INT - это экономия пространства (хотя в большинстве современных систем этот вопрос, как правило, спорный).

В конце концов, при каких обстоятельствах вы увидите, что вы используете INT в качестве PK вместо GUID?

Answer 1

Кимберли Трипп (SQLSkills.com) имеет статья об использовании GUID в качестве первичных ключей. Она советует против этого из-за ненужных накладных расходов.

Answer 2

Помимо того, что вам нужно синхронизировать несколько экземпляров базы данных, у INT есть один недостаток, о котором я не упомянул: вставки всегда выполняются на одном конце дерева индексов. Это увеличивает конкуренцию за блокировку, когда у вас есть таблица с большим перемещением (поскольку одни и те же страницы индекса должны быть изменены одновременными вставками, тогда как GUID будут вставлены по всему индексу). Индекс также может потребоваться перебалансировать чаще, если используется дерево B * или аналогичная структура данных.

Конечно, int проще для глаз при выполнении ручных запросов и построении отчетов, и потребление пространства может увеличиться за счет использования FK.

Мне было бы интересно посмотреть, насколько хорошо, например, SQL Server на самом деле обрабатывает таблицы с высокой вставкой с IDENTITY PK.

Answer 3

Чтобы ответить на ваш вопрос: В конце концов, при каких обстоятельствах вы увидите, что вы используете INT в качестве PK вместо GUID?

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

Answer 4

  

INT - это экономия пространства (хотя это   точка, как правило, спорная в большинстве современных   систем).

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

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

Answer 5

У нас есть руководства в нашем очень сложном корпоративном программном обеспечении. Работает плавно.

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

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

Answer 6

При сравнении значений, таких как отношение первичного ключа к внешнему ключу, INT будет быстрее. Если таблицы проиндексированы должным образом, и таблицы маленькие, вы можете не увидеть большого замедления, но вам придется попробовать это, чтобы быть уверенным. ИНТ также легче читать и общаться с другими людьми. Гораздо проще сказать: «Можете ли вы взглянуть на запись 1234?» вместо " Можете ли вы посмотреть запись 031E9502-E283-4F87-9049-CE0E5C76B658? "

Answer 7

Некоторые операционные системы больше не генерируют идентификаторы GUID на основе уникальных аппаратных функций (CPUID, MAC), поскольку это облегчает отслеживание пользователей (проблемы конфиденциальности). Это означает, что уникальность GUID часто уже не так универсальна, как думают многие.

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

Answer 8

Если данные хранятся в одной базе данных (как и большинство данных для приложений, которые мы пишем в целом), тогда я использую IDENTITY . Он прост, предназначен для такого использования, не фрагментирует кластеризованный индекс и более чем достаточно. Вам не хватит места на 2 миллиарда записей (~ 4 миллиарда, если вы используете отрицательные значения), но в любом случае вы будете тостом, если у вас будет столько записей в одной таблице, а затем возникнет проблема с хранилищем данных.

Если данные хранятся в нескольких независимых базах данных или интерфейсах со сторонней службой, то я буду использовать GUID , который, вероятно, уже сгенерирован. Хорошим примером может служить таблица UserProfiles в базе данных, которая сопоставляет пользователей в Active Directory с их профилями пользователей в приложении через их objectGUID , назначенный им Active Directory.

Answer 9

Если вы планируете объединить базу данных на каком-то этапе, например, для установки типа репликации с несколькими сайтами, Guid избавит вас от многих проблем. Но кроме этого я считаю, что Int легче.

Answer 10

Я всегда думаю, что ПК должны быть числовыми, если это возможно. Не забывайте, что наличие GUID в качестве PK, вероятно, будет означать, что они также используются в других таблицах в качестве внешних ключей, поэтому подкачка, индексирование и т. Д. Будут более эффективными.

Answer 11

Я думаю, что база данных также имеет значение. С точки зрения MySQL - как правило, чем меньше тип данных, тем выше производительность.

Похоже, что это справедливо и для int vs GUID - http://kccoder.com/mysql/uuid-vs-int-insert -performance /

Answer 12

Я бы использовал GUID в качестве PK, только если этот ключ ограничен аналогичным значением. Например, идентификатор пользователя (пользователи в WinNT описываются с помощью GUID) или идентификатор группы пользователей. Еще один пример. Если вы разрабатываете распределенную систему управления документами и разные части системы в разных местах по всему миру, можете создавать некоторые документы. В таком случае я бы использовал GUID, потому что он гарантирует, что 2 документа, созданные в разных частях распределенной системы, не будут иметь одинаковый идентификатор.

Answer 13

INT, конечно, намного легче читать при отладке, и намного меньше.

Однако я бы использовал GUID или аналогичный в качестве лицензионного ключа для продукта. Вы знаете, что он будет уникальным, и вы знаете, что он не будет последовательным.