Discussion :

[FatAgnus]

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 ?

[SQLpro]

Je n'ai pas les compétences pour juger mais je ne pense pas que MySQL soit un si mauvais produit que ça, de grandes banques françaises l'utilisent….

Je serais curieux d'avoir des références précises. Travaillant avec la plupart des banques françaises et donnant des formations à Orsys ou de nombreux clients viennent du monde bancaire de l'IT, je n'en ai presque jamais vu...

…
Au niveau volumétrie, je pense que MySQL peut tenir de grosses bases, mais que en restant dans le libre il vaut mieux utiliser PostgreQSL, comme le souligne SQLPro.

Même PG ne peut supporter de grosses volumétries. En pratique dépasser la centaines de Go est déjà risqué (du fait de sa conception interne… VACUUM bloquant) et avoir des requêtes complexes (plus de 12 table) devient problématique à cause de GEQO...

Pour les plus grosses bases de données (en restant sur du SQL donc sans parler du noSQL), je pense qu'Oracle reste le leader, à moins que ce soit db2 avec les mainframes.

Oracle n'est plus le leader dans le domaine des grosses bases depuis quelques années déjà. C'est maintenant MS SQL Server. Lisez les études à ce sujet :
https://blog.developpez.com/sqlpro/p...onnees-en-2016
https://blog.developpez.com/sqlpro/p...-la-difference
https://www.gartner.com/reviews/market/operational-dbms
https://menafn.com/1097721013/Enterp...recast-to-2023

A +

[SQLpro]

As-tu regardé du coté de Percona Xtrabackup ?

Normalement ça ne lock pas la base, et tu peux même faire de l'incrémentiel. Je pense que ça pourrait être une solution pour avoir des sauvegardes avec un temps acceptable.

C'est faux !
https://www.reddit.com/r/sysadmin/co...blocks_all_my/
https://codeascraft.com/2012/08/07/n...th-xtrabackup/

La structure interne de MySQL du fait de l'absence de catalogue impose de bloquer tout pour pouvoir faire une sauvegarde consistante !

Il n'y a hélas pas d'autre solution….

A +

[chrtophe]

Je serais curieux d'avoir des références précises.

L'intérêt d'utiliser des outils ouverts a également poussé quelques établissements bancaires tels que le Crédit mutuel, le Crédit agricole, le Crédit lyonnais, la Banque de développement du Canada à inscrire MySQL au catalogue de leurs produits informatiques internes.

source Wikipedia.
Une recherche Google avec en mot clé le nom de la banque et mysql retourne des offres d'emplois confortant ce que dit Wikipedia.

Pour Xtrabackup :

Percona XtraBackup works with MySQL, MariaDB, and Percona Server. It supports completely non-blocking backups of InnoDB,

https://www.percona.com/doc/percona-...2.4/intro.html

Pour le cas cité par Reddit, c'est vrai car l'utilisateur utilise des tables MyISAM. Le moteur MyISAM est complètement dépassé, il ne supporte ni les transactions ni les clés étrangères.

[SQLpro]

Le MySQL CE est peut-être mauvais, mais ses forks sont viables pour le stockage de données sensibles ou médicales.

Dites moi comment vous tracez les accès finement à la base avec les adresses IP, le nom système de l'utilisateur, le nom de l'application la requête lancée (y compris en SELECT et en DDL)… afin de garantir les exigences de la RGPD ! Et comme le chiffrement est une passoire dans MySQL je ne voit pas comment garantir la confidentialité des données. Par exemple dans le cas de données de santé on a de plus en plus recours à des HMS pour le chiffrement ce que MySQL ne sait aucunement faire…
https://fr.wikipedia.org/wiki/Hardware_Security_Module

Par ailleurs sur la volumétrie, je dirais que une base Aurora MySQL peut tenir selon sa structure autour de 800Go à 1To de données (selon Amazon AWS, théoriquement 64 To de données...), certe pas d'un forum XXL sur-utilisé, mais pour de l'archivage de données utilisé en lecture seule la majorité du temps ça va.

Si c'est pour faire de la lecture de données, aucun intérêt d'avoir une BD relationnelle. Le relationnel est spécifiquement conçu pour effectuer des transactions en garantissant la consistance ! Autant avoir de bon vieux fichiers ISAM et du COBOL, ça ira encore plus vite !

Par ailleurs en ce qui est des backups pour ceux qui demandait avant, Aurora MySQL chez AWS fait un Snapshot d'une base de 900Go en moins de 20 secondes sans interruption (par contre recharger le Snapshot vers une nouvelle base de données prendra bien entre 1h30 et 2h30...)

