Guida di approfondimento
UUID: identificatori univoci, versioni e utilizzi
Struttura degli UUID, variant e versioni, probabilità di collisione e criteri per scegliere un identificatore distribuito.
Che cos'è un UUID
Un UUID è un identificatore di 128 bit pensato per poter essere generato senza un coordinatore centrale. La forma testuale canonica usa 32 cifre esadecimali raggruppate con trattini, ma il valore fondamentale resta la sequenza di 128 bit.
L'unicità non è una proprietà matematica assoluta di ogni UUID: dipende dall'algoritmo di generazione e dal dominio. Lo scopo pratico è rendere le collisioni sufficientemente improbabili o evitarle tramite una struttura definita dalla versione.
Variant e campo version
Alcuni bit identificano il variant e la versione, cioè la famiglia di layout e il metodo con cui sono stati prodotti gli altri bit. La stringa può quindi essere sintatticamente valida ma non appartenere alla versione che un'applicazione si aspetta.
La validazione dovrebbe distinguere formato, variant, versione e policy applicativa. Un parser che accetta qualsiasi UUID non dimostra che quel valore sia appropriato per un dato protocollo.
UUID v4 e casualità
UUID v4 dedica la maggior parte dei bit alla casualità e fissa i bit necessari a version e variant. Con un generatore casuale crittograficamente robusto offre uno spazio enorme e collisioni estremamente improbabili per volumi ordinari.
La probabilità cresce con il numero di identificatori secondo il birthday bound, ma resta trascurabile in moltissimi sistemi. Il rischio operativo più concreto è spesso un RNG difettoso o una generazione non conforme, non l'esaurimento teorico dello spazio.
Versioni temporali e UUID v7
Altre versioni incorporano tempo, namespace o hash. UUID v7 usa un timestamp Unix in millisecondi nella parte più significativa e aggiunge bit casuali, offrendo ordinamento temporale utile per indici e sistemi distribuiti.
Un identificatore time-sortable può migliorare locality in alcuni database, ma espone informazioni temporali e non sostituisce una strategia di ordinamento di business. La versione va scelta in base ai requisiti, non per moda.
Database, API e confini di fiducia
Gli UUID sono comodi come chiavi pubbliche perché non richiedono una sequenza globale e riducono la prevedibilità rispetto a ID incrementali. Possono però essere più pesanti di interi compatti per indici, cache e rappresentazioni testuali.
Un UUID non è un token di autorizzazione. Conoscere o indovinare un identificatore non deve concedere accesso: autenticazione e controlli di permesso devono essere applicati indipendentemente dall'ID.
Best practice
Conserva il valore in un tipo UUID/binary nativo quando il database lo supporta, normalizza la forma testuale ai confini e valida la versione quando il contratto la richiede. Evita di generare UUID con RNG improvvisati.
Definisci anche se l'ID è stabile, pubblico, riutilizzabile e significativo attraverso ambienti diversi. La scelta di un identificatore è parte del modello dati e merita una policy esplicita.