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

Citation:

---

Envoyé par al1_24

Il faut se tenir à la page...
L'auto-incrément est pris en charge par Oracle depuis la version 12c (2013), certes bien en retard sur la norme SQL-2003.

---

Certes, mais j'ai fait de l'Oracle dans ces années là et c'était du 10 parce qu'évidemment il y a toujours du délai entre la version que possède une boîte et les releases. Et j'ai retrouvé des post de 2016 qui affirment encore d'utiliser des séquences (ce qui en vrai est mieux, notamment lorsque tu veux faire beaucoup d'insert consécutifs).

En outre n'était pas un DBA Oracle (ni DBA tout court), je ne me tient effectivement pas de façon strict à la page. Je lit des sujets à gauche à droite, et je n'étais pas tombé encore sur cette info.

Citation:

---

Envoyé par SQLpro

Une entreprise qui vend un produit a une responsabilité légale et obligatoire (défaut de conformité, défaut de vice caché… etc) que n'a pas le monde du libre. Autrement dit, tu peut te retourner contre Oracle, MS ou IBM pour leur imposer de corriger, alors que dans le monde libre c'est juste impossible !
C'est pour cela que certains états d'Europe, autrefois fervent défenseurs du libre, ont désormais imposé des logiciels propriétaires notamment pour tout ce qui est données à caractère personnelles ou sensibles...

A +

---

Amazon aurait ces responsabilités légales et obligatoire sur ses services cloud? Quand on sait que ses deux plus grosse base de données sont des forks de MySQL (Aurora) et de Postgres (Aurora ou Redshift)...
Si oui, cela serait compliqué à tenir pour eux, mais c'est quand même le cas... Et ils sont aller chercher des conformité avec des normes pour le stockages de données médicales sur ces services: https://aws.amazon.com/compliance/hi...ces-reference/
Amazon compte bien sur deux SGBD du monde libre pour se battre avec Oracle, c'est que MySQL et Postgres ne sont pas si difficile à utiliser en entreprise. (Y compris grande...)

Citation:

---

Envoyé par bloginfo

Votre démonstration est entachée de nombreuses approximations.

---

Désolé de vous le dire, mais pour le coup, c'est votre réponse qui est très approximative.

Citation:

---

Envoyé par bloginfo

Et son exemple sur la modification des valeurs d’un champ à valeur unique est tout simplement impossible à réaliser puisque les valeurs 1,2,3 ayant été saisies préalablement, il n’est pas possible de passer la valeur de 1 à 2 et de 2 à 3, puisqu’elles existent au niveau de la colonne ! Je ne vois pas en quoi, dans cet exemple, MySQL et MariaDB ne seraient pas relationnels, alors qu’il s’agit d’un problème de champs à valeur unique !!! Il y a là un contresens total dans la démonstration.

---

L'exemple donné par SQLPro est juste... un exemple. Certes, pas très réaliste (qui ferait ce genre d'opération sur la clé primaire ?), mais qui met en avant le caractère non ensembliste des opérations. La clé serait unique (sans être primaire) que le problème serait le même. Et un SGBD relationnel doit être ensembliste. Ce n'est pas moins qui le dit, ni même Frédéric, mais Codd, considéré comme le "père" du modèle relationnel. La caractère ensembliste étant pris en défaut, le SGBD ne peut être relationnel.

Citation:

---

Envoyé par bloginfo

Ensuite, il semble faire une autre erreur dans sa démonstration lorsqu’il évoque l’impossibilité de revenir à la situation de départ dans une transaction avec un ROLLBACK. Je pense qu’il a dû laisser le table en mode MyISAM. Il s’est pris les pieds dans le tapis. Ca arrive à tout le monde, moi le premier ! vous pouvez tester ce code : il marche.

Code:

---

1 2 3 4 5 6

CREATE TABLE t (c DATETIME) ENGINE=InnoDB; BEGIN WORK; INSERT INTO t VALUES (NOW()); ROLLBACK WORK; SELECT c FROM t;

---

---

Lisez son article ! Il ne dit pas ça du tout !!!
Il parle de transactions validées automatiquement dès la moindre opération DDL, pas d'un rollback inexistant.

Pour la coup de comm c'est réussi !

