Мы широко используем GUID в нашем проекте базы данных; Свойства бизнес-объекта предоставляют Guid.Empty GUID для нулевых значений DB и null всегда сохраняются в базе данных, если значение Guid.Empty.
Помимо Guid.Empty (00000000-0000-0000-0000-000000000000), насколько вероятно, что GUID будет сгенерирован со всеми одинаковыми символами e. g.: 11111111-1111-1111-1111-111111111111
Просто подумайте об использовании GUID, подобных этим для определенных значений.
Вкратце: для GUID, сгенерированного в соответствии с опубликованными стандартами и спецификациями, этого просто не может быть. GUID имеет структуру, и некоторые поля имеют смысл. Что еще,.NET генерирует GUID версии 4, где это абсолютно невозможно. Они определяются таким образом, что такого GUID не будет. Подробнее см. Ниже: -)
Здесь есть пять-семь бит, которые являются главной ловушкой. Это идентификатор версии (первые четыре бита третьей части) и поле варианта, определяющее, какой вариант GUID это.
В настоящее время версия может быть от 1 до 5. Таким образом, единственные действительные шестнадцатеричные цифры, для которых мы могли бы получить такой GUID в этот момент, - очевидно - от 1 до 5.
Немного разрежьте версии:
8, 9, A или B. Это противоречит 4 для номера версии.До сих пор мы исключали версию 4 как невозможную, другие - крайне маловероятны. Давайте посмотрим на поле варианта.
Диалоговое окно указывает некоторые битовые шаблоны для обратной совместимости (x не волнует), а именно:
0 x x Reserved. NCS backward compatibility.
1 0 x The only pattern that currently can appear
1 1 0 Reserved, Microsoft Corporation backward compatibility
1 1 1 Reserved for future definition.
Поскольку этот шаблон находится в самом начале четвертой части, это означает, что самый старший бит всегда устанавливается для самой первой шестнадцатеричной цифры четвертой части. Это означает, что эта цифра никогда не может быть 1, 2, 3 или 5. Не считая уже сгенерированных GUID, конечно. Но те, у которых MSB установлен на 0, являются либо v1, либо v2. И временная метка из них означает, что в будущем они будут созданы в течение нескольких тысячелетий, чтобы это получилось.
Приблизительно 1 из 5 316 911 983 139 693 491 615 228 241 121 400 000
Итак, я думаю, вы в безопасности.
Источник: http://msdn.microsoft.com/en-us/library/aa446557.aspx
Примерно так же, как и любые другие случайно сформированные подсказки. Так что маловероятно.
Тем не менее, вы можете захотеть переосмыслить, используя подсказки, чтобы "хранить" такие данные. Они действительно используются для уникальной идентификации объектов и компонентов.
GUID обычно генерируется с использованием алгоритма, а не является подлинно случайной строкой шестнадцатеричных символов. Если вы можете быть уверены, какой алгоритм используется для их создания, вы можете быть уверены, что GUID, которые вы хотите использовать как "магические числа", будут сталкиваться с созданными.
страница Википедии по GUID содержит приличную информацию об используемых алгоритмах, чтобы она могла дать вам окончательный ответ. Или, запустив Reflector над методом Guid.NewGuid() в рамках .net, хотя на основе поиска справочного источника для метода этого вызывается CoCreateGuid в OLE32.
Зачем использовать специально разработанный GUID? Помимо узнаваемого аспекта, почему бы просто не использовать правильно сгенерированный GUID? (Вы знаете, что это будет уникально, вот в чем смысл)
На ваш вопрос уже был дан ответ, но я думал, что буду прагматичным здесь.
1) Вы используете только 8 "жестко запрограммированных" опций, используя это соглашение.
2) Вы могли бы просто создать реальный GUID для каждого из этих "особых" случаев вместо того, чтобы их вручную проворачивать. Таким образом, он будет уникальным, и вы сможете иметь более 8.
Это не прямой ответ, я знаю, но это, вероятно, разумное предложение, учитывая ваши намерения.
Очень, очень низко. Формат GUID включает несколько бит, идентифицирующих эту схему. Если вы "сгенерировали" их сами, схема GUID, скорее всего, была бы неправильной.
Для моей последней компании мы использовали гиды как первичные ключи для таблиц для всех наших баз данных. Во всех случаях мы создали более 1 000 000 000 объектов и никогда не возникали проблем.
Это так же вероятно, как и любое другое руководство.
Если вы вставляете его в базу данных (даже с некоторым специальным значением), вы также можете убедиться, что он уникален с соответствующим ограничением.