Un article qui parle des uuidv7 qui comportent une composante temporelle pour être triable par défaut tout étant utilisables dans des systèmes distribués car uniques.
Les performances sont bien supérieures et ça vient du fait qu'ils possèdent une partie aléatoire moins importante (en plus du fait qu'ils soient triable)
Tous les conseils pour bien choisir sa clé primaire.
Dans la plupart des cas, un entier auto-incrémenté (serial) est suffisant, cependant il a quelques désavantages:
- prédictible: il est facile d'énumérer les ID et de deviner des choses comme le nombre d'utilisateurs sur un site (
yoursite.com/users/41renvoi le profil maisyoursite.com/users/42renvoi une 404) - ce n'est pas un standard SQL
Une autre possibilité est d'utiliser un UUID v4 car ceux ci sont totalement aléatoires. Par contre on a d'autres problèmes:
- pas possible de les trier
- beaucoup plus gros que notre entier auto-incrémenté
- leur indexage par la base de donnée est très difficile
C'est pour ça que d'autre types d'UUID sont apparus (voir UUID v7 et ULID), cette dernière génération inclue un timestamp afin de pouvoir les trier par exemple.
L'article termine sur un benchmark sur la vitesse de génération dans PostgreSQL mais aussi de la taille de la table et de son index.
Niveau vitesse, tous sont plus ou moins équivalents à part pour pushid et nanoid qui sont significativement plus lents.
Au niveau de la taille, sans surprise les dernières version d'UUID font augmenter l'espace utilisé.
Un point sur les UUID v7 et les ULID qui sont tous deux des améliorations de la spec UUID v4 en incluant un timestamp afin d'obtenir des identifiants ordonnés.
Je trouve les ULID moins lisible que les UUID 0GWWXY2G84DFMRVWQNJ1SRYCMC par contre les UUID v7 ne sont pas encore très répandus.
Autre chose, les UUID v7 par le même processus auront un compteur auto-incrémenté pour rester séquentiels alors que les ULID auront simplement un bit aléatoire de modifié.
Discussion sur ULID vs ID + sortable created_at (pas de consensus): https://news.ycombinator.com/item?id=28089498
Aussi, les UUID v4 sont très mal compressable donc ça peut rapidement prendre de la place.