UUIDs : Quand l'auto-increment ne suffit pas

Ta base de données utilise des IDs auto-incrémentés. 1, 2, 3, 4... Simple.

Puis tu fusionnes deux bases de données. Ou tu exposes des IDs dans les URLs. Ou quelqu'un découvre qu'il peut deviner les données d'autres utilisateurs en incrémentant l'ID dans l'URL.

Les IDs séquentiels ont des problèmes. Les UUIDs en résolvent certains.

C'est quoi un UUID ?

Universally Unique Identifier (Identifiant unique universel). Un nombre de 128 bits, typiquement affiché comme 32 caractères hexadécimaux avec des tirets :

550e8400-e29b-41d4-a716-446655440000

Les maths derrière la génération UUID rendent les collisions astronomiquement improbables. Tu peux générer des UUIDs sur différentes machines, à différents moments, sans coordination, et ils n'entreront pas en collision.

Pourquoi ne pas juste utiliser l'auto-increment ?

Sécurité. Les IDs séquentiels fuient de l'information. Si ton ID utilisateur est 15847, les attaquants savent qu'il y a au moins 15846 autres utilisateurs. Ils peuvent énumérer les ressources en essayant des IDs séquentiels.

Systèmes distribués. Plusieurs serveurs générant des IDs ont besoin de coordination pour éviter les doublons. Les UUIDs n'ont besoin d'aucune coordination.

Fusion de données. Combiner des bases de données avec des IDs séquentiels est un cauchemar. Les UUIDs fusionnent proprement.

Création hors ligne. Les applications mobiles peuvent créer des enregistrements hors ligne avec des UUIDs. Pas besoin d'attendre un ID assigné par le serveur.

Versions UUID

Tous les UUIDs ne sont pas créés de la même façon.

Version 1 : Basé sur timestamp et adresse MAC. Unique, mais révèle quand et où il a été créé.

Version 4 : Aléatoire. Plus courant. Aucune fuite d'information.

Version 7 : Basé sur timestamp mais triable. Les nouvelles bases de données en bénéficient.

Pour la plupart des usages, version 4 (aléatoire) est le bon choix.

Les compromis

Les UUIDs ne sont pas gratuits.

Taille. 128 bits vs 32 bits pour un entier. Index plus larges, plus de stockage.

Lisibilité. user/15 est plus facile à retenir que user/550e8400-e29b-41d4-a716-446655440000.

Performance. Les UUIDs aléatoires causent une fragmentation d'index dans certaines bases de données. UUID v7 résout ça.

Débogage. Chercher dans les logs un UUID est fastidieux comparé à de simples nombres.

Quand utiliser quoi

Utilise auto-increment quand :

• Interne uniquement, jamais exposé aux utilisateurs
• Applications simples, base de données unique
• La lisibilité humaine compte

Utilise UUIDs quand :

• Les IDs apparaissent dans URLs ou APIs
• Plusieurs systèmes créent des enregistrements
• La sécurité par l'obscurité aide
• Fusionner des données est possible

Conseils pratiques

N'utilise pas les UUIDs comme clés primaires dans MySQL. Utilise-les comme colonne unique secondaire à la place. Les index clusterisés de MySQL performent mal avec des UUIDs aléatoires.

Considère UUID v7. Si ta base de données le supporte, les UUIDs triables par timestamp te donnent le meilleur des deux mondes.

Retire les tirets pour les URLs. 550e8400e29b41d4a716446655440000 est toujours un UUID valide et plus court dans les URLs.

---

Les UUIDs résolvent de vrais problèmes que les IDs séquentiels ne peuvent pas. Mais ils ne sont pas toujours le bon choix. Choisis en fonction de tes besoins réels, pas parce que les UUIDs ont l'air plus professionnels.