UUID sa do schémy pridá ľahko, no po rozšírení do foreign keys, URL, eventov a cache sa mení ťažko. Najčastejším problémom nie je náhodná kolízia. Je ním uloženie ako neobmedzený text, nejasné generovanie medzi klientom a serverom, chybná konverzia bajtov alebo očakávanie, že dlhý náhodný string sám chráni dáta. Spoľahlivá implementácia považuje UUID za typovanú zmluvu.
Textový stĺpec zbytočne zväčšuje index
Kanonický text má 36 znakov, hodnota iba 16 bajtov. Nativný UUID typ poskytuje validáciu a kompaktnejšie indexy. Kde chýba, možno použiť pevný binary typ.
JSON a URL môžu zostať textové. Reprezentácia na hranici nemusí určovať fyzické uloženie.
Byte order musí byť spoločný
Niektoré platformy historicky prehadzujú časti UUID alebo používajú databázovú funkciu optimalizujúcu časové bity. Dve služby potom z rovnakých 16 bajtov zobrazia iný string.
Integrácia potrebuje známe test vectors cez databázu, broker a API. Ručný prevod segmentov je rizikový.
Primárny kľúč ovplyvňuje sekundárne indexy
V niektorých storage engines je PK súčasťou každého sekundárneho indexu. Dlhé náhodné ID zväčší celú tabuľku a rozptýli zápisy.
V7, interný sekvenčný kľúč alebo iný sortable formát môžu pomôcť. Rozhoduje benchmark, nie všeobecná poučka.
Unique constraint je stále povinný
Chráni pred kolíziou, zlým generátorom aj opakovaným fixture. Aplikácia musí konflikt odlíšiť od inej databázovej chyby.
Foreign key stĺpce používajú rovnaký typ. Implicitná konverzia medzi textom a binary môže znefunkčniť index.
API určuje vlastníka identity
Client-generated ID pomáha offline práci a idempotencii. Server-generated ID zjednodušuje trust boundary. Pole nemá byť náhodne optional podľa implementácie SDK.
Create s existujúcim ID a update sú odlišné operácie. Klient nesmie zvoleným UUID prepísať cudzí objekt.
Regex overí vzhľad, nie celý typ
Pattern môže prijať správny počet hex znakov a ignorovať variant či verziu. Štandardný parser poskytne kanonický výsledok a doménová validácia potom skontroluje povolené pravidlá.
Case alebo pomlčky možno na vstupe tolerovať podľa protokolu, výstup však používa jednu podobu.
UUID nie je autorizácia
Neodhadnuteľnosť sťažuje enumeráciu, no uniknutý odkaz stále otvorí zdroj, ak server nekontroluje oprávnenie. Každý request spája identity context s objektom a akciou.
API môže pre neexistujúci aj neprístupný objekt vracať rovnaké 404, aby neodhaľovalo existenciu. Interný log príčinu rozlíši.
Každý druh ID má inú životnosť
Object ID, request ID, trace ID a idempotency key nie sú zameniteľné. Použiť jednu hodnotu všade zviaže lifecycle a rozšíri sledovateľnosť.
Log má uviesť rolu identifikátora. UUID s vysokou kardinalitou nepatrí do labels časových metrík.
Migration potrebuje dvojité čítanie a zápis
Prechod zo sekvenčného ID mení foreign keys, cache, eventy, URL a partnerov. Bezpečný postup pridá UUID, backfilluje, určitý čas zapisuje oba a postupne presúva čítanie.
Staré odkazy potrebujú mapovanie alebo redirect. Pôvodný kľúč sa odstráni až po telemetry všetkých spotrebiteľov.
Case-insensitive text môže vytvoriť nečakané pravidlá
Hex zápis je významovo case-insensitive, no textová collation môže mať ďalšie normalizačné správanie. Nativný typ odstráni závislosť od locale a string comparison.
Ak text zostáva, schema používa presnú dĺžku a vhodnú binárnu collation. Kanonizácia prebehne pred uložením.
Prevádzka potrebuje sledovať konflikty a parse chyby
Nárast invalid UUID môže znamenať starého klienta, útok alebo chybný rollout. Metrika rozlišuje syntax, nepovolenú verziu, neexistujúci objekt a authorization failure bez logovania osobných payloadov.
Konflikt unique constraint pri generovanom ID je incidentný signál. Nemá sa navždy skrývať neobmedzeným retry.
Typ, rola a vlastníctvo musia byť viditeľné
Štandardný generátor, nativný typ, unique constraint a testované konverzie tvoria základ. API presne definuje, kto ID vytvára a ako sa správa retry.
UUID výborne rieši globálne pomenovanie bez koordinácie. Keď sa považuje iba za náhodný string, problémy sa presunú do indexov, migrácií a bezpečnostných hraníc.
Code review má preto kontrolovať nielen generovanie, ale aj typ query parametra, binding v ORM, unique index, logovanie a authorization lookup. End-to-end test s konkrétnym známym UUID overí, že sa hodnota bez zmeny prenesie cez HTTP, queue aj databázu. Taká kontrola zachytí byte-order a casting chyby skôr, než vzniknú osirelé vzťahy alebo nenájdené verejné objekty.
ORM môže skryť drahú konverziu
Model deklarovaný ako string môže pri každom query castovať natívny UUID stĺpec alebo naopak. Databáza potom nepoužije index a jednoduchý lookup sa zmení na scan. Generated SQL treba kontrolovať na skutočnej schéme.
Serializer môže tiež meniť case či formát. Boundary test overí rovnakú hodnotu od HTTP requestu cez ORM až po response bez prehodenia bajtov.
Sharding potrebuje distribúciu aj routing
Náhodné UUID rozdeľuje hodnoty rovnomerne, čo môže pomôcť hash shardingu. Časové v7 sú zoskupené a môžu vytvoriť hotspot, ak sa shard vyberá podľa prefixu. Naopak rozsahové partitioning podľa času môže v7 využiť.
Identifikátor sa nemá vyberať bez znalosti routing funkcie. Benchmark zahŕňa nielen jednu databázu, ale aj rozdelenie zápisov medzi uzly a správanie rebalancovania.
Migrácia potrebuje rollback bez dvoch autorít
Počas dual-write môže zápis jedného ID uspieť a druhého zlyhať. Transakcia alebo opravný proces musí zachovať jednoznačné mapovanie. Čítanie má definovaný primary source, aby dva stĺpce nezačali predstavovať rozdielne objekty.
Rollback neznamená odstrániť nové UUID z už publikovaných eventov. Kompatibilná vrstva ich môže naďalej rozpoznať, aj keď interné čítanie dočasne používa starý kľúč.