Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Découvrez les dangers de MySQL et MariaDB
Par Frédéric BROUARD (SQLpro)

Le , par SQLpro

0PARTAGES

34  4 
Chers membres du club,

J'ai le plaisir de vous présenter cet article :

Cet article a donc pour but de vous démontrer que MySQL/MariaDB n’est pas compatible avec la sûreté, la qualité et les performances attendues par l’entreprise. Il en est même dangereux ! Lire la suite de l'article...
Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre les bases de données MySQL.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de miaou_
Membre du Club https://www.developpez.com
Le 19/07/2019 à 9:16
Bonjour,
article intéressant mais très (trop) à charge.
Le principal reproche que je ferais à votre article concerne la forme : le ton employé assez sarcastique donne moins de poids à vos arguments (c'est mon avis).
Je comprends bien que ce ton est en adéquation avec votre fonction (expertise et audit de base de données), mais pour moi, cela ne le fait pas...
Certains chapitres semblent vouloir effrayer le lecteur:
  • celui listant les amendes dans les stockages de documents électroniques, alors que les failles relevées n'ont pour moi que très peu de rapport avec des fonctionnalités pures de sgbd. Il est plutôt rare (à ma connaissance) de laisser la gestion des documents électroniques au sgbd, cela est effectué par des systèmes informatiques dédiés possédant de nombreuses autres fonctionnalités dans ce domaine.
  • celui sur le chiffrement est hors sujet depuis MariaDB 10.1[.4] (voir ici). Je ne sais pas si cela répond totalement à vos attentes, mais donne néanmoins une autre vision de MariaDB.


Ensuite, n'étant pas expert en base de données, simple utilisateur depuis 20 ans de certains gros systèmes (Oracle, DB2 principalement), vous laissez penser que les solutions propriétaires sont le graal (notamment SQLServer qui revient souvent dans votre article). J'en doute fortement par mon expérience.
En plus d'être (très) coûteuses, ces solutions sont opaques. Vous semblez être expert en SQLServer notamment, sachez que côté Oracle, les opérations de support et maintenance sont très compliquées... sauf à payer le prix fort en abonnement adéquat (et encore, les bugs remontés ne sont jamais remontés dans un hotfix).

MySQL/MariaDB ont en effet de grosses lacunes, sur les points que vous évoquez (même si certains restent anecdotiques de mon point de vue),
mais il s'agit d'un moteur sgbd (ou de 2 ^^) possédant sûrement quelques qualités que vous ne citez pas (je ne le ferai pas moi-même, n'étant pas expert dans le domaine). Et sa gratuité et son aspect open-source sont un plus pour beaucoup, même dans le milieu de l'entreprise.

Je tiens quand même à vous remercier pour cet article, certains points m'étaient méconnus,
et puis, tout est question de nuances ;-)

Bonne journée,
Nicolas
27  0 
Avatar de FatAgnus
Membre éprouvé https://www.developpez.com
Le 22/07/2019 à 23:10
Le nom n’a d’ailleurs pas été choisi au hasard. MySQL ne signifie-t-il pas que c’est « mon petit business », loin des nécessités professionnelles d’une entreprise ?
Le nom « MySQL » vient du prénom de la fille du cocréateur Michael Widenius, sa fille se prénomme « My ». Ce début illustre bien l'état de l'esprit de l'auteur rempli de préjugés et prêt à enfoncer MySQL à chaque occasion. Le benchmark date de 2014 et mesure MySQL 5.6. En cherchant un peu Michael Widenius aurait pu trouver des benchmarks de MySQL 4.0.

Article qui aurait pu être intéressant s'il avait été impartial, mais bon venant d'un MVP Microsoft qui écrit des livres sur SQL Server pouvait-on en espérer autre chose ?
15  2 
Avatar de escartefigue
Expert éminent sénior https://www.developpez.com
Le 20/07/2019 à 11:13
Citation Envoyé par tanaka59 Voir le message
Bonjour,

Dans les truc farfelus de mysql j'ai trouvé ceci :

Créez une table ou vous injectez automatiquement de la data. Votre clef est un autoincremente. L'autoincremente a une gestion désastreuse des numéros ... Vous insérez 10000 lignes , votre compteur passe de 5000 à 7000 sans raison vous arrivez donc à 12000 .

Vous pensez au final avoir 12000 , erreur ! Vous en avez bien 10000 ... Pourquoi un tel comportement ? L'autoincremente n'est pas au point.

C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...
Voilà un discours symptomatique de la méconnaissances du fonctionnement des identifiants attribués par les SGBD, l'auto-incrémenent n'est pas en cause.

La présence de trous est tout à fait normale et n'est pas spécifique à MySQL.

- les identifiants attribués par le moteur qui ne sont pas commités sont perdus
- la valeur initiale de l'identifiant est paramétrable, rien n'interdit de démarrer avec une valeur différente de zéro ou un
- le pas d'incrément est paramétrable (pour MySQL, c'est la variable AUTO_INCREMENT_INCREMENT qui pilote cet incrément, MySQL prévoit jusqu'à 65535 comme valeur d'incrément)
- certains SGBD permettent en outre de choisir au choix un incrément ou un décrément
- certains SGBD permettent également de revenir à la valeur initiale si. le compteur a atteint le max, (il faut bien sur en ce cas que les identifiants anciens aient été supprimés physiquement de la DB sinon il y aura plantage pour clef en double).
- pour éviter de solliciter le moteur de la BDD à chaque insert, certains SGBD réservent ces identifiants par plage (la taille de la plage étant paramétrable). Chaque thread ayant besoin d'un nouvel identifiant, en récupère un dans cette plage, mais, bien sur, il est possible que tel thread fasse son commit avant tel autre et enregistre ainsi un identifiant d'une valeur supérieure à celle de l'identifiant d'un autre thread qui n'a pas encore commité.

