IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

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


Sujet :

MySQL

  1. #1
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut Découvrez les dangers de MySQL et MariaDB, par Frédéric BROUARD (SQLpro)
    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.
      34  6

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 423
    Points : 40 078
    Points
    40 078
    Billets dans le blog
    9
    Par défaut
    Merci pour cet article

    C'est... consternant !
      3  0

  3. #3
    Modérateur
    Avatar de blueice
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2003
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2003
    Messages : 3 487
    Points : 5 134
    Points
    5 134
    Par défaut Question
    Par quoi remplacer MySQL dans ce cas ou que devrait-on utiliser ?
      2  0

  4. #4
    Membre du Club
    Profil pro
    dqqds
    Inscrit en
    Août 2007
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : dqqds
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2007
    Messages : 14
    Points : 69
    Points
    69
    Par défaut Article intéressant mais à charge
    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
      29  0

  5. #5
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Septembre 2011
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Septembre 2011
    Messages : 2
    Points : 17
    Points
    17
    Par défaut
    Désolé, mais comme miaou_, je n'adhère pas du tout au discours.

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

    N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !
      10  1

  6. #6
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 761
    Points : 10 546
    Points
    10 546
    Billets dans le blog
    21
    Par défaut
    Très bon article recensant de nombreux points.

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

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

    Citation Envoyé par Gregslv
    N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !
    SQL Server coute cher pour les versions Enterprise et Standard. La version Express est tout à fait abordable (gratuite !) et est même disponible maintenant sur... Linux ! Et avant d'arriver aux limites de la version Express, et bien, il faut y aller ! (4 coeurs, 10G par BD hors fonctionnalité FileStream).
      8  1

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par blueice Voir le message
    Par quoi remplacer MySQL dans ce cas ou que devrait-on utiliser ?
    PostgreSQL à condition de :
    • Ne pas avoir de grosses bases (se limiter à quelques centaines de Go - PostgreSQL ne dispose pas d'espace de stockage administrés)
    • Se limiter en nombre d'utilisateurs simultanés (ne pas trop dépasser la centaine)
    • Ne pas avoir d'application tournant 24h sur 24, 7 jours sur 7 (la maintenance est bloquante - VACUUM et particulier…)
    • Ne pas avoir des requêtes trop complexes (se limiter au plus à une douzaine de table dans la requête à cause de GEQO)


    SQL Server ou Oracle (beaucoup plus cher) ou IBM DB2 (encore beaucoup plus cher)

    A +
      5  0

  8. #8
    Membre éprouvé
    Femme Profil pro
    Inscrit en
    Juillet 2012
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Italie

    Informations forums :
    Inscription : Juillet 2012
    Messages : 271
    Points : 1 043
    Points
    1 043
    Par défaut
    Moi j'utilise sqlite, aucun problème
      5  0

  9. #9
    Membre actif Avatar de oneDev
    Homme Profil pro
    dilettant
    Inscrit en
    Mars 2019
    Messages
    220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : dilettant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2019
    Messages : 220
    Points : 244
    Points
    244
    Par défaut
    Merci , c'est bien de connaitre ces limites !
      1  0

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par miaou_ Voir le message
    … 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.
    Cette fonctionnalités est présente dans la norme SQL depuis la version 3 datant de 1999, soit 20 ans… IBM DB2 et SQL Server l'implémente correctement. Oracle s'en approche partiellement avec le BFile. L'un des intérêts majeur est de pouvoir synchroniser les sauvegardes des données relationnelles et des fichiers électroniques associés ce qui ni MySQL, ni PostgreSQL sont en mesure de faire, en sus du transationnement des fichiers. Sans cela en cas de restauration on se retrouve immanquablement avec des fichiers manquants ou orphelins...
    Il est plutôt rare (à ma connaissance) de laisser la gestion des documents électroniques au sgbd
    Peut être parce que vous ne connaissez pas les autres SGBDR et sans doute parce que vous n'avez jamais eu affaire à de grosses GED… !
    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.
    S'en est encore très loin. J'avais lu tout ceci avant de rédiger mon article.
    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.
    Quand on analyse un cout il faut analyser tout :
    • le cout des machines sous jacente (il faut beaucoup plus de ressources aux SGBD "Libre" pour atteindre les mêmes performances),
    • le cout de l'administration qui est généralement très élevé dans le libre car il y a très peu d'outil pour se faire…
    • le coût d'une éventuelle panne bloquant la production
    • le coût des bugs à corriger

    Tout cela s'appelle le TCO. Il est généralement favorable au libre sur de petites config dont la sécurité importe peu. Il est très généralement favorable aux solutions du style SQL Server dès que la volumétrie des données, et des transaction est importante…
    Pour votre information, sur de très petites bases, les Oracle et SQL Server ont des solutions gratuites…
    Et certaines éditions sont très peu cher. Par exemple l'édition WEB de SQL Server coute quelque dizaines d'euro par mois….
    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).
    C'est un des points extrêmement négatif d'Oracle. Sa hot line de premier niveau est lamentable et celle de second niveau totalement hors de prix. Ce n'est pas du tout le cas de Microsoft dont la hot line Europe est à Paris et non seulement disponible, mais efficace et rapide !

    A +
      4  0

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par emilie77 Voir le message
    Moi j'utilise sqlite, aucun problème
    Pour information, j'utilisait encore il y a peu Mozilla Thunderbird qui utilise du SQL Lite pour y stocker les messages. Du fait du volume accumulé, j'ai eut des nombreuses corruption de données et il est devenu impossible de réparer et récupérer les bases…. J'ai perdu plus de la moitié des mes emails et le volume de données a explosé (de très nombreux messages apparaissent plusieurs dizaines de fois….).
    Sans compté que SSQL Lite n'est pas du tout transactionnel ni concurrentiel. C'est fait pour de l'embarqué. C'est comme si vous compariez un vélo à une navette spatiale !

    A +
      5  0

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Gregslv Voir le message
    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 !
    Pour information, il n'y a pas de licence par an pour SQL Server, sauf en ce qui concerne l'édition WEB qui est en mode SPLA et c'est un peu plus de mille euros par an quelque soit le nombre de CPU (et non VCPU, encore une erreur…).

    A +
      1  0

  13. #13
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    Novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    L'article est intéressant mais je rejoins l'avis d'autres sur le ton employé qui dévalorise totalement l'article.

    De plus, donner des liens vers des rapports (je parle pas du bug) qui datent de plus de 5 ans... :/

    Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évolue le plus rapidement.

    De plus l'affaire du chiffrement et du stockage de document électronique ne peut en aucun cas être imputé uniquement au SGBD, oui il peut fournir des solutions de chiffrement mais pour moi les applicatifs sont principalement responsable de cette tâche.
    Oui j'ai déjà eu à faire face à une grosse GED, et ni SQL Server ni Oracle n'ont été retenu pour cette tache, ni MySQL d'ailleurs.

    Oui MySQL et MariaDB ont leurs inconvénients comme tout SGBD, mais dans tout les soit disant "méfaits/mensonge" remontés, j'ai jamais eu à faire des choses qui auraient pu me remonter ça. Et pourtant je lui en ai fait voir de toutes les couleurs... (une BDD sous MySQL 5 avec plus de 150 tables et 600+ Millions d'enregistrements)

    Bref, j'ai utilisé SQLServer et Oracle pendant plus de 10 ans et sincèrement PLUS JAMAIS !
    Je parle même pas de PostgreSQL qui est totalement à la ramasse.

    Toutefois cela reste mon avis.
      6  0

  14. #14
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Septembre 2011
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Septembre 2011
    Messages : 2
    Points : 17
    Points
    17
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Pour information, il n'y a pas de licence par an pour SQL Server, sauf en ce qui concerne l'édition WEB qui est en mode SPLA et c'est un peu plus de mille euros par an quelque soit le nombre de CPU (et non VCPU, encore une erreur…).

    A +
    Bizarre, selon ce document Microsoft https://download.microsoft.com/downl..._Datasheet.pdf, il est bien stipulé :

    "To license a VM or container with core licenses, purchase a core license for each virtual core (virtual thread)allocated to the VM"
      2  0

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Gregslv Voir le message
    Bizarre, selon ce document Microsoft https://download.microsoft.com/downl..._Datasheet.pdf, il est bien stipulé :

    "To license a VM or container with core licenses, purchase a core license for each virtual core (virtual thread)allocated to the VM"
    Vous avez le choix de limiter la licence au vCPU d'une VM hébergeant une instance de SQL Server, si ce nombre est inférieur au nombre de cœurs physique, ou bien, de licencier le nombre de cœurs physique quelque soit le nombre de vCPU de l'ensemble des instances de SQL Server hébergées sur l'hôte.

    Ce qui revient bien à dire que vous ne payez que pour des cœurs physiques…

    A +
      1  0

  16. #16
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 933
    Points : 51 748
    Points
    51 748
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Xurudragon Voir le message
    Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évolue le plus rapidement.
    Soit vous plaisantez, soit vous n'êtes pas au courant de la concurrence….

    Mais pour votre information, voici quelques manques de MySQL que les concurrents ont :
    • intégration des schéma SQL
    • gestion des transactions imbriquées
    • transationnement du DDL, DCL
    • gestion des espaces de stockage
    • indexation verticale
    • indexation XML
    • table in memory
    • journalisation asynchrone
    • DATALINK
    • FileTable
    • Table temporelles
    • Utilisation de HMS pour le stockage des clefs de chiffrement


    Voici maintenant quelques un des modules très incomplets ou fortement bogués qui les rendent inexploitable dans MySQL :
    • full text
    • spatial
    • XML
    • JSON


    A +
      4  1

  17. #17
    Membre du Club
    Homme Profil pro
    Développeur Back-End
    Inscrit en
    Novembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Back-End
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2012
    Messages : 13
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Soit vous plaisantez, soit vous n'êtes pas au courant de la concurrence….

    Je suis au courant oui, mais avoir ces fonctionnalité ne font pas forcément d'elles des fonctionnalités utiles ou (très) utilisées.
    Et quand bien même, j'ai toujours réussi à faire sans et j'en m'en porte pas moins bien pour autant.

    Perso, je suis pas trop pour des modules tel que le JSON dans des SGBDR... Laissons ça à des système "conçu" pour. Même si ça peut être pratique dans certain cas et sur un volume de données restreint.
    Chez mon client actuel ils l'utilisent ce module JSON, j'ai moi-même fais des benchs sur 17 millions d'enregistrements, même si les concurrents (tel que ElasticSearch & Co) font très certainement mieux, MySQL se défend.

    Mais comme je l'ai dis, MySQL a aussi ses défaut et n'est pas forcément complet, d’ailleurs aucun SGBD ne l'ai réellement.
    N'oublions pas ancienneté MS SQL Server c'est 30 ans d'âge et Oracle 42 ans, Ils n'ont pas eu les mêmes passif ni les même moyens, pour un produit Open Source...
      3  3

  18. #18
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 915
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 915
    Points : 44 376
    Points
    44 376
    Par défaut
    Je trouve également l'article à charge. Je l'ai quand-même trouvé intéressant, et je sais que tu n'aimes pas du tout MySQL.

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

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

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

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

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

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

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

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

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

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

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

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

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

  19. #19
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 915
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 915
    Points : 44 376
    Points
    44 376
    Par défaut
    Pour information, j'utilisait encore il y a peu Mozilla Thunderbird qui utilise du SQL Lite pour y stocker les messages. Du fait du volume accumulé, j'ai eut des nombreuses corruption de données et il est devenu impossible de réparer et récupérer les bases…. J'ai perdu plus de la moitié des mes emails et le volume de données a explosé (de très nombreux messages apparaissent plusieurs dizaines de fois….).
    pour info : Les messages ne sont pas stockées en SQLite dans Thunderbird, mais au format MBOX. Les fichiers d'index .msf de chaque dossier sont effaçable et se reconstituent. Cela peut régler pas mal de problèmes. Les fichiers SQLite utilisés sont global-messages-db permettant la recherche, supprimable également. Lithning et les autres extensions utilisent des bases SQLite.
      6  0

  20. #20
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 761
    Points : 10 546
    Points
    10 546
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    Les condamnations CNIL ne concernent pas des problèmes liées à la base de données mais au site lui-même. Utiliser une base cryptée, et/ou autre que MySQL n'aurait rien changé, les failles se situant au niveau du code du site. Dans tous les cas cités, la modification de l'URL permettait d'interroger la base sur des critères inadéquats.
    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.

    Le coup du mot de passe stockée en clair par exemple, il faut vraiment le faire exprès avec un SGBD comme SQL Server pour le faire (car il propose les fonctionnalités qui vont bien). Mais il est difficile de faire autrement en utilisant MySQL.

    De même, pour la gestion des "documents électroniques", (plus communément appelés "fichiers"), elle peut se faire très simplement avec SQL Server, sans avoir à besoin de créer un répertoire qui contiendra les données, dont on aura oublié de gérer les droits et qui se retrouvera indexé par Google et accessible à tout le monde.

    Je pense que c'était ce que voulait dire Frédéric en mentionnant ces failles : les condamnations CNIL auraient pu être évitées simplement en utilisant de bons outils dès le départ.
      7  1

Discussions similaires

  1. Réponses: 0
    Dernier message: 11/04/2017, 21h02
  2. Réponses: 3
    Dernier message: 27/09/2016, 15h00
  3. RHEL 7 supportera MariaDB par défaut à la place de MySQL
    Par Stéphane le calme dans le forum Actualités
    Réponses: 4
    Dernier message: 28/07/2013, 12h30
  4. Réponses: 16
    Dernier message: 31/03/2011, 14h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo