MySQL : pas un bon choix en entreprise

MySQL n'est pas un bon choix comme SGBDr dans le SI d'une entreprise !

MySQL recèle de nombreux dangers

L'article Découvrez les dangers de MySQL et MariaDB décrit précisément tous les problèmes de ce moteur de base de données. Mais on peut le suspecter d'analyser tout ceci, avec un point de vue très marqué : voir les 2 sous chapitres suivants pour des remarques sur les "affaires" indiqués ainsi que sur la non comparaison entre MyISAM et InnoDB.

De plus, si on utilise MySQL pour construire un seul logiciel (typiquement avec PHP) et à fortiori si l'équipe de développement est réduite (voire une seule personne), certains problèmes n'ont plus lieu d'être ou peuvent facilement être surmontés (à partir du moment où ils ont été identifiés). D'autres problèmes sont des cas d'utilisation très spécifiques qui ne gèneront donc pas le plus grand nombre ... cependant, le jour où vous tombez dedans, vous serez bien ennuyés.

Le même auteur a écrit un autre article listant de nombreuses limitations de MySQL.

Les "affaires"

Les "affaires" décrites dans l'article sont détaillées ci-dessous. A noter que pour moi aucune n'est lié avec le SGBDr utilisé :

Uber sanctionné de 400 000€ sur le site de la CNIL, et sur le Nouvel Obs. : aucun lien avec un SGBDr, ce sont des identifiants (et mots de passe) qui ont été laissé en libre accès sur la plateforme de développement Github (dans les sources).
Amende de 250 000€ à Bouygues : un simple changement d'URL permet d'accéder aux données d'abonnés, ceci est un problème de l'application et non pas de la gestion des fichiers par le SGBDr
Amende de 30 000€ à l'Alliance Française : encore une fois un changement de l'URL permet d'accéder à des documents, le problème ne vient pas de la méthode de stockage des documents mais de l'accès par l'url via l'application : encore un problème applicatif.
Amende de 75 000€ àl'ADEF : toujours un changement d'url qui permet d'accéder à des informations de personnes gérées par l'organisme, les pdf étaient même recensés par Google. Toujours un problème applicatif pour moi et pas du SGBDr.
Amende de 400 000€ à un hopital portugais : cela n'est pas lié aux fonctions du SGBDr utilisé mais la gestion des habilitations dans le logiciel de l'hopital
Amende de 500 000£ à Equifax pour vol de données [EN] à noter que l'amende a été de 700 milions de $ aux États Unis, et que l'intrusion n'est pas lié à un SGBDr mais à un patch non appliqué sur Apache Struts (un framework de développement Java web). Enfin en dehors, de la non application du patch il a été retenu contre Equifax, une mauvaise rétention des données, et de mauvaises pratiques d'audit.
Amende de 20 000€ à Knuddels : tout ce que j'ai pu trouver c'est que c'est un piratage qui a "fuité" des adresses e-mails ainsi que des identifiants (et mots de passe) qui aurait pu être chiffré, même avec MySQL. De plus, manifestement le piratage est survenu en raison de mises à jour de sécurité non effectuées.
Amende de 50 000€ pour Daily Motion : de nouveau, un piratage a amené à la "fuite" de données privées (e-mails, identifiants et pour moins d'un quart, le mot de passe crypté), l'intrusion a été réalisé grace à un mot de passe laissé en clair sur Github et grace à la détection d'une faille repérée dans le code déposé sur Github : donc de nouveau aucun lien avec le SGBDr (la CNIL a reconnu que l'intrusion était sophistiquée).

MyISAM ou InnoDB

Ce qui est dommage, dans cet article, est de ne pas avoir mentionné la différence de comportement de MySQL selon le moteur utilisé. En effet, MySQL est un des rares SGBDr (le seul ?) qui propose plusieurs moteurs de bases de données dont les 2 plus connus sont MyISAM et InnoDB. MyISAM a longtemps été le moteur par défaut, probablement car il est supposé avoir la meilleure performance pour des applications web (beaucoup de lectures, et des insertions) mais il a beaucoup d'inconvénients : pas de transactions, pas de clefs étrangères, pas de row level locking, recovery complexe après un crash.
InnoDB permet de gérer les clefs étrangères, le row level locking, les transactions et gère mieux l'intégrité des données. Le seul inconvénient peut être une performance moindre mais ce n'est pas certain et cela dépend des opérations effectuées. De toute manière, vu les inconvénients de MyISAM, cela ne peut être le moteur utilisé pour une application sérieuse. InnoDB est d'ailleurs le moteur par défaut depuis la version 5.5 !

La solution ?

Pour moi, vu tous les problèmes posés par MySQL la solution est d'utiliser un autre SGBDr qui lui est de meilleure qualité : c'est PostgreSQL. Tous les problèmes décrit dans Découvrez les dangers de MySQL et MariaDB sont résolus en utilisant PostgreSQL : même le problème du chiffrement peut être résolu avec SEPostgreSQL.

Plus de lectures sur MyISAM vs InnoDB

Une présentation succinte (et un peu ancienne) des avantages/inconvénients entre les 2.
Un article de Liquid web [EN] présentant des cas concrets d'utilisation.
Un post de Stackoverflow [EN] sur le sujet avec beaucoup d'information.

En conclusion

Pour gérer un site web dynamique, l'utilisation de MySQL ne posera pas de problèmes (d'autant plus qu'on utilisera InnoDB). A noter que près de 40% des sites dans le monde utilise WordPress (qui fonctionne avec PHP+MySQL).

Mais dans le cas d'un SI, avec de nombreuses applications différentes (et équipes de développement) utilisant la même base de données, un SGBDr comme PostgreSQL (voire un SGBDr propriétaire si certaines fonctions sont nécessaires) sera largement préférable.