UUID
връща универсален уникален идентификатор
(надявам се също уникален, ако се импортира и в друга DB).
Да цитирам от MySQL doc (подчертавам моя):
От друга страна просто INT първичен идентификационен ключ (напр. AUTO_INCREMENT ) ще върне уникално цяло число за конкретната DB и DB таблица, но която е не универсално уникална (така че ако се импортира в друга DB има вероятност да има конфликти на първичен ключ).
По отношение на производителността не би трябвало да има забележима разлика при използване на auto-increment през UUID . Повечето публикации (включително някои от авторите на този сайт) се посочват като такива. Разбира се UUID може да отнеме малко повече време (и място), но това не е пречка за производителността за повечето (ако не всички) случаи. Да има колона като Primary Key трябва да направи и двата избора равни спрямо производителността. Вижте препратките по-долу:
- До
UUIDили не къмUUID? - Митове,
GUIDсрещуAutoincrement - Ефективност:
UUIDсрещуauto-incrementв cakephp-mysql UUIDпроизводителност в MySQL?- Първични ключове:
IDs срещуGUIDs (ужас за кодиране)
(UUID срещу auto-increment резултати от производителността, адаптирани от Митове, GUID срещу Autoincrement
)
UUID плюсове/противи (адаптирано от Първични ключове:ID s срещу GUID с
)
Забележка
Ще прочета внимателно споменатите препратки и ще реша дали да използвам UUID или не в зависимост от моя случай на употреба. Въпреки това в много случаи UUID s наистина би било за предпочитане. Например може да се генерира UUID s без изобщо да използвате/достъпвате до базата данни или дори да използвате UUID s, които са били предварително изчислени и/или съхранени някъде другаде. Освен това можете лесно да обобщите/актуализирате вашата схема на база данни и/или схема за клъстериране, без да се притеснявате за ID s нарушаване и причиняване на конфликти.
По отношение на възможни сблъсъци, например използване на v4 UUIDS (случаен), вероятността да се намери дубликат в рамките на 103 трилиона UUID на версия-4 е едно на милиард.
