Meilleures pratiques concernant les clés primaires, l'auto-incrémentation et les UUID dans les RDBM et les bases de données SQL.

Question

Nous concevons une table pour l'entité utilisateur. La seule exigence non triviale est qu'il doit y avoir une URL permanente vers l'entité utilisateur (par exemple son profil). Il y a beaucoup de choses sur le web à propos de l'int/long vs UUID. Mais ce n'est toujours pas clair pour moi.

1. Étant donné que le profil contient des informations privées, ce n'est pas une bonne idée d'avoir un identifiant prévisible intégré dans l'URL. Ai-je raison ?
2. Pour satisfaire la première, je peux avoir une clé primaire sous forme d'UUID et l'intégrer dans l'URL. Mais il y a deux questions. Dois-je m'inquiéter de l'impact sur les performances de l'utilisation de l'UUID comme clé primaire dans tous les cas : indexation, insertion, sélection, jointure ?

Cela dit, laquelle des propositions suivantes est la meilleure (par rapport à ce qui précède) ?

CREATE TABLE users(
  pk UUID NOT NULL,
  .....
  PRIMARY KEY(pk)
);

ou

CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);

Answer 1

C'est une question de choix en fait et cette question peut susciter des réponses basées sur l'opinion de mon point de vue. Ce que je fais toujours, même si c'est redondant, c'est que je crée une clé primaire sur la colonne d'incrémentation automatique (je l'appelle clé technique) pour qu'elle reste cohérente au sein de la base de données, pour permettre à la "clé primaire" de changer au cas où quelque chose se serait mal passé lors de la phase de conception et aussi pour consommer moins d'espace au cas où cette clé serait pointée par une contrainte de clé étrangère dans une autre table et aussi pour rendre la clé candidate unique et non nulle.

La clé technique est quelque chose que vous ne montrez normalement pas aux utilisateurs finaux, sauf si vous le décidez. Il peut en être de même pour d'autres colonnes techniques que vous conservez uniquement au niveau de la base de données pour tout usage dont vous pourriez avoir besoin, comme la date de modification, la date de création, la version, l'utilisateur qui a modifié l'enregistrement, etc.

Dans ce cas, j'opterais pour votre deuxième option, mais légèrement modifiée :

CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);

Answer 2

Cette question est basée sur l'opinion, voici donc la mienne.

Je pense qu'il faut utiliser le second, un UUID distinct du PK. Le truc c'est que :

• Le PK est unique et n'est pas exposé au public.
• L'UUID est unique et peut être exposé au public.

Si, pour une raison quelconque, l'UUID est compromis, vous devrez le changer. La modification d'un PK peut être coûteuse et avoir de nombreux effets secondaires. Si l'UUID est séparé du PK, son changement (bien que non trivial) a beaucoup moins de conséquences.

Answer 3

N'en faites pas la clé primaire de votre base de données : cela posera des problèmes à l'avenir si vous souhaitez changer la technologie de votre base de données. Et si vous en faites un nombre croissant, vos concurrents sauront combien d'utilisateurs vous avez et à quelle vitesse vous en ajoutez de nouveaux.