En matière de snapshot il n'y a pas de miracle…
1) il faut "freezer" les fichiers de la base pour assurer l'intégrité transactionnelle. En effet, les échanges entre le journal de transaction et les fichiers de données doivent avoir le même point de synchronisation (sinon, il est impossible de garantir l'intégrité des données…). Donc il faut bloquer tout accès en écriture à ces fichier à un moment opportun. On en revient donc au blocage…. !
2) il y a eut forcément en amont une première initialisation qui à pris du temps puisqu'un snapshot ne récupérer que le delta… Sur une base fortement sollicité au niveau transactionnel cela prendra beaucoup de temps….

A +

[DarkCenobyte]

Dites moi comment vous tracez les accès finement à la base avec les adresses IP, le nom système de l'utilisateur, le nom de l'application la requête lancée (y compris en SELECT et en DDL)… afin de garantir les exigences de la RGPD ! Et comme le chiffrement est une passoire dans MySQL je ne voit pas comment garantir la confidentialité des données. Par exemple dans le cas de données de santé on a de plus en plus recours à des HMS pour le chiffrement ce que MySQL ne sait aucunement faire…
https://fr.wikipedia.org/wiki/Hardware_Security_ModuleSi c'est pour faire de la lecture de données, aucun intérêt d'avoir une BD relationnelle. Le relationnel est spécifiquement conçu pour effectuer des transactions en garantissant la consistance ! Autant avoir de bon vieux fichiers ISAM et du COBOL, ça ira encore plus vite !

En matière de snapshot il n'y a pas de miracle…
1) il faut "freezer" les fichiers de la base pour assurer l'intégrité transactionnelle. En effet, les échanges entre le journal de transaction et les fichiers de données doivent avoir le même point de synchronisation (sinon, il est impossible de garantir l'intégrité des données…). Donc il faut bloquer tout accès en écriture à ces fichier à un moment opportun. On en revient donc au blocage…. !
2) il y a eut forcément en amont une première initialisation qui à pris du temps puisqu'un snapshot ne récupérer que le delta… Sur une base fortement sollicité au niveau transactionnel cela prendra beaucoup de temps….

A +

Pour le tracing, il est possible de se connecter à travers le service IAM de AWS au lieu du système classique de connexion, ce qui permet de tracer qui appel et d'où a l'aide du service CloudTrail.

Ça te donne tout.
https://docs.aws.amazon.com/fr_fr/Am...IAMDBAuth.html

https://aws.amazon.com/blogs/databas...on-cloudwatch/

https://aws.amazon.com/blogs/databas...on-quicksight/

Le fork Aurora propose un chiffrement AES-256 avec gestion des clés par AWS et le service KMS: https://docs.aws.amazon.com/AmazonRD...ncryption.html

Si tu fais un read-replica à Aurora, il y a une exploitation du binlog différents des autre read-replica, qui permet une réplication inférieur à 100ms en asynchrone.

Le Snapshot peut être effectué sur un read-replica, car asynchrone il mettra juste un peu plus de temps à se resynchroniser peut-être. (La réplication est invisible pour MySQL et entièrement géré par Amazon, MySQL n'a pas conscience d'avoir des master ou slaves dans ce mode).

Enfin, le terme Snapshot est à prendre avec des pincettes chez AWS. Car chaque Snapshot fait la taille la plus élevé de la base de donnée (jamais shrink), et peut recréer de nouveau cluster uniquement, pas restaurer un état à un cluster précédent. Je pense qu'il s'agit pour eux de Snapshot à l'état même de leur système de fichier... Ou du binlog...

https://aws.amazon.com/fr/rds/aurora...nd_Replication
https://docs.aws.amazon.com/AmazonRD...liability.html

[SQLpro]

Pour le tracing, il est possible de se connecter à travers le service IAM de AWS au lieu du système classique de connexion, ce qui permet de tracer qui appel et d'où a l'aide du service CloudTrail.

On parle de libre et gratuit installé dans l'entreprise… Il faudrait donc payer le cloud AWS pour avoir ce genre de service… Finalement le libre coute très cher ! ;-)

A +

[SQLpro]

source Wikipedia.
Une recherche Google avec en mot clé le nom de la banque et mysql retourne des offres d'emplois confortant ce que dit Wikipedia.

dans une offre d'emploi on y met beaucoup de chose pour tenter d'avoir quelqu'un qui approche le profil souhaité. Mais cite moi une seule installation de MySQL gérant des comptes client dans une banque et on en reparlera….

Pour Xtrabackup :