L'article figurait sur la page de Google news entre samedi midi et dimanche soir ! :aie:

Dommage j'ai pas de capture d'écran ...

Vous oubliez MariaBackup avec lequel nous faisons à chaud des sauvegardes consistantes des instances des deux moteurs.

Sur le fond, je n'ai toujours pas compris à quoi peut vous servir cet article entaché d'une absence de pratiques manifeste sur ce logiciel. Vous n'avez même pas parlé des verrous au niveau des transactions sur lesquels il y a pourtant tant de choses à dire ?

Là-encore, votre exemple est tiré par les cheveux et ne marche pas lorsque l'utilisateur de la transaction et celui qui modifie la table sont différents. Quand c'est le même utilisateur, il y a en effet un COMMIT automatique. C'est un choix des développeurs qui n'entache en rien le caractère transactionnel du moteur InnoDB, malgré ses limitations.

Citation:

---

Envoyé par bloginfo

Là-encore, votre exemple est tiré par les cheveux et ne marche pas lorsque l'utilisateur de la transaction et celui qui modifie la table sont différents. Quand c'est le même utilisateur, il y a en effet un COMMIT automatique. C'est un choix des développeurs qui n'entache en rien le caractère transactionnel du moteur InnoDB, malgré ses limitations.

---

Un choix c'est quand il existe des alternatives; Aucune alternative n'est proposée par MySQL lorsqu'une commande DDL force toutes les transactions en cours a être COMMITées, sans aucun avertissement d'aucune sorte aux utilisateurs actuels de la base !

A +

Citation:

---

Envoyé par bloginfo

Vous oubliez MariaBackup avec lequel nous faisons à chaud des sauvegardes consistantes des instances des deux moteurs..

---

Non, cela n'est pas supporté mais le fait croire. Seule la version Enterprise payante de MySQL (vendue par Oracle) permet de faire des sauvegardes à chaud consistante, c'est a dire sans jamais bloquer aucun utilisateur ni aucune requête effectuée par les utilisateurs concurrents pendant tout le temps de la sauvegarde !

A +

Je l'utilise et il permet des sauvegardes consistantes !

Citation:

---

Envoyé par SQLpro

Une entreprise qui vend un produit a une responsabilité légale et obligatoire (défaut de conformité, défaut de vice caché… etc) que n'a pas le monde du libre. Autrement dit, tu peut te retourner contre Oracle, MS ou IBM pour leur imposer de corriger, alors que dans le monde libre c'est juste impossible !
C'est pour cela que certains états d'Europe, autrefois fervent défenseurs du libre, ont désormais imposé des logiciels propriétaires notamment pour tout ce qui est données à caractère personnelles ou sensibles...

A +

---

prendre une décision politique dictée par les dessous de table et les petits cadeaux entre amis comme un choix technique éclairé et lucide, c'est vraiment se foutre de la gueule du monde!

Monsieur SQLpro, vous avez oubliez les dates avec MySQL ! Alors que c'est ce qu'il y a de plus rigolo ! :calim2:

Pouvez vous trouver comment aboutir à ce résultat, avec cette requête, et cette table ?

Code:

---

1 2 3 4 5 6 7

CREATE TABLE TEST ( ID INT PRIMARY KEY AUTO_INCREMENT, TEST_DATE DATETIME );   SELECT TEST_DATE, TEST_DATE + INTERVAL 1 DAY FROM TEST;

---

Code:

---

1 2 3

TEST_DATE TEST_DATE + INTERVAL 1 DAY 2000-11-30T00:00:00Z (null) 2000-11-30T00:00:00Z 2000-12-01T00:00:00Z

---

Non, non vous ne revez pas, il s'agit bien de la même date enregistrée ! Pourtant, seule une des deux accepte les opérations de dates...

Voilà la solution !

Code:

---

1 2 3

INSERT INTO TEST (TEST_DATE) VALUES ( STR_TO_DATE("2001-00-00", "%Y-%m-%d") ), ( STR_TO_DATE("2000-11-30", "%Y-%m-%d") );

---

Et ouai, 2001-00-00 donne 2000-11-30 !! ( il faut le savoir lol ). Sauf qu'en fait non... c'est bien une date invalide qui est enregistrée ! Donc on peut l'afficher (et il faudra m'expliquer comment...) mais on ne peut pas faire d'opération dessus.

