Возможный дубликат:
Как вам нравятся ваши первичные ключи?
Я знаю о преимуществах использования GUID, а также о преимуществах использования и INT как ПК в базе данных. Учитывая, что GUID по существу представляет собой 128-битный INT, а обычный INT - 32 бит, INT - это заставка (хотя эта точка, как правило, спорна в большинстве современных систем).
В конце концов, в каких обстоятельствах вы видите, что используете INT как ПК против GUID?
Kimberley Tripp (SQLSkills.com) статью об использовании GUID в качестве первичных ключей. Она советует против этого из-за ненужных накладных расходов.
Помимо плохого выбора, когда вам нужно синхронизировать несколько экземпляров базы данных, INT имеет один недостаток, о котором я не упоминал: вставки всегда встречаются на одном конце дерева индексов. Это увеличивает конфликт блокировок, когда у вас есть таблица с большим количеством движения (поскольку одни и те же страницы индекса должны быть изменены с помощью параллельных вставок, тогда как GUID будет вставлен по всему индексу). Индекс также может быть перебалансирован чаще, если используется дерево B * или аналогичная структура данных.
Разумеется, int проще на глаза при выполнении ручных запросов и построении отчетов, а использование пространства может складываться через использование FK.
Мне было бы интересно увидеть любые измерения того, насколько хорошо, например. SQL Server фактически обрабатывает вставные таблицы с идентификационными номерами.
Чтобы ответить на ваш вопрос: В конце концов, в каких обстоятельствах вы бы увидели, что используете INT как ПК против GUID?
Я бы использовал GUID, если моя система будет иметь онлайн-версию в автономном режиме, которую можно сохранить в автономной версии данных, и эти данные будут отправлены на сервер в один прекрасный день во время синхронизации. Таким образом, вы уверены, что дважды не будете иметь один и тот же ключ в своей базе данных.
INT - это заставка (хотя это точка в целом спорна в большинстве современных систем).
Не так. Это может показаться на первый взгляд, но обратите внимание, что первичный ключ каждой таблицы будет повторяться несколько раз по всей базе данных в индексах и как внешний ключ в других таблицах. И он будет задействован почти в любом запросе, содержащем его таблицу, и очень интенсивно, когда он использует внешний ключ для соединения.
Кроме того, помните, что современные процессоры очень, очень быстрые, но скорости RAM не поддерживаются. Поэтому поведение кэша становится все более важным. И лучший способ получить хорошее поведение кэша - иметь меньшие наборы данных. Таким образом, кажущаяся несоответствующая разница между 4 и 16 байтами вполне может привести к заметной разнице в скорости. Не обязательно всегда - но это что-то учитывать.
У нас есть Гиды в нашем очень сложном корпоративном программном обеспечении во всем мире. Работает плавно.
Я считаю, что гиды семантически более подходят для использования в качестве идентификаторов. Также нет смысла излишне беспокоиться о производительности, пока вы не столкнетесь с этой проблемой. Остерегайтесь преждевременной оптимизации.
Существует также преимущество миграции базы данных любого типа. С гидами у вас не будет столкновений. Если вы попытаетесь объединить несколько БД, где ints используются для идентификации, вам придется заменить их значения. Если эти старые значения использовались в URL-адресах, они теперь будут отличаться от SEO-удара.
При сравнении значений, таких как отношение первичного к внешнему ключу, INT будет быстрее. Если таблицы проиндексированы правильно, а таблицы небольшие, вы можете не заметить большую часть замедления, но вам придется попробовать это, чтобы быть уверенным. INT также легче читать и общаться с другими людьми. Гораздо проще сказать: "Можете ли вы посмотреть на запись 1234?" вместо "Можете ли вы посмотреть на запись 031E9502-E283-4F87-9049-CE0E5C76B658?"
Некоторые ОС не генерируют GUID больше, основываясь на уникальных аппаратных функциях (CPUID, MAC), потому что это упростило пользователей трассировки (проблемы конфиденциальности). Это означает, что уникальность GUID часто уже не столь универсальна, как многие думают.
Если вы используете некоторую функцию auto-id вашей базы данных, база данных может теоретически убедиться, что дублирования нет.
Я всегда думаю, что PK должно быть числовым, где можно. Не забывайте, что идентификаторы GUID в качестве PK, вероятно, означают, что они также используются в других таблицах в качестве foriegn-ключей, поэтому подкачки и индекс и т.д. Будут больше.
Если данные хранятся в одной базе данных (как и большинство данных для приложений, которые мы пишем вообще), я использую IDENTITY. Это просто, предназначено для использования таким образом, не фрагментирует кластеризованный индекс и более чем достаточно. У вас закончится комната на 2 миллиарда записей (~ 4 миллиарда, если вы используете отрицательные значения), но вы все равно будете тосты, если бы у вас было столько записей в одной таблице, а затем у вас проблема с хранилищем данных.
Если данные хранятся в нескольких независимых базах данных или интерфейсах со сторонней службой, я буду использовать GUID, который, скорее всего, уже сгенерирован. Хорошим примером может служить таблица UserProfiles в базе данных, которая отображает пользователей в Active Directory в их профили пользователей в приложении через их objectGUID, назначенные им Active Directory.
Если вы планируете слияние базы данных на определенном этапе, то есть для настройки типа множественной репликации на нескольких сайтах, Guid сэкономит много боли. Но кроме этого я нахожу Int проще.
INT, конечно, гораздо легче читать при отладке и намного меньше.
Я бы, однако, использовал GUID или аналогично лицензионному ключу для продукта. Вы знаете, что это будет уникальным, и вы знаете, что это не будет последовательным.
Я думаю, что база данных также имеет значение. С точки зрения MySQL - как правило, чем меньше тип данных, тем быстрее производительность.
Кажется, это верно и для int vs GUID - http://kccoder.com/mysql/uuid-vs-int-insert-performance/
Я бы использовал GUID как PK только в том случае, если этот ключ ограничивается аналогичным значением. Например, идентификатор пользователя (пользователи в WinNT описываются с GUID) или идентификатор группы пользователей. Еще один пример. Если вы разрабатываете распределенную систему для управления документами и разные части системы в разных местах по всему миру, можете создать некоторые документы. В таком случае я бы использовал GUID, потому что он гарантирует, что у 2 документов, созданных в разных частях распределенной системы, не будет одинакового идентификатора.