Ces deux derniers phénomènes justifient que les identifiants ne sont pas toujours chronologiques.
10  0 
Avatar de FatAgnus
Membre éprouvé https://www.developpez.com
Le 25/07/2019 à 10:24
Citation Envoyé par webMCA Voir le message
SQLPro, des excuses, peut-être, concernant cette erreur dans votre article concernant l'origine du nom "mySQL" ?
A tout le moins un "ERRATA" ?
Je ne pense pas qu'il faut s'attendre à des excuses ou des corrections de la part Frédéric Brouard, cet article s'inscrit dans la ligné des articles Fear, uncertainty and doubt publiés il y a quelques années par Microsoft contre Linux.

Je ne suis pas un expert SQL ni en FUD comme Frédéric Brouard, mais à mon humble niveau j'ai relevé quelques tromperies :

Tromperie sur le nom de MySQL : MySQL s’appellerait MySQL car il ne serait pas un produit professionnel alors que le nom vient du prénom de la fille du cocréateur de MySQL Michael Widenius. Dans tout l’article MySQL est qualifié de produit non professionnel et comme un outil de bidouilleur. Alors que MySQL est développé par Oracle depuis dix ans. MySQL est bien développé par des professionnels, des développeurs d'Oracle payés pour, et utilisé par des professionnels. D'ailleurs Frédéric Brouard avoue avoir un ou des clients qui utilisent MySQL.

Tromperie sur les benchmarks : des benchmarks mesurant les performance de MySQL 5.6 sorti en février 2013, voilà plus de six ans, alors que MySQL 5.7 et 8.0 sortis depuis sont données comme plus performants. Il faudrait rappeler à l'auteur que nous sommes en 2019 et des des benchmarks d'un logiciel de 2013 n'ont que peu d'intérêt.

Références sur des sanctions sans rapports avec MySQL. Des références à des amandes à des sociétés ne respectant pas le RGPD ou pour ne pas avoir respecté les données des utilisateurs, dans le seul but d'attiser la peur de MySQL, alors que rien de dit que ces sociétés utilisaient MySQL (peut-être ces sociétés utilisaient-elles SQL Server ou des fichiers textes bruts, rien ne le dit).

