En concevant une API sur Postgres ou MySQL, la question "clé auto-incrémentée ou UUID ?" finit toujours par se poser. Voici la comparaison qui nous a servi à trancher chez Toolbrik.
UUID v4 (aléatoire)
- Avantages : ne révèle ni le volume d'activité ni l'ordre ; généré côté client sans aller-retour serveur ; impossible à deviner par force brute (122 bits d'entropie).
- Inconvénients : pages d'index dispersées dans les b-trees (cache moins dense) ; 36 caractères de texte.
UUID v1 (basé sur le temps)
- Avantages : ordre temporel approximatif, utile pour l'event sourcing ou le partitionnement par date.
- Inconvénients : révèle la date de création et, selon l'implémentation, le nœud qui l'a générée. Devinable avec un nœud fixe.
ID séquentiels
- Avantages : index compacts et rapides, débogage facile, URLs propres (
/users/42). - Inconvénients : énumérables — n'importe qui peut parcourir votre ressource ; nécessitent le serveur pour être générés ; un bug de concurrence peut en créer des doublons.
Recommandation pratique
- Utilisez UUID v4 comme clé primaire par défaut.
- Générez les UUID côté serveur si vous voulez masquer l'ordre, ou côté client pour une latence nulle.
- Pour les tables d'événements, envisagez v1 ; pour les catalogues internes, une séquence reste tout à fait raisonnable.
- Stockez TOUJOURS l'UUID comme type natif
uuid, jamais envarchar, et utilisez-le comme clé de cache.
Normaliser des UUID d'origine douteuse
Tous les systèmes n'émettent pas leurs UUID dans le même format : vous croiserez des majuscules, le préfixe urn:uuid: de certains standards (WSDL, ATOM), ou des chaînes de 32 caractères sans tirets. Le validateur d'UUID accepte les trois variantes, détecte la version et le variant (RFC 4122 ou réservé), et normalise en minuscules canoniques avant l'enregistrement.
Générez-en autant que nécessaire avec notre générateur d'UUID (v4 et v1, avec ou sans tirets) et validez n'importe quelle liste avec le validateur avant de la committer.