Discussion :

[Christophe]

Effectivement, avec la version 8, j'ai une erreur. Certaines choses ont semble-t-il été corrigées.

Est-ce que cela change ma position sur MySQL/MariaDB ? Pas vraiment.

Mais cela montre que MySQL tend vers la norme, ce qui est positif. Et mon but n'était pas de te faire changer de position.

Le tutoriel présente des défauts de MySQL, j'aimerais connaitre aussi ceux de SQL-Server.

[Willy_k]

En même temps si l'auteur consultait la documentation il s'en serait rendu compte (ils l'ont dit explicitement ). MYSQL a fait de même avec CHECK avant la version 8 qui ne faisait rien mais ne renvoyait pas d'erreur de syntaxe.

Ce n'est pas une nouveauté sur le fait que MYSQL et MariaDB ne suivent(suivaient) pas totalement la norme (MariaDB semble avoir pris de l'avance)
L'erreur survient chez moi dans une version de MYSQL < 8

[François DORIN]

Mais cela montre que MySQL tend vers la norme, ce qui est positif.

J'avoue que je suis sceptique. Disons que je ne comprends pas le coup de la syntaxe supportée mais qui ne fait rien. La gestion des clés étrangères existe. Elle est supporté via une syntaxe précise. Il existe une autre syntaxe, qui est parsée, pour éviter les erreurs, mais sans effet. Quel est le coût de faire le lien entre la syntaxe et la fonctionnalité ?

Que la syntaxe ne fasse rien si les clés étrangères n'étaient pas supportées serait éventuellement compréhensible, mais que cela soit purement et simplement ignoré... quelque chose m'échappe.

Le tutoriel présente des défauts de MySQL, j'aimerais connaitre aussi ceux de SQL-Server.

Le prix ?

J'aurais bien dit aussi qu'il est limité à Windows, mais ce n'est plus vrai depuis plusieurs mois maintenant.

Pour ma part, les rares défauts que j'ai pu y voir son vraiment mineur, et on été corrigé dans les versions récentes (comme quoi, faire des rapports de bug, ça sert !). Les défauts que j'avais repéré c'était la fonction de déchiffrement DECRYPTBYPASSPHRASE qui n'était pas marqué comme déterministe (alors qu'en théorie elle l'est) et une incompatibilité lors de la définition d'un INDEX sur une colonne calculée lors de la création d'une table (avec contournement possible : il suffisait de créer la table d'abord, puis de créer l'index).

Je l'utilise depuis de nombreuses années maintenant, et je n'ai jamais réussi à le mettre en défaut.

En même temps si l'auteur consultait la documentation il s'en serait rendu compte

En même temps, sans message d'erreur ou d'avertissement, difficile de savoir que quelque chose ne va pas. La fonctionnalité est standard depuis plus de 20 ans. Elle n'est toujours pas pleinement supportée par un SGBD qui se prétend relationnel. Que l'auteur ait lu au pas la documentation ne change rien à cet état de fait.

L'avantage d'avoir une norme, c'est d'éviter aussi de consulter la documentation pour la moindre opération. Avec votre approche, il faut lire la doc pour faire un SELECT, un INSERT, un CREATE TABLE, etc... alors que toutes ces opérations sont standardisées. Lire la documentation pour connaitre les apports non standard n'a rien de choquant. Lire la documentation pour des opérations qui sont au coeur de la norme, c'est différent.

De plus, il faut que la documentation existe et soit à jour. Par exemple, il y a bien une page pour MySQL sur les différences au niveau des clé étrangères vis-à-vis du standard, mais il n'y a nullement question de la syntaxe.

La page sur la création d'une table mentionne les 2 syntaxes, mais ne précise nulle part que l'une d'elle est ignorée. Seule la documentation de MariaDB le précise.

Donc dire "l'auteur n'avait qu'à lire la doc" c'est une chose, encore faut-il que la doc soit complète !

[Willy_k]

On ne va pas supposer que parce que telle syntaxe fonctionne avec SQL Server que ça fonctionne obligatoirement avec MYSQL, l'auteur sait me semble t-il que côté norme MYSQL et MariaDB ne sont pas les plus à même donc il faut faire avec ce qu'elles disposent.
J'ai lu la doc https://dev.mysql.com/doc/refman/8.0...eign-keys.html , et bingo

