MySQL / MariaDB : des affirmations hasardeuses !

J’ai lu, avec attention, l’article de Frédéric Brouard sur MySQL/MariaDB. Rappelons qu’il est MVP (Microsoft Most Valuable Professional) et accessoirement écrit des livres sur SQL Server. Si tous les éléments présentés sont extrêmement factuels (il en a oublié quelques uns comme la complication à faire des LEFT JOIN et des RIGHT JOIN en cascade dans la même requête), je voudrais dire que son affirmation selon laquelle les moteurs de bases de données MySQL / MariaDB ne seraient pas relationnels et transactionnels est fausse. Archi fausse.

MySQL / MariaDB : des affirmations hasardeuses !Sa démonstration sur la modification de la valeur d’un champ à valeur unique est un peu tombée à l’eau. Dans nos pratiques, nous claquons systématiquement sur toutes les tables « parent » des clés primaires sous forme de compteur. A l’exception de modifications en cascade sur les tables « enfant », il n’y a donc jamais lieu de modifier directement la valeur de cette clé au niveau de la table « parent ». Or, MariaDB et MySQL prennent en compte la mise à jour des valeurs de clés en cascade !  Et son exemple sur la modification des valeurs d’un champ sur laquelle porte une clé d’unicité est tout simplement impossible à réaliser puisque les valeurs 1,2,3 ayant été saisies préalablement, il n’est pas possible de passer la valeur de 1 à 2 et de 2 à 3, puisqu’elles existent au niveau de la colonne ! Je ne vois pas en quoi, dans cet exemple, MySQL et MariaDB ne seraient pas relationnels, alors qu’il s’agit d’un problème de champs à valeur unique !!! Il y a là un contresens total dans la démonstration.

Oui, MySQL / MariaDB est transactionnel en motorisation InnoDB.  Vous pouvez tester ce code : il marche.

CREATE TABLE t (c DATETIME) ENGINE=InnoDB;
BEGIN WORK;
INSERT INTO t VALUES (NOW());
ROLLBACK WORK;
SELECT c FROM t;

Pour être plus précis, Frédéric parle de validation automatique de la transaction, sans possibilité de ROLLBACK lorsque l’utilisateur courant procède à la modification de la structure de la table. Oui, effectivement, dans ce cas précis, MariaDB / MySQL procède à un COMMIT automatique implicite. C’est évidemment totalement faux lorsque l’utilisateur de la transaction et celui qui modifie la table sont différents. On ne peut pas reprocher aux développeurs d’un moteur de faire ce type de choix qui ne remet absolument pas en cause le caractère transactionnel de la motorisation InnoDB.

Autre erreur de Frédéric Brouard, lorsqu’il évoque des problèmes de consistance des sauvegardes de données. Il existe aujourd’hui un utilitaire de sauvegarde, MariaBackup, qui pallie les limites inhérentes aux mécanismes de sauvegarde logique. L’auteur ne s’est peut-être pas donné le temps de creuser suffisamment son sujet !

Je voudrais faire deux dernières observations qui, à mes yeux, décrédibilisent plus sérieusement l’auteur. Le diable est toujours dans les détails. Issu du MCD et du MLD, le MPD reprend le nom des entités, puis des relations. Il n’y a donc pas lieu de préfixer les noms de tables par des T. C’est plus qu’une faute de goût ! Ce n’est tout simplement pas relationnel, lui qui se définit comme un expert du modèle relationnel. La 2e remarque tient ensuite au fait qu’on ne met jamais les noms de tables en majuscule, pour des raisons qui tiennent au problème de migration entre Windows et Linux.

Base de données  / DBA 

Commentaires

Non, désolé, MySQL n’a presque rien d’un SGBD Relationnel. Sur les 12 règles de Codd édictées en 1985 par le créateur des SGBD Relationnels (https://sqlpro.developpez.com/SGBDR/ReglesCodd/) il n’est conforme que sur 7 à 8 d’entre elles…
Codd avait publié deux articles à ce sujet dans Computer World en 1985, parce que déjà de nombreux produit affichant le mot « relationnel » dessus, ne l’était pas !

Même PostgreSQL ne l’est toujours pas, mais fournit une rustine pour contourner la fameuse règle des opérations ensemblistes….

@Frédéric

Les exemples que vous fournissez dans l’article ne donnent aucun raison de croire que MySQL et MariaDB ne sont pas relationnels et transactionnels. Il y a des éléments justes dans votre article sur les limitations du moteur de bases de données.

« Et son exemple sur la modification des valeurs d’un champ sur laquelle porte une clé d’unicité est tout simplement impossible à réaliser puisque les valeurs 1,2,3 ayant été saisies préalablement, il n’est pas possible de passer la valeur de 1 à 2 et de 2 à 3, puisqu’elles existent au niveau de la colonne ! »
C’est justement parce que vous raisonnez en itératif, comme MySQL, que vous voyez une impossibilité.

Alors qu’un vrai SGBDR fonctionne de façon ensembliste, donc doit pouvoir exécuter cette requête, puisqu’il n’y a aucun doublon dans l’ensemble résultat (2, 3, 4). Ça doit se comporter comme si toutes les données étaient changées d’un coup. D’un point de vue implémentation, c’est bien entendu impossible de tout changer d’un coup, il faut bien faire du séquentiel, mais pour simuler le comportement ensembliste, il faut imbriquer les différentes étapes en séparer les mises à jour de valeurs des contrôles d’intégrité. D’abord on met tout à jour, peu importe l’ordre, puis on fait toutes les vérifications d’intégrité. Et on ne sort alors pas en erreur, puisque chaque valeur est bien unique.

D’ailleurs, en itératif, le fait que cette requête passe ou non dépend de l’ordre des données… Si au lieu d’avoir inséré 1 puis 2 puis 3 on insère 3 puis 2 puis 1, la requête de mise à jour passe sans problème avec MySQL.

Le simple fait que le succès ou non d’une requête dépende de l’ordre d’insertion des données et non pas uniquement des données elles même. C’est un défaut majeur, car on arrive à des comportements non déterministes.

Petite précision oubliée : dans cet exemple, il y a un moyen de s’en sortir quand même avec MySQL, en ajoutant un ORDER BY C DESC dans la requête d’update.

Mais c’est crade au possible et ça ne fonctionne que dans certains cas.

Par exemple, s’il s’agit de corriger une inversion entre deux colonnes (SET A=B, B=A) avec des valeurs communes dans les colonnes A et B, c’est mort, le ORDER n’aidera pas, la seule solution est de supprimer temporairement la contrainte d’unicité, puis de faire l’update, puis de remettre la contrainte d’unicité… Avec tous les risques que ça implique, puisque le changement de structure empêche tout rollback…

@LFS

C’est crade, en effet.

Laisser un commentaire

(requis)

(requis)