Non seulement c'est impossible à diagnostiquer (car l'erreur a eu lien à l'insertion...), mais c'est en plus impossible à corriger.

Testé avec SQL FIddle

Citation:

---

Envoyé par Sebajuste

Monsieur SQLpro, vous avez oubliez les dates avec MySQL ! Alors que c'est ce qu'il y a de plus rigolo ! :calim2:
…
Non seulement c'est impossible à diagnostiquer (car l'erreur a eu lien à l'insertion...), mais c'est en plus impossible à corriger.

---

S'il n'y avait que ce genre de corruption de données, mais prenons aussi les exemples sur les MULSTISETS dont les opérations sont incompréhensibles du fait de la porosité des couches entre le monde relationnel et sa traduction en objet !

A +

Citation:

---

Envoyé par bloginfo

Je l'utilise et il permet des sauvegardes consistantes !

---

Vous ne l'avez visiblement pas testé en production avec quelques centaines d'utilisateurs effectuant des transactions pendant la sauvegarde….

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 +

Citation:

---

Envoyé par SQLpro

Vous ne l'avez visiblement pas testé en production avec quelques centaines d'utilisateurs effectuant des transactions pendant la sauvegarde….

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 +

---

Et donc, à ce client, vous lui avez vendu une solution pour changer de SGBD? Non et c'est encore un client? 8O

Il existe toujours des solutions de sauvegarde, même s'il faut restructurer la base pour cela. Le SGBD n'y est pour rien si la structure est merdique à sa fondation... le problème aurait sans doute était le même sur n'importe quel SGBD, mais bon, c'est plus fun d'accuser le SGBD qu'on déteste.
Perso, j'adore restructurer les data, c'est très fun avec un petit côté casse-tête.

Citation:

---

Envoyé par Manu0086

Il existe toujours des solutions de sauvegarde, même s'il faut restructurer la base pour cela.

---

En vertu de la séparation physique/logique voulue par le créateur des bases de données relationnelles, Franck Edgar Codd, ceci est strictement interdit dans un SGBD Relationnel digne de ce nom… Vous me confirmez donc, par vos propos que MySQL n'est donc pas relationnel… Ce que nous savions déjà… EN gros, on en revient au CoBOL des années 60 grâce à MySQL !

Citation:

---

Le SGBD n'y est pour rien si la structure est merdique à sa fondation... le problème aurait sans doute était le même sur n'importe quel SGBD, mais bon, c'est plus fun d'accuser le SGBD qu'on déteste.

---

Et bien justement non. Par exemple quelque soit la structure de la base de données, que ce soit dans Oracle ou SQL Server, les sauvegarde peuvent s'effectuer à chaud, même s'il y a de multiples utilisateurs, et même si chacun est en train de faire un ALTER TABLE ! Et sans jamais avoir aucun blocage consécutif au processus de sauvegarde… Ce qui est impossible avec MySQL…

A +

Super intéressant, même si "en pratique" MySQL est (me semble-t-il) pour l'essentiel utilisé au travers de CMS dont l'utilisation est éprouvée, et via des hébergeurs qui proposent des solutions "clé en main" (exemple : Wordpress...)

Pour ma part, j'utilise SQL Server pour la partie data en entreprise depuis 2001 (avec des dév. en Dotnet pour l'essentiel et pas mal de BI derrière) mais je suis également utilisateur de MySQL pour la partie web, depuis à peu près la même époque. La particularité étant que je n'ai toujours utilisé MySQL que sur des projets simples d'une part (quelques tables) OU au travers de CMS élaborés (Wordpress et Prestashop me concernant)

En cela, même si ce n'est "théoriquement" pas correct ou "peu correct", la plupart des contrôles sont réalisés depuis la partie applicative. Au final, l'article s'adresse surtout et essentiellement aux développeurs purs et durs qui font de l'applicatif web, même si cela permet de comprendre certains "comportements" du moteur de base de données sur certains types de requêtes.