https://www.percona.com/doc/percona-...2.4/intro.html

Pour le cas cité par Reddit, c'est vrai car l'utilisateur utilise des tables MyISAM. Le moteur MyISAM est complètement dépassé, il ne supporte ni les transactions ni les clés étrangères.

Le seul moyen d'approcher une sauvegarde non bloquante est d'avoir un réplica… Autrement dit pour une simple sauvegarde je suis obligé de monter une usine à gaz ! Finalement le libre ça coute cher !

Donc, je maintient et j'affirme que MySQL ne sait pas faire des sauvegardes consistante sans blocage...

A +

[sebbod]

Je confirme que en mode InnoDB les contraintes fonctionnent
l'exemple [Client] 1 <---> n [facture] produirait une erreur

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE TABLE test.T_CLI 
(CLI_ID INT PRIMARY KEY);
 
CREATE TABLE toto.T_FAC 
(FAC_ID INT PRIMARY KEY, 
 CLI_ID INT REFERENCES test.T_CLI (CLI_ID));

Insérons une ligne dans la table des factures : INSERT INTO toto.T_FAC VALUES (1, 1); => ça génère une erreur en "InnoDB" si CLI_ID = 1 n'existe pas dans la table T_CLI (mais pas en "MyISAM")

[chrtophe]

cite moi une seule installation de MySQL gérant des comptes client dans une banque et on en reparlera….

Je ne peux pas car je travaille pas dans le milieu bancaire, mais si celui-ci cherche des dba MySQL, c'est bien pour quelque chose. Peut-être pour des petites applis à part.

Moi je vois que des petites bases das des applis métier sous SQL Server Express qui est gratuit ou SQL Server standard. MySQL je le vois que sur les sites Web ou les CMS/ERP en mode Web bien que certains donnent le choix entre Mysql est PostGreSQL, voire l'impose pour certains (mais c'est rare). J'ai du voir une seule fois un produit avec client lourd sous Windows utilisant MySQL. JE sais pas à partir de quel volume une base est considérée comme grosse, mois ce que je vois ne dépasse jamais 20 Go je pense.

Quant à mon entourage travaillant dans des grands comptes, c'est plutôt de l'AS400, et quand c'est migré c'est vers SAP. Mais pour rester objectif, je pense que c'est surtout lié à leur ERP qu'au système de base de donnée derrière.

[oxomichael]

Franchement, on est dans un environnement pro donc les choix ne dépendent que de l'environnement

Dans une précédente entreprise
BDD de 2To MySQL puis passage à MariaDB, pas de problème de perf
Avec tout plein de fonctionnalitées, Indexation FullText, etc

Aujourd'hui du Perconna pour 500 BDDs isolées pour des clients pour une application SaaS

Pour tout les problèmes énoncés, on dirait un point de vue trop DBA et pas applicatif
Qu'est ce qui tourne derrière, qu'est ce que l'application fait, quel est le niveau de sécurité (Réseau, Certification, .... ) ?

[DarkCenobyte]

Je ne peux pas car je travaille pas dans le milieu bancaire, mais si celui-ci cherche des dba MySQL, c'est bien pour quelque chose. Peut-être pour des petites applis à part.

Moi je vois que des petites bases das des applis métier sous SQL Server Express qui est gratuit ou SQL Server standard. MySQL je le vois que sur les sites Web ou les CMS/ERP en mode Web bien que certains donnent le choix entre Mysql est PostGreSQL, voire l'impose pour certains (mais c'est rare). J'ai du voir une seule fois un produit avec client lourd sous Windows utilisant MySQL. JE sais pas à partir de quel volume une base est considérée comme grosse, mois ce que je vois ne dépasse jamais 20 Go je pense.

Quant à mon entourage travaillant dans des grands comptes, c'est plutôt de l'AS400, et quand c'est migré c'est vers SAP. Mais pour rester objectif, je pense que c'est surtout lié à leur ERP qu'au système de base de donnée derrière.

Comme le dit Oxomichele, ca dépend de l'usage... Une base de donnée MySQL va pas exploser avec 1To à l'intérieur... Sauf si tout est dans la même table a la limite.
Il y a des pièges à éviter (pas de TEXT ni de BLOB dans une grosse table ni de JSON, sur le papier utiliser les colonnes auto-généré pour mettre des index sur du JSON, car en tout cas en 5.7 c'est faire un gouffre à performance... Ça doit aller mieux en 8.0 ..., des index bien pensé car sinon ils flinguent l'écriture si trop nombreux, savoir que la primary Key se met comme une dernière colonne à la fin de toutes les autres clefs qui du coup sont comme des clefs multiples). Savoir que dans une requête une seule clef est utilisé par table jointes donc autant bien faire des clefs multiples.
Se méfier des procédures stockés qui en vrai sont des flingueuses de performances (à une certaine volumétrie, tout faire à la suite dans le client est plus rapide que de CALL une procédure stocké).

