UUID vs auto-increment

Les clés primaires permettent de s’assurer que chaque identifiant est bien unique au sein d’une table. Mais ce n’est parfois pas suffisant notamment lorsque l’on souhaite masquer le nombre d’enregistrements dans une table, anonymiser en partie des données, lorsqu’on a besoin de générer un identifiant avant que l’élément ne soit réellement stocké en base de données ou encore lorsqu’on ne peut pas se coordonner avec les autres serveurs qui génèrent de leur côté de nouvelles données à stocker en base.

La solution pour dépasser ces problèmes est l’UUID ou Universally unique identifier. L’idée c’est de créer un identifiant non pas unique mais avec une très forte probabilité d’être unique. Pour cela, les UUID sont construits sur 128 bits à partir de données pseudo-aléatoires et d’informations extraites de la machine qui le génère (portion de date, caractéristiques technique de la machine, numéro aléatoire…). On obtient alors une suite de chiffres et de lettres extrêmement difficiles à regénérer dans un autre contexte.

Voici des UUID :

32c2-c023d6b1-8s28-7351-62a2d2s41e66

6dh2-fjs47hd65-62gg-7462-642daryc82c

Les UUID servent en informatique pour identifier des logiciels et des machines sur un réseau mais on peut aussi s’en servir en base de données pour identifier des objets uniques dans des systèmes décentralisés et/ou à forte volumétrie.

Aujourd’hui les grands SGBD ont des fonctions dédiées relatifs aux UUID. C’est le cas de Microsoft SQL Server, PostgreSQL, MySQL et Oracle.

Les UUID sont tout aussi performants que les clés primaires et en plus elles ne sont pas prédictibles. De quoi rassurer ceux qui veulent protéger et manipuler leurs données :

  • Nombre de lignes impossible à déduire à partir d’un UUID ;
  • Pas besoin de connaître l’identifiant à utiliser quand la base n’est pas joignable ;
  • Facile à répliquer ou à fusionner avec d’autres données (pas de risque de doublon).

La contre-partie est que les UUID prennent plus de place à stocker, rendent parfois les requêtes et le déboggage plus difficiles.

Les UUID sont donc très intéressants lorsque les données peuvent être exposées. S’il s’agit de données non distribuées et qui ne sont pas partagées, l’intérêt est certainement beaucoup moins visible.