Long vs Guid для Id (Entity), каковы плюсы и минусы

Ответ 1

Когда GUID могут быть несоответствующими

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

Также подумайте, целесообразно ли использовать "длинный". Это огромное количество. Вам это нужно только в том случае, если вы считаете, что в какой-то момент у вас может быть более 2 МИЛЛИАРОВ. Редко я их использую.

GUID также могут быть сложными для использования и отладки. Говоря, "проблема с записью клиента 10034, Фрэнк, пойти проверить" намного проще, чем сказать "есть проблема с {2f1e4fc0-81fd-11da-9156-00036a0f876a}..." Интс и длинны также легче для ввода в запросы, когда вам нужно.

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

Когда GUID могут быть подходящими

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

GUID также позволяют вам связывать объекты, не сохраняя их в базе данных, в определенных сценариях ORM. Linq to SQL (и я считаю, что EF) не имеют этой проблемы, хотя бывают случаи, когда вы можете отправить свои изменения в базу данных, чтобы получить ключ.

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

Мой совет

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

Ответ 2

Размер: Длинные 8 байт Guid - 16 байт

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

long (Identity in DB) может представлять собой уникальную запись в таблице, но у вас могут быть записи, представленные одним ID (Identity), в одной или нескольких разных таблицах, например:

TableA: PersonID int, name varchar(50)
TableB: ProductID int, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name =''

оба могут возвращать одинаковое значение, но в случае GUID:

TableA: PersonID uniqueidentifier, name varchar(50)
TableB: ProductID uniqueidentifier, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name ='

вы редко можете иметь то же значение, что и id, возвращаемый из двух таблиц

Посмотрите здесь

• SQL Server - Guid VS. Длинные
• GUID как PRIMARY KEYs и/или ключ кластеризации

Ответ 3

Гиды значительно упрощают создание "свежей" сущности в вашем API, потому что вы просто присваиваете ей значение Guid.NewGuid(). Там нет зависимости от автоматически увеличивающихся ключей из базы данных, поэтому это лучше отделяет модель домена от лежащего в основе механизма сохранения.

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

Другая проблема заключается в том, что, если вы выполняете выборки из такой базы данных без указания явного упорядочения, вы получаете результаты в существенно случайном порядке.