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

32  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
23  0 
Avatar de FatAgnus
Membre confirmé 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 ?
14  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 confirmé 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 !
7  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.
7  0 
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
7  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
7  0 
Avatar de webMCA
Membre du Club https://www.developpez.com
Le 25/07/2019 à 10:51
Autant je comprends certains de ses arguments et je le remercie de pointer tout ça du doigt, autant je trouve presque hallucinant qu'un expert comme lui (qui plus est enseignant) se soit aussi mal documenté et ose affirmer certaines choses qui sont démontées par d'autres experts (je dois avouer que je suis très loin des compétences des différents intervenants concernant les bases de données).

Autre chose qui m'étonne fortement est l'absence de réponse lorsqu'on pointe du doigt une erreur ou une imprécision alors qu'il participe vertement à la discussion lorsqu'il est persuadé d'avoir raison.

Donc merci FatAgnus d'avoir compilé ce que tu penses erroné ou trompeur.

Merci également aux membres qui ont jugé utile de mettre une note négative à mes interventions (si ils pouvaient m'expliquer pourquoi j'accepterai volontiers les critiques).

Dans l'attente, toujours, d'une intervention de Mr SQLPro / Frédéric BROUARD. (je me permet de rappeler que des excuses ou un mea culpa sont tout à l'honneur de la personne qui les présente).
9  2 
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).
6  0