Furthermore, MySQL parses but ignores “inline REFERENCES specifications” (as defined in the SQL standard) where the references are defined as part of the column specification.

[François DORIN]

On ne va pas supposer que parce que telle syntaxe fonctionne avec SQL Server que ça fonctionne obligatoirement avec MYSQL,

Mais... ca n'a rien à voir avec SQL Server, mais avec le standard SQL ! Un standard de plus de 20 ans !!!! Et la véritable problématique, c'est que ça ne fonctionne pas, mais le fait en silence, sans message, que ce soit d'erreur ou d'avertissement.

J'ai lu la doc https://dev.mysql.com/doc/refman/8.0...eign-keys.html , et bingo

Et bien, je l'ai loupé
En même temps, louper un paragraphe de 2 lignes sur une doc de 34 pages, c'est vite arrivé

[Willy_k]

Mais... ca n'a rien à voir avec SQL Server, mais avec le standard SQL ! Un standard de plus de 20 ans !!!!

J'ai lu certaines interventions de l'auteur qui n'hésite à rappeler cette affaire de norme à propos de MYSQL (Je l'ai dit dans mon message précédent) . Enfin il tire la plupart du temps sur tout ce qui est différent de SQL Server.

... Et la véritable problématique, c'est que ça ne fonctionne pas, mais le fait en silence, sans message, que ce soit d'erreur ou d'avertissement.

C'est un comportement documenté (mais d'après vous on s'en fout un peu), Perso je ne peux pas passer à SQL SERVER par exemple sans me documenter au minimum.

[François DORIN]

J'ai lu certaines interventions de l'auteur qui n'hésite à rappeler cette affaire de norme à propos de MYSQL (Je l'ai dit dans mon message précédent) . Enfin il tire la plupart du temps sur tout ce qui est différent de SQL Server.

Il cite souvent SQL Server car SQL Server est très respectueux du standard et est un des meilleurs SGBD du marché (ne vous en déplaise).

C'est un comportement documenté (mais d'après vous on s'en fout un peu), Perso je ne peux pas passer à SQL SERVER par exemple sans me documenter au minimum.

C'est bien de me faire dire ce que je n'ai pas dit. On ne se fout pas de la doc. C'est juste que quand il y a une norme, on la respecte. Sinon, écrire un standard ne sert à rien. Et on ne parle pas d'une fonctionnalité marginale, on parle d'une fonctionnalité au coeur d'un SGBD !
C'est comme si demain, j'écrivais un compilateur C qui accepte l'initialisation d'une variable à sa déclaration mais uniquement du point de vue syntaxique, sans procéder à l'initialisation (mais que l'affectation seule fonctionne très bien). Je vais répondre aux gens qui doivent revoir leur code que c'est documenté et qu'ils n'ont qu'à lire la doc ?

Désolé, mais c'est une position insoutenable.

[Willy_k]

C'est vous qui voyez, ce qui est sûr on ne sera pas d'accord sur ce point.

Il a voulu montrer une limitation de MYSQL et MariaDB sur la gestion des clés étrangères en utilisant une syntaxe non supportée (dans le sens que ça ne fait rien) et miracle ça ne fonctionne pas , qui aurait cru donc danger.
Un membre a parlé des dates avec des 00-00 , s'il avait consulté la doc, il aurait vu qu'il est possible de ne pas accepter ce genre de date, idem pour GROUP BY.

Je ne suis pas "anti-standard" loin de là, y'a des fonctionnalités que j'aimerais avoir dans MariaDB (ça fera moins de casse-tête côté application), mais quand je veux manipuler MariaDB j'ai la doc pas loin et je fais avec.

[François DORIN]

C'est vous qui voyez, ce qui est sûr on ne sera pas d'accord sur ce point.

Je crois qu'on peut effectivement être d'accord au moins sur ce point

a voulu montrer une limitation de MYSQL et MariaDB sur la gestion des clés étrangères en utilisant une syntaxe non supportée (dans le sens que ça ne fait rien) et miracle ça ne fonctionne pas , qui aurait cru donc danger.
Un membre a parlé des dates avec des 00-00 , s'il avait consulté la doc, il aurait vu qu'il est possible de ne pas accepter ce genre de date, idem pour GROUP BY.

