Евангелие от GUID

Использовал GUID когда делал плагин для Firefox.

Вопрос: GUID'ы же могут повториться! Вот тогда произойдет глобальный пипец.
Единственное что, это вести базу созданных GUID и проверять на существование, а если GUID есть - перегенерять его и снова проверять.

Как-то загадочно. Кажется, я чего-то не понимаю.

Чорт, вот оно что:

GUID (Globally Unique Identifier) — представляет собой статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3,4028

Парсер лохе.

http://ru.wikipedia.org/wiki/GUID

Есть еще http://ru.wikipedia.org/wiki/UUID

Во-первых: "небольшое снижение производительности у связей, построенных на базе gUID" - наличие или отсутствие "не" в первом слове зависит очень много от чего. Просто нагенерить 70 миллионов гуидов - это уже целое дело. А это, например, всего-навсего трудовой день в NYSE.

Во-вторых: часто на основе ID строятся какие-нибудь коды, которые где-то печатаются. За номера заказа в виде guid надо расстреливать из крупнокалиберного пулемета не отходя от кассы, имхо. Чтобы это прочувствовать - попробуйте прочитать номер заказа девочке-операторше по мобилке, ага.

В-третьих: проблема foreign data purge, возникающая при сливании наборов данных из разных источников, практически не решается на основе идентификаторов - нужны natural keys. То, что в БД аптеки я под номером 1234567890, а у страхового агента - под номером 0987654321 ни чем не помогает, простите.

Ну и, наконец, в последних: слово "Евангелие" плохо сочетается со 128 битами.

GUID'ы при генерации, под Виндой по крайней мере, используют текущее время. WinAPI использует таймер и при генерации КАЖДОГО GUID'а делает некоторую задержку по времени прежде чем отдать обатно его значение. Так что, для БД оно самое оно! В своё время шутили, что генерация GUID'а ещё один недокументированный способ получить гарантированную задержку в несколько мс при исполнении программы.

кстати, стоит упомянуть, что 128 бит — это 16 байт, либо — судя по Вашему примеру — строка из 38 символов, включая скобки и дефисы. Оракловый тип Number имеет примерно такое же максимальное ограничение — он занимает до 16 байт, и декларирует хранение до 38 значимых десятичных знаков. Но числа можно (до 15 знаков) тянуть на клиент как Double, а GUID-ы — врядли, встроенных типов данных на 16 байт кажись нету, и придётся тянуть строки по 32 или по 38 знаков, и наверно тогда уж их же и хранить, чтоб не конвертить их туда-обратно каждый раз.

В GUID, генерённых подряд в винде, меняющаяся часть начинается где-то знака с 8-го… хотя, на дальних этапах работы БД с обычными числовыми идентификаторами — меняющаяся часть тож в правую часть строки уползает… Но сравниваются они как числа, наверняка тоже справа, с младших разрядов. Интересно, как это может повлиять на эффективность индекса?

И ещё стоит помянуть (из википедии): «генерируя 1 триллион ключей каждую наносекунду, перебрать все возможные значения удастся лишь за 10 миллиардов лет.»