Насколько я могу положиться на GUID в .Net? - PullRequest
6 голосов
/ 13 сентября 2011

Насколько я могу положиться на GUID в .Net?Мой SA сказал мне, что

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

Интересно, надежность GUID в качестве первичного ключа.

Могут ли быть какие-либо шансы, что будет дубликат?

Должны ли мы действительно использовать этот способ?

Как насчет производительности?

Любой совет будет полезен для меня.

Ответы [ 6 ]

6 голосов
/ 13 сентября 2011

Вот некоторые баллы за GUID, которые дают вам ответ

Преимущество:

  1. Уникальный для всего сервера.

Недостаток:

  1. Строковые значения не так оптимальны, как целочисленные значения для производительности при использовании в соединениях, индексах и условиях.
  2. Требуется больше места для хранения, чем INT.

Вы можетепрочитайте полный пост об этом по адресу: СЕРВЕР SQL - GUID против INT - Ваше мнение

4 голосов
/ 13 сентября 2011

Возможно, вы захотите взглянуть на эти статьи:

http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

Лично я использую целые числа, если мне не нужны первичные ключи длябыть уникальным для нескольких таблиц и баз данных.Мне проще отладить с 87, чем 2A734AE4-E0EF-4D77-9F84-51A8365AC5A0.

4 голосов
/ 13 сентября 2011

Да, может быть дубликат, но это не так. GUID имеет длину 32 символа, и каждый символ может быть 0-F (шестнадцатеричный). Это означает 16 ^ 32 возможностей.

Таким образом, если вы генерируете 1 000 000 GUID каждую секунду в течение 10 лет, вероятность создания дубликата составляет около 1 / 1079028307080601418897053.

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

3 голосов
/ 13 сентября 2011

Благодаря Парадоксу на День Рождения (Проблема) у вас есть около 50% нахождения дубликата, если вы генерируете 2 ^ 64 GUID ... Вы счастливы? (это потому, что полностью случайный GUID имеет длинную 128 битов, поэтому существует 2 ^ 128 разных GUID. Парадокс дня рождения говорит нам, что если у вас есть aproximatevely sqrt (2 ^ 128) GUID, у вас есть 50% шанс на столкновение, я говорю полностью случайный GUID, потому что есть некоторый стандартный тип GUID, в котором некоторые цифры являются фиксированными, но .NET не использует эти стандарты (см. здесь http://en.wikipedia.org/wiki/Globally_unique_identifier))

Я добавлю, что если у вас проблема с «скоростью» БД, вы должны прочитать это:

Повышение производительности первичного ключа GUID индекса кластера

2 голосов
/ 13 сентября 2011

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

Преимущество использования этих идентификаторов в веб-приложении заключается в том, что пользователи не могут просто тестировать URL-адреса с другими идентификаторами, поэтому теоретически это будет более безопасным (хотя в любом случае вы должны иметь проверку сервера для разрешений)

0 голосов
/ 06 июля 2014

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

Например.Работа в автономном режиме и возврат изменений в центральный дБ.

...