J'avais commencé à écrire un gros pavé, puis je l'ai sélectionné et supprimé. La discussion, bien qu'intéressante au départ, devient stérile. Nous n'avons clairement pas les mêmes attentes. J'ai fait un choix, vous avez fait le votre. Un outil, quel qu'il soit, doit être là pour aider et dire quand quelque chose ne va pas. Ce que ne font pas MySQL/MariaDB.

Merci pour cette discussion

[Willy_k]

Exactement, mais un peu de bonne foi de la part de l'auteur n'aurait fait aucun mal. Vous avez pris dès le départ l'article comme "parole d'évangile" .
Je ne suis pas là pour vous faire aimer MariaDB et MySQL.
Merci à vous aussi.

[FatAgnus]

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.

Une réponse aussi longue de ta part pour mon commentaire qui n'apporte rien au débat, je suis plutôt flatté.

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.

Frédéric Brouard avance un peu tout et n'importe quoi comme je l'ai montré dans mon précédent commentaire. N'ayant aucune compétence sérieuse de SQL, comme l'auteur, je ne conteste pas ces exemples (que je ne peux et veux pas vérifier) qui sont certainement véridiques (ou pas) pour la plupart. Ayant relevé plusieurs erreurs volontaires de la part de l'auteur, dans le seul but d'enfoncer MySQL, je me demande juste si ces exemples ne sont pas un peu biaisés ou présentés de façon alarmistes. Dans tous les cas il faudrait l'expertise d'une personne impartiale, tout ce que n'est pas l'auteur. Même si MySQL n'est pas parfait et ne respecte pas totalement les treize règles du CODD cela reste un SGBD relationnel. MySQL n'est-il conforme à aucune norme SQL-86, SQL-89, SQL-99, ... ? Est-ce que Internet Explorer 8 n'est pas un navigateur web pour la simple raison qu'il n’implémente pas complètement les standards ?

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 !

Faux, je me base aussi sur la page d'accueil qui affiche « Avez-vous un commentaire ou une suggestion pour améliorer SQL Server ? Nous serions ravis de l'entendre ! ». L'utilisateur doit entrer la catégorie (bugs, other, setup + deployment, suggestions), son idée et son adresse électronique. C'est l'outil de suivit des bugs des développeurs de SQL Server ? Un peu de sérieux s'il te plaît. Comment peut-ton comparer un site qui recueille les avis des utilisateurs depuis trois ans à une base de bugs dédiés aux développeurs ouverte il y a dix-sept ans ? Incompétence de l'auteur ou tentative de manipulation ?

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

Pourquoi tergiverser ? C'est un fait connu, MySQL et MariDB, utilisent les prénoms des deux filles du cocréateur Michael Widenius. Cela prouve juste que l'auteur ne vérifie pas ses sources et se permet une explication basée sur ses préjugés et en profite pour dénigrer MySQL, sans aucun fondement technique. Comment croire les autres points soulevés par l'auteur alors que la première information qu'il énonce sur son article est fausse et vérifiable en cinq minutes par un enfant de dix ans ?

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 presque gratuites.

Encore faux, j'ai bien relu le paragraphe des benchmarks qui ne donne aucune information sur la date du benchmark de 2014, ni sur la version MySQL 5.6 sortie en 2013. Mes attaques ne sont pas gratuites, sauf si tu arrives à me prouver la pertinence d'un benchmark d'un produit sorti en 2013 en 2019 ? C'est un peu comme si je publiais aujourd'hui des benchmarks de Firefox 21.0 sorti en 2013. On me demanderait à juste titre pourquoi pas ne pas publier des benchmarks de Firefox 68 actuel ? Je ne possède pas de benchmarks de MySQL 8 face à SQL Server 2017 et je ne suis pas l'auteur de l'article. Si l'auteur n'a pas non plus de tels benchmarks, alors qu'il fasse honneur à son pseudo SQLPro et qu'il ne publie rien, au lieu de laisser supposer que le benchmark est récent tout en dénigrant MariaDB et MySQL au passage « les performances de MariaDB sont tellement pathétiques » et simple qu'un « simple comptage MariaDB/MySQL est huit fois plus lent que SQL Server ». Où est le le professionnalise de Frédéric Brouard ? Uniquement dans son pseudo ? Pourtant l'auteur sait faire des benchmarks comme le prouve son article Microsoft SQL Server 2017 plus rapide sous Linux que Windows ? Pas si sûr…. La preuve que l'auteur peut écrire de bons articles quand il n'est pas aveuglé par sa rage contre MySQL.

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