En final tout dépend des cas d'usage... On peut cracher sur le Cloud mais Amazon arrive à faire des choses impressionnantes en partant de MySQL (et à stocker plus qu'avec Postgresql dans le cas Aurora).

Mais avec des staging table on peut faire pas mal de chose jusqu'à 1 To au moins.

Je ne dit pas qu'il n'y a pas mieux autour, mais MySQL sait gérer beaucoup de chose, et il suffit de parler avec un DBA Percona pour comprendre que ça se joue à plein de niveau, jusque sur la compression de certaines tables ou non. Du barracuda vs antilope...

MySQL n'est pas à jeter et s'en sort encore pour amorcer une base de données, voir pour toute la durée de vie de la base selon les cas, y compris en mode pro même si cela peut nécessiter des replica ou des master-master pour gonfler les perfs.

[Nb]

L'un de mes clients, piégé par MySQL, ne sauvegarde même plus sa base pour ces raisons là. Il est vrai qu'elle est trop grosse pour du MySQL (plus de 300 Go), que la sauvegarde dure des heures et que, comme le système est en permanence sollicité par un minimum d'une centaines d'utilisateurs la sauvegarde est devenue impossible !

A +

Moi je connais un forgeron qui a été piégé par un fabriquant de maillet en bois....

Encore une fois l'article est interressant car il peut permettre de se poser des questions sur ce qui existe en matiere de SGBD mais le coté orienté couplé à des arguments fallacieux décrébilise le propos.

[webMCA]

Bonjour,
cet article est très interessant et permet d'attirer l'attention sur des negligences des utilisateurs, ainsi que sur des faiblesses de Mysql
Cependant, il me semble que sqlpro fait preuve d'un peu de mauvaise foi ou de beaucoup d'incompétence concernant MySql. Il aurait pu demander l'avis d'un expert MySql, ou montrer une certaine neutralité.

Sur la partie de l'article qui prétend qu'une instruction de ddl valide toute transaction, je n'ai pas compris pourquoi dans l'exemple aucun niveau d'isolation de transaction n'est précisé. Or, la gestion des transactions dépend du niveau d'isolation, et Mysql par défaut est au niveau read uncommitted. J'ai testé son exemple avec le niveau repeatable read et je n'ai pas eu de commit automatique avec une instruction de ddl, sur les autres transactions (j'utilise mysql8).
Pour moi, cela semble relever d'un peu de mauvaise Foi pour un expert en bases de données de parler de transactions sans mentionner l'impact des niveaux d'isolation, et de tester les transactions sans les définir.

Condamner le strict mode de Mysql relève simplement d'un manque de recul. Comment assurer la compatibilité ascendante avec les programmes si à un moment tout était permis et que plus tard on améliore en permettant que certaines choses deviennent interdites? La solution la plus simple est l'introduction d'un strict mode, pour ne pas faire planter les systèmes en production qui ne l'avaient pas respecté, et qui se limitaient à prendre les parties justes de la requête (autrement les utilisateurs se seraient plaints de bugs et il y aurait eu des corrections). Par contre, il est effectivement important d'attirer l'attention des developpeurs mysql sur la nécessité de définir ce mode de fonctionnement pour leur SGBD

avec mysql8, la collation par défaut est utf8mb4 et non latin1.
D'autres ont déja répondu sur d'autres points, sur lesquels je ne reviens pas.
Il aurait été souhaitable pour un tel article de préciser quelle version de MySql a été utilisée.

J'avoue que j'aimerai bien entendre la réponse de SQLPro par rapport à ce commentaire... il répond aux commentaires mais aux commentaires "choisis"... ce qui renforce encore plus l'évidence d'une possible mauvaise foi...

[webMCA]

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 ?

SQLPro, des excuses, peut-être, concernant cette erreur dans votre article concernant l'origine du nom "mySQL" ?
A tout le moins un "ERRATA" ?

[escartefigue]

Je ne peux pas car je travaille pas dans le milieu bancaire, mais si celui-ci cherche des dba MySQL, c'est bien pour quelque chose. Peut-être pour des petites applis à part.

