долго против Guid для Id (Entity), каковы плюсы и минусы - PullRequest
Новая
       31

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

13 голосов
/ 09 февраля 2010

Я делаю веб-приложение на asp.net mvc и выбираю между типом данных long и Guid для своих сущностей, но я не знаю, какой из них лучше. Некоторые говорят, что долго намного быстрее. Guid также может иметь некоторые преимущества. Кто-нибудь знает?

Ответы [ 3 ]

18 голосов
/ 09 февраля 2010

Когда GUID может быть неуместным

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

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

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

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

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

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

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

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

Мой совет

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

3 голосов
/ 09 февраля 2010

Размер: Длинный 8 байт Guid составляет 16 байт

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

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

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 ='

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

Взгляните сюда

2 голосов
/ 09 февраля 2010

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

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

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

...