Le rapport sur les condamnation de sociétés ne respectant pas le RGPD ou pour ne pas avoir respecté les données des utilisateurs sont valables quelques soit les technologies utilisées, même SQL Server, si les développeurs font mal leur travail. Je reste persuadé que l'auteur a publié ces nombreux exemples juste pour attiser la peur de MySQL en poctuant de petites phrases comme « Était-ce du MySQL ? », pour essayer de convaincre le lecteur que la société a eu une pénalité à cause de MySQL.

Au hasard, de la.

Effectivement, dans le lien https://bugs.mysql.com/bugstats.php, je vois un total de 74 038 bugs (en dix-sept ans), dont 33 460 fermés et 118 ouverts, 5 556 vérifiés, 8 500 dupliqués, plus un certain nombre de bugs dans un autre état. Donc ce ne sont pas 74 038 bugs non résolus comme on aurait pu le penser (l'auteur ne dit rien sur l'état des bugs, laissant planer le doute). En plus ces bugs ne concernent pas que MySQL, mais aussi des logiciels tournant autour de MySQL comme MySQL Workbench ou encore des bugs dans la documentation (une erreur d'orthographe dans la documentation est vu comme un bug). Encore une fois le nombre des bugs n'a rien à voir avec la nature des bugs. Donc balancer le nombre de 74 038 bugs, oubliant de préciser que ce sont tous les bugs ouverts depuis 2002, que ces bugs ne concernent pas que MySQL, mais aussi la documentation, les problème de compilation et d'autres logiciels tiers comme MySQL Workbench et d'oublier que sur ces 74 038 bugs seuls 118 restent ouverts n'est plus ou moins qu'une tentative de FUD. Encore une fois, vu que nous n'avons pas accès la base de données des bugs de SQL Server aucune comparaison n'est possible.

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.

Tu confonds nombre de bugs et qualité d'un projet. À mon humble avis, un projet open source de par sa nature ouverte aura toujours plus de bugs, non pas que sa qualité soit inférieure ou meilleure qu'un logiciel propriétaire, mais juste le fait que la base de données de bugs soit publique rend possible à n'importe quel développeur ou utilisateur de reporter un bug. Donc forcément des projets très actifs comme MySQL ou MariaDB qu'on retrouve dans chaque distribution GNU/Linux et qui sont très utilisés vont générer plus de rapports de bugs.

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 !

Une faille de sécurité est toujours un bug, d'ailleurs Linus Torvalds considère les failles de sécurités comme de simples bugs, ni plus ni moins. Je ne suis pas certains que plus il y a de bugs plus il y a de risques de failles, un bug est rarement une faille de sécurité, cet argument reste à prouver. Vu qu'on ne connaît pas le nombre de bugs de SQL Server depuis sa première version de 1989, le débat est clos. L'auteur a juste ajouté ce paragraphe pour faire du bruit et dénigrer MySQL.

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 ?

L'auteur n'a pas fait son travail correctement, sinon il aurait trouvé que le nombre de CVE pour l'année 2019 de MySQL est bien supérieur à celui de SQL Server. MariaDB a l'air d'en avoir beaucoup moins de CVE que MySQM. SQL Server est plus sécurisé que MySQL si on s'en tient juste au nombre de CVE. Il faudrait aussi étudier le niveau de ces failles et le temps de correction. Ensuite MySQL est open source, possède deux forks actifs (MariaDB et Percona Server), MySQL ou MariaDB sont aussi présents dans toutes les distributions GNU/Linux, MySQL est installé sur des dizaines de millions de sites web et Intranet. Peut-être que ce nombre de CVE est aussi la rançon de son succès.

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 n'a pas besoin de moi pour se discréditer il y arrive bien tout seul. Au lieu de de se contenter à des faits techniques, l'auteur dénigre MySQL et arrose la communauté libre au passage : « cela donne froid dans le dos pour certains SGBD du monde libre» , « technologie est hors de portée du monde libre », « comme c’est du soi-disant libre ». MySQL est un produit profondément open source, diffusé sous GPL (qui est une licence pourtant écrite par la FSF) afin que seul Oracle puisse diffuser des versions commerciales de MySQL (un contributeur doit accorder son droit d'auteur à Oracle en signant l'Oracle Contributor Agreement).

mais est-il autant inconcevable pour un libriste d'accepter qu'une solution propriétaire soit meilleure qu'une solution libre ?