Tromperie sur la taille du code. Confusion de la taille d'installation avec la taille du code. Puisque MySQL occupe 210 Mo et SQL Server et 7 720 Mo, donc SQL Server contiendrait 37 fois plus de code. Conclusion plus que douteuse, puisque rien ne prouve que les fichiers installés dans le cas de SQL Server soient tous des binaires, et il me semble, sauf erreur de ma part, que SQL Server fournit aussi certains autres programmes avec une interface graphique. Enfin les binaires générés dépendent aussi du compilateur. Microsoft ne communique pas me semble-t-il sur la taille du code de SQL Server.

Tromperie sur les bugs : MySQL est un projet open source, donc la liste des bugs est ouverte. Microsoft ne communique pas sa liste de bugs il me semble, alors comment comparer ? Le site feedback.azure.com (comme le nom « feedback » l'indique) est destiné aux utilisateurs, pas aux développeurs de SQL Server.

Tromperie sur les bugs : MYSQL, MySQL comporte 73 738 bugs (d'où l'auteur tient-t-il ce chiffre ?) donc c'est un outil de bidouilleurs. L'auteur oublie que tous les projets open source, de fait de leurs natures open source, ont une toujours de grandes listes de bugs. Exemple le projet Chromium comporte 61 801 bugs , Chromium est donc un projet de bidouilleurs sur lequel Microsoft va baser son navigateur web Edge qui, si on suit le raisonnement de l'auteur, exposera les utilisateurs de Windows à des malfaçons. Je n'ai pas recherché le nombre de bugs ouverts dans le noyau Linux ou Mozilla Firefox, mais je pense qu'on doit atteindre des chiffres similaires.

Tromperie sur les bugs : 73 738 bugs laissent à penser qu’un très grand nombre d’utilisateurs ont été victimes des malfaçons. L'auteur essaie de tromper le lecteur en faisant un parallèle douteux entre le nombre de bugs et les failles de sécurités. Un bug n'est pas forcément une faille qui pourrait être utilisée comme une malfaçon.

Tromperie sur les CVE : l'informatique pour l'auteur s'est arrêté en 2016, benchmark de 2016 d'un logiciel de 2013 et des CVE de 2010 à 2016. Pour rappel nous sommes mi-2019 et l'informatique est un domaine qui évolue très vite. Puisque MySQL possède 35 fois plus de CVE que SQL Server sur la période entre 2010 et 2016, MySQL serait 35 fois pire que SQL Server en 2019. L'auteur oublie aussi qu'il faut tenir compte du niveau des failles, évaluées de zéro à dix ainsi que le temps de correction de ces failles.

Enfin pourquoi la faille dans la conception de MySQL permet à des serveurs malveillants de voler des fichiers à des clients, si c'est une faille ne fait-elle pas l'objet d'un CVE ? Si c'était le cas un CVE existerait, où est ce CVE ?

On notera aussi la confusion entre le libre et l'open source, l'auteur ne semble pas faire la différence. MariaDB et MySQL sont des projets open source. Je ne pense pas que l'objectif d'Oracle en développant MySQL soit que les utilisateurs puissent profiter des libertés du logiciel libre.

Enfin l’article dénigre aussi le logiciel libre et open source (qu'il confond). Certaines technologies seraient hors de portée du monde libre. Comme si la licence d'un logiciel ait quelque chose à voir avec son implémentation et sa qualité. Une manière détournée d'enfoncer encore plus MySQL, qui puisque MySQL est open source, il n'arrivera jamais à la cheville de SQL Server le Saint-Graal des bases de données.

L'auteur semble bien connu pour s'être donné comme mission de faire de la propagande SQL Server au détriment des base de données open source, et il fait ça depuis très longtemps. J'ignore pourquoi l'auteur s'est donnée cette mission, il ne serait pas surprenant qu'il en tire quelques avantages en coulisses.
13  3 
Avatar de Gregslv
Membre à l'essai https://www.developpez.com
Le 19/07/2019 à 10:16
Désolé, mais comme miaou_, je n'adhère pas du tout au discours.

L'exemple IV.A en est la parfaite illustration ... SQLServer n’empêchera absolument pas la suppression d'un fichier si le serveur est arrêté ! Le sujet chiffrement est traité tout autant à charge, cela donne l'idée du reste de l'article ! Enfin, laisser penser que MySQL est réalisé par un suédois dans son garage alors qu'il appartient depuis plus de 10 ans à Sun puis à Oracle ...

N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !
10  1 
Avatar de escartefigue
Expert éminent sénior https://www.developpez.com
Le 19/07/2019 à 16:06
Citation Envoyé par stephweb Voir le message
C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
Je m'explique :
Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

Pour détourner ce "problème", pour résumé je fais ceci :
Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.
Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple
9  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 19/07/2019 à 11:12
Très bon article recensant de nombreux points.

Certains considère l'article à charge. Le ton peut effectivement laisser penser cela, mais les faits sont pourtant bien là !

Je rajouterai pour ma part le problème d'intégrité des données suite à un arrêt brutal du service (bug, crash serveur, kernel panic, etc...). Perdre une BD à cause de ça, c'est possible avec MySQL, alors qu'un SGBD digne de ce nom encaisse sans broncher ce genre d'interruption.

Citation Envoyé par Gregslv
N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !
SQL Server coute cher pour les versions Enterprise et Standard. La version Express est tout à fait abordable (gratuite !) et est même disponible maintenant sur... Linux ! Et avant d'arriver aux limites de la version Express, et bien, il faut y aller ! (4 coeurs, 10G par BD hors fonctionnalité FileStream).
8  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 19/07/2019 à 14:55
Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire dans premier temps côté code.
Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.

Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.
En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.
8  0 
Avatar de Xurudragon
Membre du Club https://www.developpez.com
Le 19/07/2019 à 16:37
Citation Envoyé par stephweb Voir le message
Yes.
Mais beaucoup de dév utilisent les id pour les numérotations de factures.
Mais là ce n'est, encore une fois, pas un problème de SGBD, mais un problème de connaissance du/des développeurs
8  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 19/07/2019 à 13:45
Je trouve également l'article à charge. Je l'ai quand-même trouvé intéressant, et je sais que tu n'aimes pas du tout MySQL.

Je ne suis pas du tout expert dans le domaine (je vais donc peut-être dire des bêtises), mais voici mes remarques/interrogations.

Beaucoup de développeurs n'ont pas remarqué cela et laissent en production cette collation qui peut s'avérer une bombe à retardement en matière de gestion des données accentuées, car le jeu de caractères accentués de la langue suédoise n'est pas compatible avec les principaux accents du français.
Intéressant et probablement en adéquation avec les posts réguliers sur ce type de problème dans nos forums. Mais il suffit de changer celle-ci.

MySQL/MariaDB, un SGBD non relationne
InnoDB est un moteur de stockage pour les systèmes de gestion de base de données MySQL et MariaDB. Il est inclus et activé dans toutes les distributions fournies par MySQL AB depuis la version 41 et devient le moteur par défaut à partir de MySQL 5.5.52. Son principal avantage par rapport aux autres moteurs de stockage de MySQL est qu'il permet des transactions ACID (atomiques, cohérentes, isolées et durables), ainsi que la gestion des clés étrangères (avec vérification de la cohérence). Autrement dit, InnoDB est un moteur de bases de données relationnelles et transactionnelles, à l'image de celui utilisé par son concurrent Open Source PostgreSQL.
Donc qui ment ?
Je pense que c'est plus compliqué que cela, voir cette discussion sur le sujet.

J'en conclus que MySQL est relationnel au moins en partie. Sur l'exemple présenté, je ne peux pas juger, mais vu l'auteur je pense qu'il a raison et que dans l'exemple fourni, MySQL ne conviendra pas.

À l’exception de MySQL/MariaDB, tous les SGBD relationnels, PostGreSQL compris, disposent d’un catalogue(5)
Et la table système INFORMATION_SHEMA c'est quoi alors ? un tutoriel sur le sujet.

Disparition des objets de la base
J'ai fait un test, j'ai supprimé le fichier de définition de .frm, la base a continué de fonctionner, jusqu'au redémarrage du serveur.
J'ai essayé de recréer une base après copie du fichier db.opt et recréation de celle-ci avec le même shéma, la recopie du fichier db.opt ne m'as pas permis de récupérer les données. Avec SQL Server tout est dans le fichier .mdf et .ldf, je ne sais pas si il est possible de remonter une base directement depuis une copie de ces fichiers en l'état, mais ce n'est de toute façon pas une bonne méthode. Le fait qu'il n'est pas possible de supprimer les fichiers .mdf depuis l'interface graphique Windows indique uniquement que les services SQL-Server les bloquent. Il suffit de stopper ces services et la même connerie peut être faite. On ne bidouille pas des fichiers de Program files sans risquer de conséquences.

Cette absence de table système constituant le catalogue exigé par Codd, contraint MySQL/MariaDB à valider automatiquement toutes les transactions de tous les utilisateurs sans leur demander leur avis dans certaines circonstances
Extrait de la doc :
CREATE TABLE and DROP TABLE statements do not commit a transaction if the TEMPORARY keyword is used. (This does not apply to other operations on temporary tables such as ALTER TABLE and CREATE INDEX, which do cause a commit.) However, although no implicit commit occurs, neither can the statement be rolled back, which means that the use of such statements causes transactional atomicity to be violated. For example, if you use CREATE TEMPORARY TABLE and then roll back the transaction, the table remains in existence.
https://dev.mysql.com/doc/refman/5.7...it-commit.html

Ça ne semble pas être le cas pour CREATE TABLE ou DROP TABLE. Pour le reste, je ne comprend pas les impacts. Et je ne connais pas les normes.

Pour les "calculs faux", MySQL retourne NULL. Si on teste le retour, on voit bien un problème. Je présume que ceci permet de retourner une valeur sans interrompre la requête tandis qu'une gestion en "strict mode" permet une interruption ?

Sauvegarde non consistente.
Pour avoir une sauvegarde consistante, il faut effectivement mettre un verrou sur les tables avant de faire un mysql dump. En utilisant LVM, il suffit de locker les tables, créer le cliché, puis déverrouiller tout de suite les tables. Le SQL Dump depuis le cliché sera cohérent. C'est plus ou moins ce que dois faire SQL Server avec VSS. Il est possible aussi d'utiliser des outils comme Percona Xtrabackup, gratuit, qui permet en plus des sauvegardes incrémentielles. C'est externe à MySQL mais répond au besoin. Dans les deux cas(SQL Server et MySQL) il est possible de monter un cluster,le le problème de sauvegarde se réglant en bloquant temporairement un membre du cluster.

Les condamnations CNIL ne concernent pas des problèmes liées à la base de données mais au site lui-même. Utiliser une base cryptée, et/ou autre que MySQL n'aurait rien changé, les failles se situant au niveau du code du site. Dans tous les cas cités, la modification de l'URL permettait d'interroger la base sur des critères inadéquats.

Il ne sert à rien de crypter une base données si la vulnérabilité se situe au niveau de son point d'entrée comme un site web. Cela revient à mettre une porte blindée quand un voleur peut entrer par la fenêtre.

Je pense que MySQL, même si il n'est pas parfait, est un bon compromis pour des petites bases, notemment pour le web, comme le dit l'auteur de l'article. Dans le cas de grosses bases, ce sera de toute façon SQL Server ou Oracle (postGreSQL est un challenger, mais quel est l'interet par rapport à Oracle par exemple ?). On ne va pas utiliser de camionettes pour transporter plusieurs tonnes, tout comme on ne va pas utiliser un un camion à remorque pour transporter une palette. Sur de grosses bases, la notion de côut est un critère négligeable car en général les acteurs on les ressources derrière.
8  1