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