UUID nie je jediný algoritmus. Verzia určuje, z akých údajov hodnota vzniká a aké vlastnosti môže systém používať. V4 stavia na náhodnosti, v7 pridáva časovú zložku a name-based verzie vytvárajú deterministickú identitu. Voľba nemá byť náhodný default frameworku. Má vychádzať z databázového workloadu, požiadaviek súkromia, interoperability a toho, či rovnaký vstup musí vytvoriť rovnaké ID.

V4 je jednoduchý všeobecný základ

Takmer celý dostupný priestor tvoria náhodné bity. Pri kryptograficky kvalitnom generátore je kolízia prakticky zanedbateľná a hodnota neodhaľuje čas ani zariadenie.

Je vhodná pre verejné ID a offline tvorbu. Náhodné zápisy však rozptyľujú B-tree index a pri veľkom objeme môžu zhoršiť locality.

V7 zlepšuje časovú lokalitu

UUID v7 obsahuje timestamp v milisekundách a náhodný zvyšok. Kanonický tvar sa približne radí podľa vytvorenia, takže nové databázové zápisy prichádzajú bližšie k sebe.

Zároveň odhaľuje približný čas vzniku. To môže byť prijateľné interne, no nevhodné pri verejnom objekte s citlivým lifecycle.

V1 nesie historické kompromisy

V1 kombinuje čas, clock sequence a node identifikátor tradične spojený s MAC adresou. Môže odhaliť metadata o čase a zariadení.

Existujúci systém nemusí okamžite migrovať, ale nový návrh obyčajne použije v7, ak potrebuje časové radenie bez historického node modelu.

Name-based verzie sú deterministické

V3 a v5 hashujú namespace a meno. Rovnaká dvojica vždy vytvorí rovnaké UUID, čo pomáha pri stabilnom mapovaní externého kľúča a distribuovanej deduplikácii.

Namespace oddeľuje domény. Rovnaké meno v rôznych systémoch nemá kolidovať. Determinizmus zároveň prezrádza, že dva záznamy vznikli z rovnakého vstupu.

„Sortable“ potrebuje presnejšiu požiadavku

Tím môže myslieť rýchlejší index, zobrazenie podľa createdAt alebo garantované poradie eventov. V7 pomáha indexu a približnému času, no nerieši kauzalitu medzi uzlami.

Presné business poradie potrebuje samostatnú sequence alebo version. ID nemá niesť všetky významy naraz.

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

Dopad v4 a v7 závisí od storage enginu, objemu, page size a sekundárnych indexov. Nativný UUID typ sa správa inak než text.

Benchmark sleduje write latency, index size, page splits, cache a replikáciu na produkčne podobnom workloade.

Interné a verejné ID môžu mať inú úlohu

Databáza môže používať kompaktný sekvenčný primárny kľúč a API verejné UUID. To izoluje index od odhadnuteľnosti, ale pridáva ďalší unique index a mapovanie.

Dva identifikátory majú zmysel iba s jasnou rolou. Inak spotrebitelia začnú používať nesprávny a migrácia sa skomplikuje.

Súkromie nie je iba neodhadnuteľnosť

V4 skrýva timestamp lepšie než v7, no žiadne UUID nie je secret. Hodnota môže byť sledovateľná cez logy a služby. V7 navyše zverejní približný čas.

Ak držba odkazu udeľuje prístup, treba náhodný token alebo podpis. Verzia UUID nenahrádza autentizáciu.

Validácia verzie má mať dôvod

Ak systém stavia na time ordering v7, môže odmietnuť inú verziu. Ak používa UUID iba ako opaque ID, zbytočne prísna kontrola zhoršuje interoperabilitu.

Kontrakt má povedať, kto ID generuje a ktoré verzie prijíma. Telemetry zmeria starých klientov pred sprísnením.

Štandardizácia znižuje prekvapenia

Zdieľaná knižnica zabezpečí správny random source, kanonický text a jednotné metriky. Výnimka z default verzie potrebuje vlastníka a dôvod.

Rozhodnutie sa zapisuje do API schema a databázových migrácií, nie iba do ústnej dohody jedného tímu.

Najlepšia verzia plní jednu hlavnú úlohu

V4 je bezpečný default pre náhodné nezávislé ID. V7 je vhodná pri preukázateľnej výhode časovej locality. Name-based verzia patrí k deterministickému mapovaniu.

Ak architektúra od UUID očakáva tajomstvo, autorizáciu, dokonalé poradie aj auditný čas, treba tieto zodpovednosti rozdeliť do samostatných polí.

Monotónnosť v7 nie je automatická medzi procesmi

Generátor môže v rámci jednej milisekundy upravovať náhodnú alebo sekvenčnú časť, aby lokálne hodnoty rástli. Dva procesy však nemajú spoločný stav a ich hodiny sa môžu posunúť dozadu. Globálne strict ordering preto nemožno predpokladať.

Ak databáza používa ID iba pre locality, približné radenie stačí. Ak klient z poradia odvodzuje poslednú verziu, potrebuje explicitný stĺpec a transakčné pravidlo.

Privacy review sa týka aj metadát

Timestamp vo v7 môže odhaliť, kedy vznikol účet, objednávka alebo incident. V niektorých produktoch ide o nevinnú informáciu, v iných o citlivý údaj. Verejné ID sa preto posudzuje spolu s URL, logmi a možnosťou korelácie.

V4 odstráni časovú stopu, ale stále umožní sledovať rovnaký objekt naprieč systémami. Pseudonymný identifikátor nie je automaticky anonymný podľa privacy požiadaviek.

Migrácia verzie nemusí meniť staré objekty

Systém môže začať generovať v7 pre nové záznamy a ponechať existujúce v4. Parser prijme obe a nesmie pri starých hodnotách predpokladať timestamp. Index postupne získa zmiešaný profil.

Hromadné prečíslovanie objektov obyčajne prináša väčšie riziko než úžitok. Ak je nutné, potrebuje mapovanie, redirecty a kompatibilitu všetkých foreign keys a eventov.

SDK a API schema majú verziu pomenovať iba vtedy, keď na nej spotrebiteľ smie stavať. Inak klient začne parsovať timestamp alebo meniť sort podľa implementačného detailu a budúca zmena verzie sa stane nekompatibilnou. Opaque ID contract poskytuje serveru väčšiu slobodu. Ak sa časová vlastnosť verejne sľúbi, musí byť testovaná vrátane clock rollbacku, súbehu a zmiešaných historických UUID.

Verejná dokumentácia zároveň presne a jednoznačne vysvetlí, ktoré vlastnosti sú zámerné a ktoré zostávajú iba interným implementačným detailom konkrétneho generátora.