Les banques chez lesquelles je suis intervenu (Crédit Agricole, BNP, Caisse d'épargne et Banques populaires) ont pour point commun le S.I. métier sur DB2 for Z/OS (infra mainframe IBM).
C'est souvent le cas chez les grands comptes et pas seulement dans le milieu bancaire (ex : assurance, retraite, industrie automobile).
Les S.I. distribués concernent les applications annexes telles que la relation client et le décisionnel, on y trouve les SGBD Oracle, MySQL et SQL server

Il en allait de même pour Atos Worldline au début des années 2000, je ne sais pas si c'est toujours le cas.

[FatAgnus]

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.

[webMCA]

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).

[François DORIN]

Pour ma part, je t'ai moinssé. Non pas qu'il n'y ait pas d'argument (de ce point de vue, ta réponse est plutôt complète), mais parce que je trouve que cela n'apporte strictement rien au débat.

SQLPro a donné de nombreux exemples expliquant pourquoi il considère que MySQL ne devrait pas être qualifié de SGBD relationnel. Ces arguments sont factuels, et non pas été démontés par les intervenants. Certains ont essayé (par exemple, sur la sauvegarde à chaud) mais, à mes yeux, non pas vraiment réussi.

Non, je t'ai moinssé, car tes arguments ne sont pas sur le message de fond, mais sur le messager lui-même. Et ce qui est rigolo, c'est que tu fais exactement la même chose en parlant de feedback.azure.com que SQLPro de MySQL : se baser sur le nom pour déterminer les intentions. Chapeau !

On peut tergiverser longuement sur l'origine du nom (est-ce que cela vient de sa fille ou pas), mais cela ne changera pas les problèmes de fond, à savoir les dettes techniques (le coup de la date sous MySQL m'a tué !).

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.

Il me semble pourtant que l'auteur a fait un long paragraphe sur les benchmark, qui, si on le lit, explique pourquoi le benchmark est "vieux". Si maintenant tu as des benchmark montrant la vitesse des versions actuelles, pourquoi ne pas les avoir déjà cité afin justement de contredire l'auteur ? Cela aurait beaucoup plus d'impact que des attaques presques gratuites.

Références sur des sanctions sans rapports avec MySQL

Rapport indirect, dont j'ai déjà parlé dans un commentaire dans ce fil de discussion.

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 : MYSQL, MySQL comporte 73 738 bugs (d'où l'auteur tient-t-il ce chiffre ?) donc c'est un outil de bidouilleurs.

Au hasard, de la.

L'auteur oublie que tous les projets open source, de fait de leurs natures open source, ont une toujours de grandes listes de bugs.

Faites attention à vos écrits ! Sans vous en rendre compte, vous soutenez le propos que vous essayer de combattre !
La nature du projet (open source ou non), n'a rien à voir avec les bugs. C'est la qualité des développements derrière.

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.

Un bug n'est pas forcément une faille de sécu, mais une faille de sécu est (très souvent) un bug (ou une erreur de conception). Donc plus il y a de bugs, plus il y a de risque de faille de sécurité. Il n'y a qu'à voir le plugin Flash d'Adobe !

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.

L'auteur choisirai les chiffres qui l'arrangent ? Ce n'est pas juste alors... ou alors... serait-ce que les chiffres CVE s'arrêtent en 2016 pour MySQL ?

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 ?

CVE n'est pas un recueil exhaustif des failles.

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.

Et ? Ca apporte quoi au schmilblick la différence de philosophie qu'il peut y avoir entre open source et libre ? Est-ce que cela va changer quoi que ce soit sur le fait que MySQL peut stocker une date invalide sans broncher ? Non. Vous essayez de jeter du discrédit sur l'auteur pour le désavouer.

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.

Je ne parle pas au nom de l'auteur (Frédéric, je te laisse t'exprimer sur ce point), mais est-il autant inconcevable pour un libriste d'accepter qu'une solution propriétaire soit meilleure qu'une solution libre ? Est-il inconcevable que des personnes payées à plein temps arrivent à faire un meilleur travail depuis des années qu'une communauté de libriste ? Surtout sur des sujets de haute technicité comme les bases de données ?

Oui, l'auteur à fait un article à charge sur MySQL. Mais la réalité, c'est que les fait qu'il a énoncé n'ont pas réussi à être contré. Alors n'arrivant pas à le faire, on s'attaque au messager en lui prêtant les plus mauvaises intentions du monde. Ahhhh triste monde...

[DarkCenobyte]

Pour information, l'erreur de la date ne se produit pas sur mon 5.7 Aurora. La date est stocké invalide sans être transformé en l'autre date. Du coup l'opération de date provoque bien le résultat de l'erreur mais on ne peut pas confondre les deux entrées au départ sur mon MySQL.