À quel moment j'ai ai-je prétendu que MySQL était supérieur à SQL Server ? Jusqu'à la lecture de cet article je pensais que SQL Server était meilleur que MySQL, et je connais personne dans mon entourage qui prétendra le contraire. Mais vu l'effort que fait l'auteur pour descendre MySQL, je me pose des questions.

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 ?

Est-il inconcevable que toi et l'auteur puissiez imaginer que les développeurs de MySQL sont des développeurs payés à plein temps par Oracle ? Est-il inconcevable de penser qu'en 2019 des sociétés comme Red Hat, Microsoft, IBM, Intel paient des ingénieurs à plein temps pour développer des logiciels open source de haute technicité comme le noyau Linux, le navigateur web Chromimum, le compilateur Clang ? Est-il inconcevable en 2019 de penser que la qualité d'un logiciel ne dépend pas de sa licence ?

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

J'ai démontré que certains faits étaient faux ou baisés. De plus les démonstrations de l'article n'indiquent pas la version de MySQL, ni le nom est la version du système d'exploitation utilisé, ni quel moteur de stockage ont été utilisés, c'est donc difficile de reproduire ces démonstrations de l'auteur dans les mêmes conditions. Ce n'est pas très sérieux pour un professionnel. Ces faits sont peut-être en partie exacts, certainement dramatisés ou n'ont pas réussi à être contré totalement ou partiellement, car il n'y a peut-être aucun expert MySQL qui lira cet article ou qui veut perdre son temps à répondre à ce FUD. Je peux bien attaquer un peu l'auteur puisque l'auteur s'attaque bien la communauté du libre en prétendant qu'ils ne sont pas compétant (des technologies qui seraient hors de portée du monde libre) alors que MySQL est un projet open source développé principalement par des salariés d'Oracle depuis dix ans.

[Christophe]

Par rapport à l'opération 3/2. Poser le dans une calculatrice n'importe laquelle ou dans un tableur qu'est ce que vous avez?

C'est pas toujours le cas en informatique. et en programmation, si tu fais cela en C, avec deux entiers tu obtiendras 1, sauf si tu castes les opérandes en flottant. Et pire si tu fait un printf("%f\n",3/2) tu obtiendras 0.000000.

Ne serait-ce qu'en mathématiques, si tu restes dans l'ensemble des entiers naturels, comment se traite 3/2 ?

D’où l'importance de normes. Mais j’ai l'impression que les normes SQL ne sont pas facilement accessible. Mais rien n'empêche de prendre de bons bouquins.

Après dans une base, tu as un type de champs spécifique pour les int et un autre pour les floats. Si je mets une expression de type 3/2 directement dans une requête, soit je sais à quoi m'attendre car je connais le comportement du SGBD, soit je teste.

Frédéric Brouard avance un peu tout et n'importe quoi comme je l'ai montré dans mon précédent commentaire. N'ayant aucune compétence sérieuse de SQL, comme l'auteur,

Faux, l'auteur a des compétences, il a écrit des livres sur le SQL justement.

Donc, même si je trouve l'article trop à charge envers MySQL j'ai appris des choses, j'ai vu des pièges de MySQL par rapport à SQL Server.

[François DORIN]

N'ayant aucune compétence sérieuse de SQL, comme l'auteur,

C'est fortement méconnaitre l'auteur. Il est extrêmement réputé et à même écrit des livres qui sont des références dans le domaine.

Faux, je me base aussi sur la page d'accueil qui affiche « Avez-vous un commentaire ou une suggestion pour améliorer SQL Server ? Nous serions ravis de l'entendre ! ». L'utilisateur doit entrer la catégorie (bugs, other, setup + deployment, suggestions), son idée et son adresse électronique. C'est l'outil de suivit des bugs des développeurs de SQL Server ? Un peu de sérieux s'il te plaît. Comment peut-ton comparer un site qui recueille les avis des utilisateurs depuis trois ans à une base de bugs dédiés aux développeurs ouverte il y a dix-sept ans ? Incompétence de l'auteur ou tentative de manipulation ?

Le site recueil les "feedback", les retours des utilisateurs, et les bugs en font parti. Le site est peut être ouvert depuis 3 ans, mais l'ensemble des "tickets" ont été migré sur cette plateforme. Exemple avec ce ticket de 2006, pris au hasard dans les archives.

