Лучше использовать уникальный идентификатор (GUID) или bigint для столбца идентификации?

Question

Для сервера SQL лучше использовать уникальный идентификатор (GUID) или bigint для столбца идентификаторов?

Answer 1

Это зависит от того, что вы делаете:

• Если скорость - это главное, то старый int, вероятно, достаточно большой.
• Если у вас действительно будет более 2 миллиардов (с символом B;)), используйте bigint или последовательный указатель.
• Если вам нужно иметь возможность легко синхронизировать записи, созданные удаленно, то Guid действительно здорово.

Обновление
Некоторые дополнительные (менее очевидные) примечания по Guids:

• Они могут сильно повлиять на индексы, и это снижает производительность базы данных
• Вы можете использовать последовательные направляющие, чтобы вернуть некоторые показатели индексации, но отбросьте некоторую случайность, использованную во втором пункте.
• Направляющие могут быть сложны для отладки вручную (where id='xxx-xxx-xxxxx'), но вы также можете получить часть этого через последовательные направляющие (where id='xxx-xxx' + '123').
• По той же причине, Guids может сделать атаки на основе ID более сложными, но не невозможными. (Вы не можете просто набрать 'http://example.com?userid=xxxx' и ожидать получения результата для чужой учетной записи).

Answer 2

В общем, я бы рекомендовал BIGINT больше GUID (так как направляющие большие и медленные), но вопрос в том, нужно ли вам это? (Т.е. вы делаете репликацию?) Если вы ожидаете менее 2 миллиардов строк, традиционный INT будет в порядке.

Answer 3

Делаете ли вы репликацию или у вас есть продавцы, которые используют отключенные базы данных, которые должны объединиться, используйте GUID. В противном случае я бы пошел на Int или Bigint. С ними гораздо легче иметь дело в долгосрочной перспективе.

Answer 4

Если вы планируете использовать репликацию слиянием, тогда ROWGUIDCOL выгодно для производительности ( см. Здесь для информации ). В противном случае нам нужно больше информации о том, каково ваше определение «лучше»; лучше за что?

Answer 5

Не зависит от того, что вам нужно. DB Производительность выиграла бы от целого числа, в то время как GUID полезны для репликации и не требует от БД повторять, какая идентификация была создана, т.е. код может создать идентификатор GUID перед вставкой в ​​строку.

Answer 6

Может быть несколько аспектов или требований для использования GUID.

• Если первичный ключ имеет какой-либо числовой тип (Int, BigInt или любой другой), то вам нужно либо сделать его столбцом Identity, либо проверить последнее сохраненное значение в таблице.
• И в этом случае, если запись во внешней таблице сохраняется как транзакция, тогда будет трудно получить последнее значение идентификатора первичного ключа. Например, если используется IDENT_CURRENT, то снова будет влиять на производительность при сохранении записи во внешнем ключе.
• Таким образом, в случае сохранения записей как для транзакций, было бы удобно сначала сгенерировать Guid для первичного ключа, а затем сохранить сгенерированный ключ (Guid) в первичной и внешней таблицах.

Answer 7

Я с Эндрю Роллингсом.

Теперь вы можете утверждать, космическая эффективность. Int это что, 8 байт максимум? Гид будет намного дольше.

Но у меня есть две основные причины предпочтения: удобочитаемость и время доступа. Числа для меня проще, чем GUID (так как я всегда могу легко найти следующую / предыдущую запись).

Что касается времени доступа, обратите внимание, что у некоторых БД могут возникнуть БОЛЬШИЕ проблемы с GUID. Я знаю, что это имеет место с MySQL ( MySQL InnoDB Выбор первичного ключа: GUID / UUID против производительности вставки целых чисел ). Это не может быть большой проблемой с SQL Server, но это то, что нужно остерегаться.

Я бы сказал, придерживайтесь INT или BIGINT. Единственный раз, когда я думаю, что вам понадобится GUID, это когда вы собираетесь выдавать их и не хотите, чтобы люди могли угадывать идентификаторы других записей по соображениям безопасности.

Answer 8

Если у вас нет реальной потребности в GUID, например, в возможности генерировать ключи где угодно, а не только на сервере, тогда я остановлюсь на использовании ключей на основе INTEGER. GUID являются дорогостоящими для создания и затрудняют фактический просмотр данных. Кроме того, вы когда-нибудь пытались ввести GUID в запросе SQL? Это больно!

Answer 9

Это действительно зависит от того, ожидаете ли вы репликации на картинке. Репликация требует UUID строки, поэтому, если вы планируете сделать это, вы можете сделать это заранее.

Answer 10

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