Discussion :

[scamphp]

Bonjour

Que pensez vous de l'UUID4 par rapport à l'ID auto-increment

La clé unique UUID4 semble plus fiable si besoin de synchronisation entre bases (master - slave et master - master).

Semble plus intéressement car elle n'est pas liée au contenu 54vch5v1vj n'a rien a voir avec id 1 de l'admin ou de id 1 c'est mon 1er article lol

Par contre qu'en est-il de sa performance ???

Je cherche ID 253
Mysql passe-t-il toutes les lignes en lecture
00001 -> 00002 -> 00003 -> 00004 -> .... -> 00253 ou va-t-il directement à la ligne 253 car en auto-increment il sait ou aller chercher directement car il sait que c'est rangé par ordre croissant.

Alors qu'avec UUID, il doit forcement lire ligne par ligne puisqu'il n'y a pas d'ordre croissant (pas d'auto-increment)

[CinePhil]

Réponse de SQLPro dans son blog : clé auto-incrémentée.

[scamphp]

Code :

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

1
2
create table users(id_bin binary(16), name varchar(200));
insert into users values(unhex(replace(uuid(),'-','')), 'Andromeda');

BINARY (16) est ... bien ... juste binaire! Pas de jeu de caractères, pas de collation, juste seize octets.

11E570EA3A059CCBA4FBB026B977EB28 -> �p�:�ˤ� &�w�

dans votre exemple vous êtes en DATA1 VARCHAR(642) et DATA2 VARCHAR(64)

[CinePhil]

Code :

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

1
2
create table users(id_bin binary(16), name varchar(200));
insert into users values(unhex(replace(uuid(),'-','')), 'Andromeda');

BINARY (16) est ... bien ... juste binaire! Pas de jeu de caractères, pas de collation, juste seize octets.

11E570EA3A059CCBA4FBB026B977EB28 -> �p�:�ˤ� &�w�

D'où vient ce code ? À quoi répondez-vous ?

dans votre exemple vous êtes en DATA1 VARCHAR(642) et DATA2 VARCHAR(64)

Là vous parlez sans-doute du code de SQLPro dans son article ?
J'ai remarqué ça effectivement et j'ai supposé que c'était une coquille de saisie lors de la rédaction de l'article. Il faudrait le demander à SQLPro en réponse à son article de blog.

[scamphp]

Voici l'article

https://mysqlserverteam.com/storing-...-mysql-tables/

Oui je parlais du code de SQLPro où la comparaison avec UUID est faite en sorte d'être défavorable à l'UUID

Je compare 2 voitures, mais dans une des 2 je la charge de plomb et je lui crève les pneus... la quelle va la plus vite

On pourrait comparer en optimisant les 2 pour voir l'écart objectif

[CinePhil]

N'ayant pas SQL Server sous la main, je ne peux pas corriger son code et reproduire son test pour le vérifier. Encore une fois, je vous invite à lui répondre sur son blog.

Ceci dit, quand je vois toutes les manipulations compliquées à faire avec MySQL dans l'article que vous citez, je me dis que ça doit être bien moins performant aussi à utiliser qu'une clé auto-incrémentée.

Qu'on utilise l'UID pour identifier de manière unique quelque chose dans une BDD répartie, pourquoi pas. Mais l'utiliser comme clé primaire ne me semble a priori pas performant.

[Artemus24]

Salut à tous.

Que pensez vous de l'UUID4 par rapport à l'ID auto-increment?

Je n'ai jamais entendu parlé de UUID4 sous mysql, donc je ne sais pas si on peut l'appliquer sous MySql.

Inversement, sous Linux, les UUID (Universally Unique IDentifiers) permettent d'dentifier des partitions d'une manière unique.
Voici un UUID sous linux : "550e8400-e29b-41d4-a716-446655440000". Cela comprend des tirets, des chiffres et des lettres.

A priori, pourquoi faire simple quand on peut faire compliqué.
L'identifiant (id) auto incrémenté répond déjà à ce besoin d'unicité dans une table.
De plus, si la colonne est déclaré en "integer", l'occupation mémoire est que de 4 octets.
Alors qu'avec un UUID, dans l'exemple ci-dessus, va occuper 36 octets.
Pour l'instant, je ne vois pas trop l'avantage.

Par contre qu'en est-il de sa performance ???

Une colonne auto incrémenté sera déclaré en "integer", tandis que l'UUID sera (???) déclaré en char(36).
La colonne auto incrémenté sera obligatoirement une clef primaire, et donc il y a unicité de la valeur.
Coté performance, l'accès va se faire par un index et donc l'accès sera directe, sans balayage de toutes les lignes de la table.

Pour la colonne UUID, un char en tant que clef primaire n'est pas une bonne solution.
Coté performance, l'index sera bien plus volumineux et de ce fait, la recherche dans l'index sera plus longue.
Franchement, je ne vois pas trop l'avantage de procéder ainsi.

Je cherche ID 253
Mysql passe-t-il toutes les lignes en lecture
00001 -> 00002 -> 00003 -> 00004 -> .... -> 00253 ou va-t-il directement à la ligne 253 car en auto-increment il sait ou aller chercher directement car il sait que c'est rangé par ordre croissant.

Si c'est un identifiant, la colonne est déclaré en tant que clef primaire.
De ce fait, votre index est unique et l'accès à la ligne de la table se fait directement.

Alors qu'avec UUID, il doit forcement lire ligne par ligne puisqu'il n'y a pas d'ordre croissant (pas d'auto-increment)

L'index va trier les UUID dans un ordre croissant, mais le problème est que le type sera char.
Donc volumétrie plus importante et de ce fait, recherche dans l'index plus longue.

Comprenez que tester 4 octets sera plus rapide que de tester 36 octets.

La bonne question est pourquoi avez-vous besoin, sous MySql d'utiliser un UUID ?

@+

[scamphp]

Avec

Code :

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

1
2
create table users(id_bin binary(16), name varchar(200));
insert into users values(unhex(replace(uuid(),'-','')), 'Andromeda');

BINARY (16) est ... bien ... juste binaire! Pas de jeu de caractères, pas de collation, juste seize octets.

11E570EA3A059CCBA4FBB026B977EB28 -> �p�:�ˤ� &�w�

On peut créer une vue de la table pour retransformer en 11E570EA3A059CCBA4FBB026B977EB28 pour une lecture humaine

Mais en réalité on n'a pas besoin de lire un ID donc �p�:�ˤ� &�w� c'est suffisant et cela n'est que un BINARY (16)

Concernant le début de l'UUID qui est commune c'est une UUID 1 et non une UUID 4

La version 1 crée une UUID spécifique à la machine qui l'exécute l'UUID 4 crée une clé unique quelque soit la machine qui l'exécute

[Artemus24]

Salut à tous.

Je constate que la gestion des UUID concerne MySql 8.0, donc de nouvelles fonctionnalités dans MySql.

N'ayant pas SQL Server sous la main,

Je crois qu'il y a une légère confusion.
L'article concerne MySql et non Microsoft SQL Server et il ne s'agit pas de SQLPRO mais de Mr. Guilhem Bichot.
--> https://mysqlserverteam.com/storing-...-mysql-tables/

J'ai fait une petite recherche sous MySql, et j'ai trouvé quelques nouvelles fonctions :
--> Bin_to_uuid()
--> Is_uuid()
--> Uuid()
--> uuid_short()
--> Uuid_to_bin()

J'ai utilisé les fonctions que j'ai à ma disposition, pour gérer les UUID.

J'ai testé la valeur du uuid(), ce qui donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
--------------
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid() union
select uuid()
--------------
 
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 1cf808aa-6334-11e8-81ed-0024814ba126 |
| 1cf80959-6334-11e8-81ed-0024814ba126 |
| 1cf80995-6334-11e8-81ed-0024814ba126 |
| 1cf809c4-6334-11e8-81ed-0024814ba126 |
| 1cf809f7-6334-11e8-81ed-0024814ba126 |
| 1cf80a26-6334-11e8-81ed-0024814ba126 |
| 1cf80a55-6334-11e8-81ed-0024814ba126 |
| 1cf80a89-6334-11e8-81ed-0024814ba126 |
| 1cf80ab8-6334-11e8-81ed-0024814ba126 |
| 1cf80ae7-6334-11e8-81ed-0024814ba126 |
| 1cf80b16-6334-11e8-81ed-0024814ba126 |
| 1cf80b49-6334-11e8-81ed-0024814ba126 |
| 1cf80b78-6334-11e8-81ed-0024814ba126 |
| 1cf80ba7-6334-11e8-81ed-0024814ba126 |
| 1cf80bd6-6334-11e8-81ed-0024814ba126 |
| 1cf80c0a-6334-11e8-81ed-0024814ba126 |
| 1cf80c34-6334-11e8-81ed-0024814ba126 |
| 1cf80c68-6334-11e8-81ed-0024814ba126 |
| 1cf80c97-6334-11e8-81ed-0024814ba126 |
| 1cf80cc6-6334-11e8-81ed-0024814ba126 |
| 1cf80cf5-6334-11e8-81ed-0024814ba126 |
| 1cf80d24-6334-11e8-81ed-0024814ba126 |
| 1cf80d57-6334-11e8-81ed-0024814ba126 |
| 1cf80d86-6334-11e8-81ed-0024814ba126 |
| 1cf80db5-6334-11e8-81ed-0024814ba126 |
| 1cf80de9-6334-11e8-81ed-0024814ba126 |
| 1cf80e1c-6334-11e8-81ed-0024814ba126 |
| 1cf80e4b-6334-11e8-81ed-0024814ba126 |
| 1cf80e7a-6334-11e8-81ed-0024814ba126 |
+--------------------------------------+
 
Appuyez sur une touche pour continuer...

Comme dans l'article, il semble qu'il y ait une partie fixe et une partie variable.
Cela ne pose aucun problème de ne pas réorganiser cette UUID pour obtenir la similitude dans incrémentation croissance.
Voici un petit exemple de création d'une base de données, avec une recherche sur une valeur données.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
CREATE TABLE `test`
(  `id`     binary(16)   not null primary key,
   `uuid`   char(36)     not null,
   `lib`    varchar(255) not null
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='un'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='deux'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='trois'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='quatre'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='cinq'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='six'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='sept'
--------------
 
--------------
set @val=uuid()
--------------
 
--------------
insert into `test` set uuid=@val,   id=uuid_to_bin(uuid), lib='huit'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='neuf'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='dix'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='onze'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='douze'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='treize'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='quatorze'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='quinze'
--------------
 
--------------
insert into `test` set uuid=uuid(), id=uuid_to_bin(uuid), lib='seize'
--------------
 
--------------
select    bin_to_uuid(id),
          uuid,
          lib
    from `test`
order by id
--------------
 
+--------------------------------------+--------------------------------------+----------+
| bin_to_uuid(id)                      | uuid                                 | lib      |
+--------------------------------------+--------------------------------------+----------+
| 8b6bd0f9-6338-11e8-81ed-0024814ba126 | 8b6bd0f9-6338-11e8-81ed-0024814ba126 | un       |
| 8b6bee87-6338-11e8-81ed-0024814ba126 | 8b6bee87-6338-11e8-81ed-0024814ba126 | deux     |
| 8b6d5f57-6338-11e8-81ed-0024814ba126 | 8b6d5f57-6338-11e8-81ed-0024814ba126 | trois    |
| 8b6f92b4-6338-11e8-81ed-0024814ba126 | 8b6f92b4-6338-11e8-81ed-0024814ba126 | quatre   |
| 8b728f14-6338-11e8-81ed-0024814ba126 | 8b728f14-6338-11e8-81ed-0024814ba126 | cinq     |
| 8b758401-6338-11e8-81ed-0024814ba126 | 8b758401-6338-11e8-81ed-0024814ba126 | six      |
| 8b774529-6338-11e8-81ed-0024814ba126 | 8b774529-6338-11e8-81ed-0024814ba126 | sept     |
| 8b79909d-6338-11e8-81ed-0024814ba126 | 8b79909d-6338-11e8-81ed-0024814ba126 | huit     |
| 8b7d8b03-6338-11e8-81ed-0024814ba126 | 8b7d8b03-6338-11e8-81ed-0024814ba126 | neuf     |
| 8b7e9205-6338-11e8-81ed-0024814ba126 | 8b7e9205-6338-11e8-81ed-0024814ba126 | dix      |
| 8b7f714e-6338-11e8-81ed-0024814ba126 | 8b7f714e-6338-11e8-81ed-0024814ba126 | onze     |
| 8b81e697-6338-11e8-81ed-0024814ba126 | 8b81e697-6338-11e8-81ed-0024814ba126 | douze    |
| 8b83c3a1-6338-11e8-81ed-0024814ba126 | 8b83c3a1-6338-11e8-81ed-0024814ba126 | treize   |
| 8b85e5f4-6338-11e8-81ed-0024814ba126 | 8b85e5f4-6338-11e8-81ed-0024814ba126 | quatorze |
| 8b868a65-6338-11e8-81ed-0024814ba126 | 8b868a65-6338-11e8-81ed-0024814ba126 | quinze   |
| 8b88dcea-6338-11e8-81ed-0024814ba126 | 8b88dcea-6338-11e8-81ed-0024814ba126 | seize    |
+--------------------------------------+--------------------------------------+----------+
--------------
select *
 from  `test`
where  id=uuid_to_bin(@val)
--------------
 
+------------------+--------------------------------------+------+
| id               | uuid                                 | lib  |
+------------------+--------------------------------------+------+
| ‹yc8èí $K¡& | 8b79909d-6338-11e8-81ed-0024814ba126 | huit |
+------------------+--------------------------------------+------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

Comme on peut le voir, le fait d'afficher une valeur en hexadécimal peut produire un affichage bizarre.

@+

[Artemus24]

Salut scamphp.

Oui et donc ?

@+

[scamphp]

Comme on peut le voir, le fait d'afficher une valeur en hexadécimal peut produire un affichage bizarre.

C'est pas grave c'est pas fait pour être affiché, mais pour gagner des octets BINARY (16)

Code :

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

1
2
3
4
5
6
| 1cf80d57-6334-11e8-81ed-0024814ba126 |
| 1cf80d86-6334-11e8-81ed-0024814ba126 |
| 1cf80db5-6334-11e8-81ed-0024814ba126 |
| 1cf80de9-6334-11e8-81ed-0024814ba126 |
| 1cf80e1c-6334-11e8-81ed-0024814ba126 |
| 1cf80e4b-6334-11e8-81ed-0024814ba126 |

il semble qu'il y ait une partie fixe et une partie variable.

Oui il y a un horodatage + marqueur spécifique


Alors docteur la conclusion suite à la découverte des nouvelles fonctionnalités de Mysql 8

Une clé de type �p�:�ˤ� &�w� est-elle toujours aussi nuisible ou pas

[Artemus24]

Salut scamphp.

Alors docteur la conclusion suite à la découverte des nouvelles fonctionnalités de Mysql 8

Cela dépend de ce que vous désirez faire avec vos UUID.
Si c'est juste informationnelle, une simple colonne dans une table suffit, et d'utiliser par ailleurs un identifiant auto incrémenté.

Par contre, si vous avez besoin d'avoir un identifiant UUID, le faire uniquement sur la table d'entrée dans votre base de données.
C'est-à-dire que vous devez utiliser deux clefs d'identifications !

L'une sera en tant que index unique, à savoir votre UUID et c'est par cette clef que vous allez rechercher votre ligne.
L'autre sera une clef auto incrémenté de type clef primaire où vous pourrez faire référence dans les autres tables en tant que clef étrangère.

Je pense que mettre partout une clef primaire en tant que UUID est une erreur, à cause des performance.
Et comme vous l'avez constaté, à faire que dans MySql 8.0.

Si vous désirez que je fasse un autre teste, vous n'avez qu'à me le demander, en bon français, svp.

@+

[scamphp]

Merci pour ta réponse...

Je débute et découvre en réalité les notions de clé primaire, clé étrangère etc etc...

Mais j'aime bien me poser des questions lol voila pourquoi j'étais partie sur l'UUID 4 (ou 1 car mysql semble ne produire que des UUID 1).

Pour comprendre les avantages et inconvénients

[scamphp]

Je trouve cela plus logique uen clé �p�:�ˤ� &�w�

Que ID 1 qui correspond à mon article 1

User ID 1 qui correspond à l'admin

En plus j'avais lu que c'étai mieux aussi niveau sécurité de ne pas lier une logique de contenu à une logique de clé

Et si un jour on veut synchroniser une table ID auto-incrément semble poser des problème alors que UUID non

[Artemus24]

Salut scamphp.

Quand on débute, il y a deux questions à ne pas négliger :

• la modélisation de votre base de données
• les notions de performances

La première notion permet de respecter les formes normales et de répondre à votre besoin fonctionnel.
La deuxième notion est de trouver l'aspect technique le mieux adapté à ce que vous désirez faire.

Et si un jour on veut synchroniser une table ID auto-incrément semble poser des problème alors que UUID non

Je ne vois pas pourquoi il y aurait des problèmes de synchronisation avec l'auto incrément et pas avec UUID.
Je pense qu'il s'agisse plutôt d'une maîtrise de la réplication, plutôt que d'un bug dans mysql.

@+

[scamphp]

Justement, j'en suis exactement là. la modélisation de la base de donnée

Je sais un ID dans l'URL c'est plus rapide, mais je fais le choix de ne mettre que le SLUG type nom de l'article en chaine de caractère.

Modélisation Simple : Ma table POST

ID | SLUG chaine de Caractère | Titre | Méta | description | Catégorie | ARTICLE


Comme j'aurais pas ID dans mon URL je devrais chercher dans la table POST pour trouver le SLUG correspondant. Je sais c'est moins performant qu'un ID, mais pour le coup là c'est un choix.


Ma question est : pour limiter la casse est ce que c'est mieux de créer une table SLUG indépendante donc avec moins de colonne et donc plus légère

Table SLUG

ID | SLUG chaine de Caractère

Puis de faire une jointure avec la table POST

ID | Titre | Méta | description | Catégorie | ARTICLE


On lit tout et son contraire, alors je voulais avoir vos avis critiques et constructif (sauf sur l'abandon de l'ID ou la c'est un choix).

[scamphp]

Artemus24 m'indique

Quand on débute, il y a deux questions à ne pas négliger :

la modélisation de votre base de données
les notions de performances

Alors je lui répond lol même si cela recoupe un autre sujet...
C'est en complément de la discussion initiale pas en SPAM de l'autre sujet....

Je posais la question par rapport à l'article https://blog.developpez.com/sqlpro/p...mances_petites

Si votre ligne rentre dans une page (innodb_page_size à 16k), je ne vois pas pourquoi vous devriez créer une autre table plus petite.

Alors c'est quoi la vérité si je mens Base de données et performances… petites tables et tables obèses ! au risque de parler d'un 3ème sujet

[CinePhil]

Votre question d'origine dans cette discussion portait sur le choix à faire entre une clé primaire auto-incrémentée ou une colonne de type UUID comme clé primaire.
On vous a expliqué assez largement pourquoi la clé primaire auto-incrémentée est meilleure.

Si vous voulez parler d'autre chose, ouvrez une nouvelle discussion !

[scamphp]

ok

[Artemus24]

Salut scamphp.

Quel est la taille de votre colonne "SLUG chaine de Caractère" ?
Quel est la taille total de votre ligne ?
Et avez-vous seulement que sept colonnes ?

Si votre ligne rentre dans une page (innodb_page_size à 16k), je ne vois pas pourquoi vous devriez créer une autre table plus petite.

@+