Encore faux, j'ai bien relu le paragraphe des benchmarks qui ne donne aucune information sur la date du benchmark de 2014, ni sur la version MySQL 5.6 sortie en 2013. Mes attaques ne sont pas gratuites, sauf si tu arrives à me prouver la pertinence d'un benchmark d'un produit sorti en 2013 en 2019 ?

Il a donner le lien du benchmark, où il y a toutes les informations demandées. Il explique pourquoi il n'y a pas de benchmark récent (car des benchmark reconnu comme TPC-E n'incluent pas MySQL). Et encore heureux qu'il n'a pas publié de benchmark réalisé par lui-même dans son article, vu le procès d'intention qui lui est fait !

Effectivement, dans le lien https://bugs.mysql.com/bugstats.php, je vois un total de 74 038 bugs (en dix-sept ans), dont 33 460 fermés et 118 ouverts, 5 556 vérifiés, 8 500 dupliqués, plus un certain nombre de bugs dans un autre état. Donc ce ne sont pas 74 038 bugs non résolus comme on aurait pu le penser (l'auteur ne dit rien sur l'état des bugs, laissant planer le doute). En plus ces bugs ne concernent pas que MySQL, mais aussi des logiciels tournant autour de MySQL comme MySQL Workbench ou encore des bugs dans la documentation (une erreur d'orthographe dans la documentation est vu comme un bug). Encore une fois le nombre des bugs n'a rien à voir avec la nature des bugs. Donc balancer le nombre de 74 038 bugs, oubliant de préciser que ce sont tous les bugs ouverts depuis 2002, que ces bugs ne concernent pas que MySQL, mais aussi la documentation, les problème de compilation et d'autres logiciels tiers comme MySQL Workbench et d'oublier que sur ces 74 038 bugs seuls 118 restent ouverts n'est plus ou moins qu'une tentative de FUD. Encore une fois, vu que nous n'avons pas accès la base de données des bugs de SQL Server aucune comparaison n'est possible.

Et n'est-ce pas ici une tentative de faire croire que tout est obsucre ? La liste des bugs de SQL Server est disponible. Tout comme pour MySQL, la liste des bugs ne concerne pas uniquement SQL Server, mais aussi des programmes autour, comme SQL Server Management Studio ("l'équivalent" de MySQL Workbench). Effectivement, il ne dit rien sur le statut des bugs. Mais il fait la même chose d'un côté comme de l'autre. Donc même traitement.

Tu confonds nombre de bugs et qualité d'un projet. À mon humble avis, un projet open source de par sa nature ouverte aura toujours plus de bugs, non pas que sa qualité soit inférieure ou meilleure qu'un logiciel propriétaire, mais juste le fait que la base de données de bugs soit publique rend possible à n'importe quel développeur ou utilisateur de reporter un bug. Donc forcément des projets très actifs comme MySQL ou MariaDB qu'on retrouve dans chaque distribution GNU/Linux et qui sont très utilisés vont générer plus de rapports de bugs.

Je ne confonds rien. Un projet de piètre qualité aura plus de bugs qu'un projet de bonne qualité, tout en sachant que comparer le nombre de bugs ne peut avoir qu'une signification pour des projets équivalents. On a ici deux projets équivalents, Je pense que la nature du projet n'a que peut d'incidence sur le nombre de bugs qui sera rapporté. Cela dépend principalement de l'utilisation du logiciel et de l'ouverture du processus de report de bug.

Une faille de sécurité est toujours un bug

Non. Une faille de sécu peut être une erreur de configuration ou une erreur de conception.

Je ne suis pas certains que plus il y a de bugs plus il y a de risques de failles, un bug est rarement une faille de sécurité, cet argument reste à prouver.

Le contraire aussi

L'auteur n'a pas fait son travail correctement, sinon il aurait trouvé que le nombre de CVE pour l'année 2019 de MySQL est bien supérieur à celui de SQL Server.

Je n'ai pas fait non plus mon travail correctement alors. J'ai regardé le nombre de CVE, et pour MySQL, cela s'arrête à 2016. Où sont les chiffres pour 2019 ?

Il faudrait aussi étudier le niveau de ces failles et le temps de correction. Ensuite MySQL est open source, possède deux forks actifs (MariaDB et Percona Server), MySQL ou MariaDB sont aussi présents dans toutes les distributions GNU/Linux, MySQL est installé sur des dizaines de millions de sites web et Intranet. Peut-être que ce nombre de CVE est aussi la rançon de son succès.

