Snad tento článek je zbytečný a jeho napsaní nošením sov do Athén. Snad ony 128bitové identifikátory ve formátu UUID jsou již natolik běžné,že jsou obsaženy ve většině informačních systémů a také jsou skryty na pozadí většiny internetových aplikací. Nevím. Považují UUID za užitečné, tak jsem se jim rozhodl věnovat tento text.

Relační paradigma aneb jak jsem našel UUID

Všichni informatici se učí ve škole o relačních databázích a normálních formách. Teorie relačních databází ale neříká, že by ID muselo být celočíselné, ale je to pro člověka přirozené – řádky jsou očíslovány vzestupnou řadu, takže to přípomíná pořadí.

Celočíselná IDčka mají svoje limity, například místo vzniku IDčka musí být jenom jedno nebo musíme vyřešit problém neduplicitní vytváření IDček různými generátory. Kdysi jsme z našeho shopu vytvářili konektor do ERP, který měl celočíselná IDčka, ale pro každý řádek dvě. První IDčko bylo klasické, druhé udávalo server, kde řádek vznikl. Tímto způsobem ERP podporovalo distribuovaný vznik záznamů. Každý záznam tedy obsahoval dvě políčka, která dohromady identifikovala záznam. Asi netřeba podrobně vysvětlovat, jak to bylo nepraktické a rizikové vzhledem k možnosti vzniku chyby (ne vše lze elegantně vyřešit podobně jako equals).

Poprvé jsem se setkal s použítím UUID v Lotus Notes a musím říct, že podivné hexakódy ve stylu C9694AE51798E4ACC12576B4007DFD89 se mi vůbec nelíbily. Kolega notesář mi vysvětlil, že tato IDčka mají v Notesech své opodstatnění:

1. ID obsahuje kód serveru, tím je vyřešen problém potenciální duplicity v distribuovaném prostředí
2. ID obsahuje čas svého vzniku, což se hodí pro systémové účely

A tak jsem se s těmi hexakódy smířil…

Výhody UUID

Hlavní výhodou použití UUID je použitelnost v distribuovaném prostředí. Může existovat několik geograficky vzdálených a ne nutně on-line propojených generátorů IDček. Záznamy v databázi s takovými IDčky pak můžeme bez problémů sloučit z různých zdrojů. To je řešeno buď použitím algoritmu pro generování UUID, který do UUID zakomponuje MAC adresu. Jiná možnost je použití algoritmu, který pracuje jako generátor náhodných čísel – vzhledem počtu bitů je pravděpodobnost duplicity nízká (matematicky je pravděpodobnost vyjádřena na wiki).

Další výhodou UUID je to, že identifikátor nepřímo vyjadřuje i datový typ. Pokud vám někdo řekne číslo 358, tak nevíte, jestli je to ID objednávky, produktu nebo zákazníka. Pokud se dozvíte UUID, stačí prohledat odpovídající tabulky (tj. všechny tabulky, které používají UUID) a záznam určitě naleznete. (Dokonce to lze v Hibernate pomocí dědičnosti řešit jediným HQL dotazem, ale to už je jiné téma.)

32 hexadecimálních znaků se špatně pamatuje a ještě hůře hádá. Můžete tedy UUID použít jako „tajný kód“. Napadá mě například použití v „tajném“ jednorázovém URL pro změnu hesla uživatele, které mu aplikace pošle mailem.

Nevýhody UUID

Nevýhodou UUID je délka. 16 bajtů není žádný extrém, ale problém je v tom, že relační databáze UUID příliš nepodporují a namapování do jiného datového typu je problematické:

1. celá čísla bývají jen 64bitová
2. při namapování do řetězce políčko zabere 32 znaků (při zakódování do hexadecimálního kódu) nebo 26 znaků (při zakódování do písmen a číslic z ASCII)

(Podporu pro UUID můžete nalézt v Oracle nebo v PostgreSQL.)

UUID se špatně pamatuje.

Závěr

Pomocí UUID můžete vaší aplikaci přidat několik zajímavých funkcionalit, které se jiným způsobem realizují jen velmi špatně. A pokud UUID nepoužíváte, je alespoň dobré vědět o co jde…