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/41 renvoi le profil mais yoursite.com/users/42 renvoi 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é.