GUID по сравнению с ИДЕНТИФИКАЦИОННЫМИ ДАННЫМИ INT [дубликат]

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

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

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

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

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

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

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

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

We have Guids in our very complex enterprise software everywhere. Works smoothly.

I believe Guids are semantically more suitable to serve as identifiers. There is also no point in unnecessarily worrying about performance until you are faced with that problem. Beware premature optimization.

There is also an advantage with database migration of any sort. With Guids you will have no collisions. If you attempt to merge several DBs where ints are used for identity, you will have to replace their values. If these old values were used in urls, they will now be different following SEO hit.

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

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

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

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

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

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

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

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

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

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

An INT is certainly much easier to read when debugging, and much smaller.

I would, however, use a GUID or similar as a license key for a product. You know it's going to be unique, and you know that it's not going to be sequential.