SQL Server уникальный GUID

Question

Я понимаю, что в SQL Server идентификаторы GUID НАИБОЛЕЕ уникальны, а также что вероятность столкновения невелика, но в то же время кто-то должен выиграть в лотерею, поэтому я чувствую, что имеет смысл подготовиться к такой возможности.

Что быстрее / лучше практики

Используя технику, в которой я назначаю новый GUID напрямую, просто вставляя строку и проверяя на наличие ошибки (@@ ERROR <> 0) и повторяя до тех пор, пока не получу ошибку [которую, я полагаю, в теории, будет только при худший раз будет ...]

или используя такой подход

DECLARE @MyGUID uniqueidentifier
SELECT @MyGUID = NewID()
if exists(select * from tablename where UserID=@MyGUID)

и перебираю это, пока не найду тот, который не используется.

Мне нравится 2-й подход, потому что тогда у меня может быть GUID для использования в Хранимой процедуре, поэтому я сейчас склоняюсь к этому.

Answer 1

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

При этом для обеспечения уникальности чего-либо в реляционной базе данных используется только одно средство: создать уникальное ограничение для данных:

ALTER TABLE tablename ADD CONSTRAINT uniqueUSerID UNIQUE UserID;

Answer 2

Вероятность столкновения на вашем компьютере гораздо меньше, чем выигрыш в лотерее .

Используйте NEWID() и не беспокойтесь о невероятно маловероятном событии.

Если вы объявили столбец уникальным, он все равно не будет сохранен.

Answer 3

На самом деле ответить на вопрос, а не обсуждать достоинства вопроса / предполагаемой проблемы.

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

• Выполнение проверки существует перед выполнением вставки для каждой отдельной записи, с которой вы будете иметь дело, в конечном итоге вы выделите больше ресурсов на что-то, что крайне маловероятно. (также база данных будет обеспечивать ограничение для столбца, поэтому, если она столкнется, данные не будут зафиксированы)
• Если у вас есть ошибка в первом случае, вы можете потратить немного больше времени и обработать ОШИБКУ, которая возвращается.

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

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

Answer 4

Вероятность столкновения настолько низка - намного меньше, чем вероятность выиграть в лотерею - что более вероятно, что космические лучи попадут в ОЗУ в машине и вызовут сбой вашей программы каким-либо другим, произвольным образом.Более вероятно, что ваша обработка ошибок для этого случая будет (сейчас или в конечном итоге) содержать ошибку, которая приведет к сбою.Исследователям, которые намеренно пытаются обнаружить столкновения, используя обширные вычислительные мощности, пока не удалось найти ни одного.Я не думаю, что это стоит ваших усилий или времени, чтобы обработать этот случай ошибки, по крайней мере, пока вы не обработаете широкий спектр гораздо более вероятных аппаратных и программных ошибок, которые могут произойти.Я понимаю, что это нелогично, но поверь мне.

Answer 5

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