En termes de perfs, il ne faut pas s'attendre à des miracles, et c'est bien pour cela qu'on utilise quasi systématiquement des systèmes de cache sur les principaux CMS du marché qui s'appuient sur MySQL. Même si parfois, on ne peut pas trop "faire autrement" (exemple : un dév. de site web avec des fonctionnalités métier particulières s'appuyant sur Wordpress, sur base de custom post types et custom taxonomies... Un dév. 100% maison basé sur un autre SGBD supporté par l'hébergeur - usuellement PostGreSQL - demanderait un temps et des coûts de mise en oeuvre exorbitants face à une solution "clé en main" facilement adaptable, certes pas optimale, mais très utilisable pour ce qu'on lui demande de faire, et avec un "time to market" extrêmement bref)

En conclusion : j'utilise MySQL par confort, tout en sachant que ce n'est pas la meilleure solution, mais pour ce que je fais avec, ce n'est clairement pas un critère majeur de choix au niveau technique !

Citation:

---

Envoyé par cedric_g

Super intéressant, même si "en pratique" MySQL est (me semble-t-il) pour l'essentiel utilisé au travers de CMS dont l'utilisation est éprouvée, et via des hébergeurs qui proposent des solutions "clé en main" (exemple : Wordpress...)
…

---

Votre commentaire est de loin le plus censé. Je ne suis pas là pour condamner l'utilisation de MySQL. Il a sa place pour des petits sites web perso et des CMS de petite à moyenne taille que l'on compense effectivement par plus de hardware/software… (bonjour la trace écologique…). Je l'utilise d'ailleurs moi même à travers WordPress et mon site professionnel http://mssqlserver.fr/

Mon but est simplement de faire comprendre que MySQL n'est pas compatible avec des données sensible d'entreprise, comme ce serait le cas avec un ERP, ou encore dans certains domaines comme la santé, le bancaire… et bien entendu dès que la taille des bases est importante, le volume des transactions élevé, le panel d'utilisateurs conséquent ou la charge continue sans jamais d'heures creuses.

Et mon but est donc dans montrer les dangers pour ceux qui ne les connaissaient pas !
J'ai visiblement bien réussi mon coup vu le nombre de consultations et de commentaires...

A +

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, mais ils doivent utiliser les autres produits aussi. Après je ne sais pas si c'est avec des grosses bases, vu le secteur c'est probable.

Je pense que selon la situation, l'une ou l'autre sera adaptée. (volumétrie données, coût, compétences internes, etc.) 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.

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.

D'un autre coté, ne pas maitriser l'un ou l'autre donnera le même résultat, il faut maitriser le produit pour pouvoir faire de l'optimum. Et surtout sur les très grosses bases, cea prendra tout de suite une forte empleur. Un serveur n'ayant pas assez de mémoire donnera des résultats catastrophiques quelque soit le SGBD, tout comme la mauvaise utilisation des index.

Avec SQL Server express on peut gérer gratuitement jusqu'à 10 Go, ce qui est déjà une belle taille pour les petites structures.

En tout cas l'article montre les cas ou MySQL peut poser des problèmes, et même si ils sont contournables, cela reste intéressant.

Citation:

---

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 !

---

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.

Citation:

---

Envoyé par SQLpro

Votre commentaire est de loin le plus censé. Je ne suis pas là pour condamner l'utilisation de MySQL. Il a sa place pour des petits sites web perso et des CMS de petite à moyenne taille que l'on compense effectivement par plus de hardware/software… (bonjour la trace écologique…). Je l'utilise d'ailleurs moi même à travers WordPress et mon site professionnel http://mssqlserver.fr/

Mon but est simplement de faire comprendre que MySQL n'est pas compatible avec des données sensible d'entreprise, comme ce serait le cas avec un ERP, ou encore dans certains domaines comme la santé, le bancaire… et bien entendu dès que la taille des bases est importante, le volume des transactions élevé, le panel d'utilisateurs conséquent ou la charge continue sans jamais d'heures creuses.

Et mon but est donc dans montrer les dangers pour ceux qui ne les connaissaient pas !
J'ai visiblement bien réussi mon coup vu le nombre de consultations et de commentaires...

A +

---

https://www.percona.com/blog/2017/06...part-2-innodb/

https://www.teschglobal.com/resource...ep-after-mysql

Le MySQL CE est peut-être mauvais, mais ses forks sont viables pour le stockage de données sensibles ou médicales. 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.

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