Enfin un argument censé ! Merci. Sauf pour le temps de correction, je ne vois pas trop en quoi ça influe sur la sécurité)

Au lieu de de se contenter à des faits techniques, l'auteur dénigre MySQL et arrose la communauté libre au passage : « cela donne froid dans le dos pour certains SGBD du monde libre» , « technologie est hors de portée du monde libre », « comme c’est du soi-disant libre ». MySQL est un produit profondément open source, diffusé sous GPL (qui est une licence pourtant écrite par la FSF) afin que seul Oracle puisse diffuser des versions commerciales de MySQL (un contributeur doit accorder son droit d'auteur à Oracle en signant l'Oracle Contributor Agreement).

En sortant les phrases de leur contexte, on peut leur faire dire tout et n'importe quoi. Il ne dénigre pas le libre. Il dénigre les SGBD libre du point de vue de la cryptographie. La nuance est quand même importante !

Est-il inconcevable que toi et l'auteur puissiez imaginer que les développeurs de MySQL sont des développeurs payés à plein temps par Oracle ? Est-il inconcevable de penser qu'en 2019 des sociétés comme Red Hat, Microsoft, IBM, Intel paient des ingénieurs à plein temps pour développer des logiciels open source de haute technicité comme le noyau Linux, le navigateur web Chromimum, le compilateur Clang ? Est-il inconcevable en 2019 de penser que la qualité d'un logiciel ne dépend pas de sa licence ?

Oh mais je le conçois. Mais pour MySQL, quand on connait son historique, j'avoue que j'ai du mal à le croire. MySQL est un projet personnel à la base, avant la création de MySQL AB, racheté ensuite par Sun puis par Oracle... qui possède une base de données éponyme depuis de nombreuses années. Est-ce qu'Oracle a décidé de mettre autant de salarié derrière MySQL que Oracle ? Je ne suis pas vraiment certains...

J'ai démontré que certains faits étaient faux ou baisés. De plus les démonstrations de l'article n'indiquent pas la version de MySQL, ni le nom est la version du système d'exploitation utilisé, ni quel moteur de stockage ont été utilisés, c'est donc difficile de reproduire ces démonstrations de l'auteur dans les mêmes conditions. Ce n'est pas très sérieux pour un professionnel. Ces faits sont peut-être en partie exacts, certainement dramatisés ou n'ont pas réussi à être contré totalement ou partiellement, car il n'y a peut-être aucun expert MySQL qui lira cet article ou qui veut perdre son temps à répondre à ce FUD.

Jusqu'à présent, tu n'as rien démontré du tout. Pourquoi préciser la version quand cela concerne toutes les versions ? Le moteur, pour peut qu'on s'y connaisse un chouilla, on devine facilement que c'est InnoDB (mais je l'accorde, la précision manque à ce sujet).

Je peux bien attaquer un peu l'auteur puisque l'auteur s'attaque bien la communauté du libre en prétendant qu'ils ne sont pas compétant (des technologies qui seraient hors de portée du monde libre) alors que MySQL est un projet open source développé principalement par des salariés d'Oracle depuis dix ans.

Comme dit plus haut, c'est beau de sortir les phrases de leur contexte. Le libre n'est pas incompétent. Je me permet de citer le passage entier, contextualisé :

Tous les SGBD prétendent faire du chiffrement. Mais lorsque l’on examine à la loupe ce qui est fait et comment cela est fait, cela donne froid dans le dos pour certains SGBD du monde libre. Il en est ainsi de MySQL/MariaDB comme de PostGreSQL.

L’étude de la problématique de chiffrement et via les préconisations de la CNIL et les règlements du RGPD(7), montre sans équivoque que presque toutes les données d’une base contenant des personnes physiques devraient être chiffrées. Certes le nom, le prénom, mais aussi les emails, numéros de téléphone doivent l’être, mais aussi la combinaison d’une adresse ou d’une action unitaire et d’une date. De fil en aiguille c’est la base entière qu’il faut chiffrer. Pour cela les grands éditeurs (Oracle, Microsoft SQL Server) proposent une méthode globale appelée TDE (Transparent Data Encryption) pour chiffrer de manière élégante et sans impact sur les performances relationnelles, la totalité des données de la base. Cette technologie est hors de portée du monde libre.

