GUID против INT IDENTITY

Question

Можно создать дубликат:
How do you like your primary keys?

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

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

Answer 1

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

Answer 2

INT, безусловно, гораздо легче читать при отладке и намного меньше.

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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

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

Answer 11

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

Answer 12

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

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

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

Answer 13

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

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

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