Označení UUID nepopisuje jediný algoritmus. Verze určuje, z jakých informací hodnota vzniká a jaké vlastnosti lze očekávat. Některé varianty jsou časové, jiné deterministicky odvozují ID z názvu a nejrozšířenější verze 4 používá náhodné bity. Novější verze 7 nabízí přirozenější časové řazení. Výběr proto nemá být automatickým zvykem knihovny, ale rozhodnutím podle indexování, soukromí, reprodukovatelnosti a hranic systému.

Verze 4 je jednoduchá univerzální volba

UUID v4 používá téměř celý dostupný prostor pro náhodná data. Při kryptograficky kvalitním generátoru je kolize prakticky zanedbatelná a hodnota neodhaluje čas ani adresu zařízení. Generování funguje offline a nezávisle na ostatních uzlech.

Je vhodná pro veřejné identifikátory, příkazy a objekty, kde není potřeba řadit podle ID. Náhodné rozložení však způsobuje zápisy na různá místa B-tree indexu, což může u velmi vytížené databáze zvýšit fragmentaci a cenu cache.

Verze 7 kombinuje čas a náhodnost

UUID v7 ukládá do významné části čas v milisekundách a doplňuje jej náhodnými bity. Kanonický binární či textový tvar se proto přibližně řadí podle vytvoření. Nové řádky přicházejí do indexu s lepší lokalitou než čistě náhodná v4 a ID stále může vzniknout bez centrální sekvence.

Časová složka prozrazuje přibližný okamžik vytvoření. To může být přijatelné u interního primárního klíče, ale nevhodné u objektu, jehož stáří nemá být veřejně odhadnutelné. Řazení navíc není absolutní pořadí mezi uzly s rozdílnými hodinami.

Verze 1 nese historické kompromisy

UUID v1 kombinuje timestamp, clock sequence a node identifikátor, tradičně odvozený z MAC adresy. Poskytuje časovou strukturu, ale může odhalit čas a informace o zařízení. Moderní knihovny umějí node část anonymizovat, přesto bývá pro nový návrh vhodnější v7, pokud je cílem časová lokalita.

Existující systém může v1 používat korektně. Migrace má vycházet z konkrétního rizika a výkonu, nikoli pouze z čísla verze. Smíšené verze lze ukládat ve stejném formátu, ale aplikace nesmí předpokládat stejné vlastnosti všech hodnot.

Deterministické verze řeší jmenný prostor

Verze 3 a 5 vytvářejí UUID z namespace a názvu pomocí hashovací funkce. Stejná dvojice vždy vede ke stejné hodnotě. To je užitečné při stabilním mapování externího klíče, deduplikaci nebo migraci, kde několik procesů musí bez komunikace dojít ke stejnému ID.

Namespace je zásadní: stejný název v různých doménách nemá kolidovat. V3 používá zastaralejší MD5, v5 SHA-1. Pro identifikační, nikoli bezpečnostní účel jsou definované standardem, ale nový protokol může zvážit modernější jmenné schéma, pokud nepotřebuje interoperabilitu UUID.

Požadavek na řazení se musí upřesnit

Tým často žádá „sortable UUID“, ale může tím myslet rychlejší databázový index, zobrazení objektů podle vytvoření nebo garantované pořadí zpráv. Časově řaditelné ID pomáhá prvnímu a přibližně druhému, neřeší však kauzalitu a souběh.

Objekty vytvořené ve stejné milisekundě potřebují doplňkový mechanismus lokálního pořadí a uzly mohou mít posunuté hodiny. Business pořadí má používat samostatný sloupec či verzi, jejíž smlouva je explicitní.

Databázový test je lepší než obecná poučka

Rozdíl mezi v4 a v7 závisí na databázi, objemu zápisů, velikosti indexu a typu úložiště. Nativní UUID typ může mít jiné chování než textový varchar. Před migrací je vhodné měřit produkčně podobný workload a sledovat velikost indexu, page split, latency a replikaci.

Optimalizace primárního klíče nesmí změnit veřejnou smlouvu bez potřeby. Systém může používat interní řaditelný klíč a samostatné veřejné ID, pokud mají rozdílné požadavky.

Soukromí a odhadnutelnost nejsou totéž

Náhodná v4 skrývá čas lépe než v7, ale žádné UUID není tajemství. Časová verze neumožňuje snadno vyjmenovat všechny náhodné zbylé bity, přesto zveřejňuje metadata. Před vložením ID do veřejné URL je vhodné posoudit, zda tento únik něco prozrazuje o zákazníkovi nebo workflow.

Pokud samotná znalost odkazu uděluje přístup, je potřeba náhodný capability token nebo podepsaná krátkodobá URL. Výběr verze UUID nenahrazuje bezpečnostní návrh.

Standardizace v rámci systému snižuje překvapení

Organizace může stanovit výchozí verzi pro nové entity a povolené výjimky. Sdílená knihovna zajistí správný zdroj náhody, kanonický zápis a metriky chyb. Dokumentace má uvést, zda klient smí dodat vlastní ID nebo jej vždy vytváří server.

Validace příchozí hodnoty může přijmout pouze očekávané verze, pokud na jejich vlastnostech aplikace skutečně staví. Pokud verze není důležitá, zbytečně přísné odmítnutí komplikuje interoperabilitu.

Rozhodnutí je vhodné zaznamenat i do databázových migrací a kontraktních testů. Jinak může nová služba začít generovat jinou verzi, která sice projde obecným UUID parserem, ale poruší předpoklad o řazení nebo soukromí. Metrika přijatých verzí ukáže skutečné používání před zpřísněním validace a zabrání náhlému odstavení staršího klienta bez přechodného období.

Výjimka z výchozí verze má mít vlastníka, zdůvodnění a datum další revize, aby se z dočasného kompromisu nestal neviditelný standard.

Volba vychází z jedné hlavní odpovědnosti

V4 je bezpečný obecný základ pro nezávislá a neřazená ID. V7 dává smysl, když časová lokalita prokazatelně pomáhá databázi a zveřejnění přibližného času nevadí. Jmenné verze jsou vhodné, když stejný vstup musí vždy vytvořit stejnou identitu.

Nejlepší verze je ta, jejíž vlastnosti systém skutečně používá a dokáže vysvětlit. UUID má stabilně pojmenovat objekt. Když od něj architektura současně očekává tajemství, přesné pořadí, autorizaci a časovou historii, potřebuje tyto odpovědnosti rozdělit do samostatných dat.