Dans MySQL/MariaDB, le chiffrement impose la connaissance des clefs dans l’appel de fonction de déchiffrement ou bien le stockage de la clef à titre de fichier dans le système de fichiers à la portée du serveur. Un peu comme si vous laissiez votre voiture fermée à clef avec les clefs dessus. Lorsque l’on sait que la majorité des vols de données sont le fait d’attaques internes à l’entreprise, ce niveau de sécurité est plus qu’illusoire.

On y comprend qu'actuellement, vu l'architecture retenue pour la gestion du chiffrement dans les SGBD libre les plus répandues, il est techniquement quasi-inutile de mettre en place des technologies comme TDE.

Ce que je constate, c'est que pour l'instant, quasiment toutes les attaques ont été faite envers l'auteur et ses intentions, et non les faits qu'il rapporte. Personnellement, je ne lis pas dans les pensées, mais beaucoup semblent dire qu'il ment sciemment. Pourtant, le seul point sur lequel pour l'instant il a été pris en défaut, c'est sur le support des clés étrangères au sein de MySQL/MariaDB (car utilisant une syntaxe acceptée mais sans effet !), et vue l'erreur, je pencherai plutôt pour une erreur qu'une tromperie volontaire....

[escartefigue]

Bonjour,

Je commence avec ma casquette de correcteur

N'ayant aucune compétence sérieuse de SQL, comme l'auteur, je ne conteste pas ces exemples (que je ne peux et veux pas vérifier) qui sont certainement véridiques (ou pas) pour la plupart.

C'est fortement méconnaitre l'auteur. Il est extrêmement réputé et à même écrit des livres qui sont des références dans le domaine.

Selon toute vraisemblence, ce que voulais dire FatAgnus c'était "Nayant aucune compétence sérieuse en SQL, contrairement à l'auteur..." la suite de la phrase en atteste

Et maintenant, en tant que simple contributeur
Je crois que ce sujet est devenu stérile et qu'il serait temps de le clôturer

[triaguae]

Code :

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

1
2
3
4
5
CREATE TABLE T (C INT UNIQUE);
 
INSERT INTO T VALUES (1), (2), (3);
 
UPDATE T SET C = C + 1;

J'ai testé sur PostgreSQL ce comportement et quelle déception de voir la même erreur que sous MySQL

J'utilise PG quotidiennement depuis plusieurs années et j'ai été rarement déçu, contrairement à Oracle (version 11g) que j'utilise également tous les jours, et dont le respect du standard sql est parfois douteux, la gestion des dates pourrie, pas de support du json, pas d'autoincrément.........

[SQLpro]

Mais cela montre que MySQL tend vers la norme, ce qui est positif. Et mon but n'était pas de te faire changer de position.

Le tutoriel présente des défauts de MySQL, j'aimerais connaitre aussi ceux de SQL-Server.

Son principal défaut, hélas congénital car hérité de Sybase, lui même hérité d'INGRES est d'interdire le "multi NULL" dans une contrainte d'unicité.
Il existe cependant une voie de contournement en créant un index UNIQUE filtré WHERE … IS NOT NULL.

A +

[SQLpro]

J'ai testé sur PostgreSQL ce comportement et quelle déception de voir la même erreur que sous MySQL

J'utilise PG quotidiennement depuis plusieurs années et j'ai été rarement déçu, contrairement à Oracle (version 11g) que j'utilise également tous les jours, et dont le respect du standard sql est parfois douteux, la gestion des dates pourrie, pas de support du json, pas d'autoincrément.........

Hélas oui, PG est aussi incapable de mettre à jour tout type de contrainte d'unicité car il fait du ligne à ligne et non de l'ensembliste. Mais au moins dans PG il existe une solution de contournement qui consiste à utiliser une contrainte déferrée. Mais il faut l'avoir penser au départ… C'est un peu grossier, mais ça marche !

Je compte d'ailleurs aussi publier un article à charge sur PostgreSQL montrant aussi ses défauts… Je pense que je vais me faire encore beaucoup d'amis !

Quant à Oracle, nous avons fait une session entre professionnels pour comparer Oracle à SQL Server, les avantages et inconvénients de l'un et de l'autre d'un point de vue comparatif… (entre experts Oracle et MS SQL Server) et si j'ai un moment, je publierais nos notes !

A +