Discussion :

[pcouas]

Bonjour

La generation d'un UUID dans toutes mes tables est elle un "dogme" de DBA ou si cela n'apporte rien car j'ai un id 'metier' unique alors il faut mieux s'en passer ?
Merci de vos réponses

[SQLpro]

Si c'est pour une clé primaire c'est stupide d'utiliser un UUID. C'est lourd, lent à générer et fragmente immédiatement la table => mauvaises perforrmance, mauvaise montée en charge. Mieux vaut utiliser les mécanismes d'auto incrémentation qui sont fait pour cela (IDENTITY et SEQUENCE : norme SQL).

A +

[Michel.Priori]

C'est lourd, lent à générer et fragmente immédiatement la table

Explication de texte : La fragmentation n'existe que si on l'utilise avec index ; d'autant plus s'il est cluster (M$SQL).
Si c'est pour l'utilsier pour un ID, faudra accepter les conséquences ...

L'utilisation d'un UUID est utile dans le cas des bases réparties en mode "multi-maitre".
C'est une pierre angulaire de la réplication de fusion (M$SQL).

En dehors de cas d'usage, je rejoint Frédéric :

Mieux vaut utiliser les mécanismes d'auto incrémentation qui sont fait pour cela (IDENTITY et SEQUENCE : norme SQL).

[SQLpro]

Explication de texte : La fragmentation n'existe que si on l'utilise avec index ;

Pas du tout...

la fragmentation existe dans n'importe quelle structure de données, table en heap ou index de quelque sorte (Btree ou autre) dès qu'il y a :

• une suppression (delete)
• un update

Pour le cas d'un DELETE, la ligne est supprimée jusqu'à la prochaine reconstruction ou réemploi... donc fragmentation...

De manière générale, le fait d'utiliser des types de données variables (VARCHAR, VARBINARY...) fait qu'en cas d'UPDATE agrandissant la valeur, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
UPDATE PERSONNE
SET NOM = 'DE LA POMMERY DU COUDRAY'
WHERE NOM = 'LAVAL';

...le positionnement n'est plus possible à l'emplacement d'origine car dans 5 caractères on ne peut en mettre 24. Il y aura donc un déplacement de la ligne dans une table en heap ce qui générera un trou à l'emplacement d'origine. Une fragmentation apparait aussi pour un UPDATE inverse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
UPDATE PERSONNE
SET NOM = 'LAVAL'
WHERE NOM = 'DE LA POMMERY DU COUDRAY';

.. il en résultera 11 caractères inutilisés... S'ils s'agit de lettres d'alphabets non latin ou diacritique alors le trou est plus important en octets que des caractères simple en latin...

Malheureusement pour le cas de PostGreSQL c'est pire car, dans tous les cas, il y un INSERT + DELETE dans le cas d'un UPDATE.

Pour le cas de l'INSERT, c'est plus subtil.... Dans certains SGBDR haut de gamme (SQL Server par exemple) il y a recherche du premier "trou" suffisant pour y loger la ligne. Donc cela réduit la fragmentation. Dans des SGBDR bas de gamme comme MySQL/MariaDB ou PostGreSQL on ne s'emmerde pas... la ligne est rajoutée dans l'espace disponible en fin de page, souvent la dernière...

A +

[Michel.Priori]

la fragmentation existe dans n'importe quelle structure de données, table en heap ou index de quelque sorte (Btree ou autre)

Ok fred, mais là on parle d'une colonne UUID...

Une colonne UUDI se génère, sous Pg, en général, via gen_random_uuid().
Vu qu'un index Btree est ordonné, l'ajout de valeurs aléatoires va "fragmenter" l'index.
Et un ID est généralement indexé (voire être la PK)

Pas besoin de faire un cours sur la fragmentation en général.

Par contre, toi comme moi, n'avons produit les tests montrant nos convictions/explications.
On est dans l'argument d'autorité.

Dans certains SGBDR haut de gamme (SQL Server par exemple) il y a recherche du premier "trou" suffisant pour y loger la ligne.

oui, ok ; mais pourquoi ne pas citer Oracle ?

Si on revient à la demande initiale qui demande si on peux "se passer" des UUID, ta réponse était la bonne => oui, utiliser identity ou sequence.