109 réflexions au sujet de « MySQL ? Un SGBDR poudre aux yeux ! »

1. SQLpro Auteur de l’article24 janvier 2015 à 12 h 28 min

   MySQL et le bug de l’arrondis !

   SELECT round(0.95 * 3.5, 2) => 3.32

   Or la règle d’arrondis de la norme IEEE est appliquée par la norme SQL (SQL étant un langage normatif). Cela veut dire que :
   – si le premier chiffre de troncature est entre 0 et 4 inclus, arrondi à l’inférieur
   Рsi le premier chiffre de troncature est entre 5 et 9 inclus, arrondi au sup̩rieur
   Le résultat correct devrait être 3.33.

   C’est un bug hélas monstrueux pour tout ceux qui ont des données comptables (site web de vente, comptabilité d’entreprise, ressources humaines…)

   Connectez-vous pour répondre ↓
2. -kiki- 12 mars 2013 à 12 h 17 min

   Etes-vous sûr de vous!?
   Ce serait complètement débile!!

   Vous n’auriez pas fait vos tests en mettant des champs CHAR au lieu de VARCHAR?

   Connectez-vous pour répondre ↓
   1. SQLpro Auteur de l’article28 mars 2013 à 20 h 08 min

      Hélas oui….

      Il suffit par exemple de créer une colonne de 275 caractères en UTF 8 et d’essayer d’y poser un index…

      A +

      Connectez-vous pour répondre ↓
      1. -kiki- 10 avril 2013 à 18 h 25 min

         Salut,

         Mes tests confirment plutôt que la longueur des caractères est bien dynamique :
         test effectué avec des chaines de 500 caractères.
         accentués : LENGTH = 1000
         non accentués : LENGTH = 500
         la moitié accentués, l’autre moitié non : LENGTH = 750
         (le poids des tables confirme ces différences)

         Pour ce qui est des index, il y a effectivement « tromperie sur la marchandise »…
         (mais c’est pas la première fois qu’on voit une erreur dans la doc de Mysql^^)
         Quelle que soit la longueur de mes enregistrements, le nombre de caractères indexés reste inchangé (avec mes strings de 500 charactères) :
         myisam : 333 caractères indexés
         innodb : 255 caractères indexés

         Je me coucherais moins bête, mais toujours aussi têtu : je considère maintenant les index comme limités « en nombre de caractères ». MAIS C’EST PAS GRAVE!

         (ce qui me faisait le plus peur, c’était la longueur fixe des caractères. j’étais même en train de me demander si la longueur des champs varchar était vraiment dynamique… donc plus de peur que de mal pour moi sur ce coup là

         Connectez-vous pour répondre ↓
3. SQLpro Auteur de l’article9 mars 2013 à 10 h 43 min

   Parmi les trompes-couillons, l’encodage UTF8 de MySQL. Celui ci est supposé compresser les données et a été étudié pour les sites web et ne donne un réel bénéfice de compression que pour la langue anglais (et oui, nos accents sont très volumineux car spécifique au français…).
   Or utiliser l’encodage UTF8 dans une base MySQL est une réelle catastrophe. En effet, au lieu de compresser les littéraux, MySQL prend 3 octets pour tout caractères, histoire de se simplifier la vie ! Il y a comme une tromperie sur la marchandise….
   Le problème est que cela induit des effets de bord très intéressant !
   Exemple : dans un index la longueur de la clef est limitée à 767 octets… soit 266 caractères UTF8. Pire : à partir de ce moment, MySQL tronque les données, mais sans le dire (une maladie générale de MySQL est de faire des erreurs silencieuse…)

   Connectez-vous pour répondre ↓
4. -kiki- 20 février 2013 à 16 h 06 min

   Oui, déterrons ce sujet

   @ Sqlpro : les démonstrations par métaphores peuvent persuader, mais pas convaincre.
   Et aussi pittoresques soient-elles, elles ne sont pas tout à fait à propos.

   Je ne prône pas l’absence de normes! Je suis même d’accord sur l’essentiel : les normes sont nécessaires.
   Mais pour autant, j’apprécie que certains outils s’écartent de cette norme pour être plus proche de mes besoins.
   Si j’utilise Mysql en connaissant ses limites, où est le problème?
   Je ne suis pas un fervent défenseur de la cause Mysql, ni du monde libre! j’essaye simplement de choisir les technos les plus appropriées aux situations.

   Votre exemple sur le LIMIT étant un peu simpliste, ma première réaction a été « jamais je ne me laisserais piéger par ce genre de détail! prévoir tous les cas tordus fait partie du taff! »
   Mais il est vrai que je ne peux pas prétendre connaitre tous les mécanismes de Mysql et que je ne suis pas à l’abri d’une erreur.
   Alors oui, postgre s’impose dès que les données sont un tant soit peu sensibles.
   Car c’est là qu’est vraiment utile la norme (à mes yeux) : nous mettre sur le droit chemin (=nous empêcher de faire des conneries).

   Pour le reste (la majorité des sites web), j’apprécie toujours autant Mysql, même si ça fait de moi un hérétique qui bafoue la sacrosainte séparation logique/physique
   le jour où les systèmes « physiques » changeront le comportement de Mysql, soit je me mettrais à la page, soit je changerais de sgbd.

   @ Cryde : je ne crois pas que ça ait beaucoup changé depuis le rachat.
   il y a bien l’ajout des vues matérialisées, la possibilité d’avoir des index fulltext en innoDB…
   mais de manière générale, je crois que Mysql continue son chemin dans la même direction : ajouter des fonctionnalités.
   Et j’en suis ravi.
   ex : La nouvelle façon d’intégrer memache ouvre encore de nouvelles perspectives!
   mais ce rabat-joie d’SqlPro va encore nous dire que c’est de la poudre aux yeux

   Connectez-vous pour répondre ↓
5. Cryde 15 février 2013 à 15 h 00 min

   Ça serait pas mal de faire une mise à jour de l’article, avec la version 5.6 de MySQL et peut-être être plus nuancé et montré aussi les avantages qu’il pourrait avoir. (sans pour autant les vanter)

   Je suis d’accord qu’avant il était à la ramasse … Mais bon ça à surement changer non ?

   Connectez-vous pour répondre ↓
6. CinePhil 12 novembre 2012 à 15 h 31 min

   Je viens de découvrir encore un truc hallucinant sur MySQL, au hasard d’une discussion.

   Il n’utilise pas les index des tables figurant dans une vue !

   Ce n’est quand même pas comme ça dans tous les SGBD ? Sinon à quoi bon faire des vues ?

   Connectez-vous pour répondre ↓
7. sqlpro Auteur de l’article18 juillet 2012 à 10 h 44 min

   Cher kiki, vous confondez deux notions absolument antagonistes :
   1) les aspect logiques des SGBD Relationnel sur lequel repose les traitements
   2) les aspects physiques des SGBD en général sur lequel repose l’administration.
   Ces deux aspects doivent toujours être dissocié ce qui n’est pas le cas dans MySQL. En effet, MySQL mélange assez systématiquement le physique et le logique.
   À partir de là, cela conduit à des résultats faux.
   Par exemple si votre patron vous demande de trouver le meilleur vendeur pour le féliciter en lui donnant une prime et que vous utilisez LIMIT 1, alors vous risquez les pires ennuis. En effet, imaginons qu’il y ait deux vendeurs ex æquo. dans ce cas MySQL donnera l’un des deux au hasard et vous aurez foutu la zizanie dans l’entreprise. En tant que patron, je vous virerais immédiatement !
   C’est pourquoi un tel opérateur folklorique c’est pas relationnel. En revanche sont relationnel les opérateurs comme RANK(), DENSE_RANK() ou encore PERCENT_RANK() qui gèrent parfaitement les ex æquo.

   Le mélange physique / logique, c’est comme si pour conduire une voiture on était obligé de faire des travaux de mécanique en roulant. Auriez vous confiance dans une marque de voiture qui vous dirais de gonfler les pneus et de rajouter de l’huile en permanence alors que le véhicule est en marche ? Moi pas !

   La dissociation physique / logique a été voulue par le père des bases de données relationnel, justement parce que les systèmes précédents (bases hiérarchiques, bases en « réseau »…etc) ne donnait pas satisfaction tant sur le plan des performances que sur le plan des possibilités. Considérer cela en disant que c’est « mieux » est un retour en arrière lamentable et stupide qui prouve que l’ignorance de l’histoire de l’informatique conduit toujours à répéter les mêmes erreurs !

   Quand à la norme SQL, heureusement qu’elle existe… sans cela il aurait été quasiment impossible de porter des application de Oracle à MySQL par exemple… N’oubliez pas qu’elle est faite par les industriel et non pas par des savants dans leur tour d’ivoire ! Si MySQL veut imposer de nouveau opérateur, il suffit de le présenter au comité de normalisation qui l’étudiera, et si cela respecte les règles fondamentales, l’ajoutera. Sauf que MySQL est déjà très en retard sur l’application de la norme actuelle (il n’est même pas au niveau « entry » de la norme SQL 1 de 1986 !!!) Et les opérateur spécifique à MySQL ne sont là que pour masquer l’incompétence des développeurs de MySQL de se conformer au standard de l’industrie…
   Et quand j’entends dire par certains qu’il faut laisser tomber les normes, que les normes c’est pas bien, que la liberté c’est pas de norme du tout, je pisse de rire, car c’est tout le contraire. je vous invite à lire l’article que j’ai écrit à ce sujet. Vous y verrez que sans norme on retourne au moyen age ou chaque seigneur imposait ses mesures en les faisant payer fort chères histoire d’asservir un peu plus ses sujets… Vous y verrez aussi que l’absence de normes à tué de nombreuses personnes au cours des 18 et 19e siècles !

   A +

   Connectez-vous pour répondre ↓
8. -kiki- 12 juillet 2012 à 11 h 53 min

   après réflexion, votre version n’est peut-être pas moins performante…
   vous commencez à me faire douter^^

   par contre, avouez que ma solution est bien plus abordable pour un junior!
   (comment ça je me rattrape aux branches?

   Connectez-vous pour répondre ↓
9. -kiki- 12 juillet 2012 à 11 h 45 min

   ok ce n’est pas la cata, mais ça reste moins performant (table temporaire) et moins clair que la solution « crade »!
   non?

   Connectez-vous pour répondre ↓
10. cinephil 12 juillet 2012 à 11 h 37 min

    A mon avis, la bonne requête serait celle-ci :

    SELECT e.nom&nbsp;<br />
    FROM employe e&nbsp;<br />
    INNER JOIN&nbsp;<br />
    (&nbsp;<br />
    &nbsp;&nbsp;SELECT service&nbsp;<br />
    &nbsp;&nbsp;FROM employe&nbsp;<br />
    &nbsp;&nbsp;GROUP BY service&nbsp;<br />
    &nbsp;&nbsp;HAVING COUNT(*) = 1&nbsp;<br />
    ) tmp ON tmp.service = e.service

    Elle répond exactement au besoin : Sélectionne le nom des employés dont le service n’a qu’un employé.

    Connectez-vous pour répondre ↓
11. -kiki- 12 juillet 2012 à 11 h 29 min

    je comprend. c’est parce que votre esprit a été formé par la norme, et vous avez du mal à vous en détacher.

    personnellement j’ai une parfaite confiance en ce comportement.

    Dans ce cas, j’avoue que la requête est un peu stupide.
    Prenons l’idée inverse : je veux récupérer le nom des employés étant seuls dans leur groupe.

    à première vue, je ferais :
    SELECT nom
    FROM employe
    GROUP BY service
    HAVING COUNT(*) = 1;

    que feriez vous?
    Je pense que vous seriez obligé d’effectuer un tri sur « nom ».
    -s’il n’y a pas d’index sur « service,nom », bonjour le scan!
    -si vous créez l’index, c’est pas la cata mais les requêtes utilisant uniquement « service » seront légèrement plus lentes/gourmandes que si l’index n’était que sur « service ». Et les insertions seront plus lentes.

    Dans tous les cas, la solution crade de Mysql me semble plus performante. Et personnellement, je la trouve plus « logique » (elle traduit exactement ce qu’on veut. si vous ajoutez un tri, c’est une information « parasite »)
    non?

    ps: je n’essaye pas de me la jouer « Mr je sais tout », ni défendre à tout prix Mysql. Je crois vraiment que vous sous-estimez l’intérêt de certaines pratiques « crades ». Et je n’y voit aucun inconvénient (le problème du portage n’existe pas à mes yeux. j’ai peut-être tort, mais je l’ai expliqué un peu plus haut)

    Connectez-vous pour répondre ↓
12. cinephil 12 juillet 2012 à 10 h 08 min

    -> je pense que tu as envoyé 2 fois la requête d’insert des employés.

    Effectivement, je viens de vérifier et j’avais deux fois les données. Au temps pour moi !

    Il n’en reste pas moins que cette requête est stupide et je ne lui fait aucune confiance !

    Connectez-vous pour répondre ↓
13. -kiki- 12 juillet 2012 à 9 h 38 min

    andré 6
    fabien 4
    jean 8

    -> je pense que tu as envoyé 2 fois la requête d’insert des employés.

    andré 3
    fabien 2
    jean 4

    -> c’est tout à fait normal

    Connectez-vous pour répondre ↓
14. cinephil 11 juillet 2012 à 20 h 05 min

    Alors que signifie le résultat renvoyé par la requête ?
    nom nb_employe
    andré 6
    fabien 4
    jean 8

    Tiens ! En prime, je viens de refaire les mêmes requêtes que SQLPro sur mon ordi à la maison et voilà le résultat (sans le HAVING) :
    nom nb_employe
    andré 3
    fabien 2
    jean 4

    Ce n’est pas le même résultat !
    Même avec un tout peti jeu de données, ça foire !
    Tout juste peut-on dire que cette fois la requête a donné le nombre d’employés des services des personnes citées mais la première fois cela n’avait pas été le cas !

    Connectez-vous pour répondre ↓
15. -kiki- 11 juillet 2012 à 17 h 49 min

    si! la norme l’interdit lorsque l’on se trouve « Ã  l’intérieur d’un groupe » (il est interdit de demander dans le SELECT une colonne qui n’est pas présente dans le GROUP BY et qui n’est pas agrégée).

    c’est justement le sujet : vous criez au scandale quand Mysql récupère le premier élément d’un groupe. (ce qui est hors norme, mais parfaitement logique à mon sens)

    Et vous faites bien d’en parlez : vous trouvez normal de récupérer le premier élément d’une table, même si l’on ne spécifie pas d’ordre de tri!
    ->Pourquoi serait-ce différent dans un groupe?

    Et non, les résultats ne sont pas faux! c’est votre interprétation qui est fausse! :p

    Connectez-vous pour répondre ↓
16. cinephil 11 juillet 2012 à 17 h 25 min

    Mais la norme n’interdit pas, je pense, de ne récupérer qu’une seule ligne de la table. ROW_NUMBER ne serait-il pas là pour ça ?

    Chez MySQL il y a LIMIT qui n’est pas standard SQL et je pense qu’il y a des équivalents dans les autres SGBDR.

    Cependant, le propos ici était de dire ce que j’ai dit dans mon précédent message : MySQL permet des choses qui peuvent entraîner des résultats faux ou incohérents ou sujets à mauvaise interprétation par l’utilisateur à qui sont présentées les données. L’exemple du GROUP BY est le plus évident.

    Connectez-vous pour répondre ↓
17. -kiki- 11 juillet 2012 à 16 h 28 min

    je viens de vous relire, et vous viez raison : nous n’avons pas la même notion de l’ordre.

    pour moi, votre 2ème série a bien un ordre!
    à l’instant T : 5 est le premier élément, 1 est le 2eme… etc
    cet ordre peut changer, mais il existe.
    c’est pourquoi je peux demander « le premier élément qui vient ».
    ce sera probablement 5 puisque vous ne pouvez éditer votre commentaire, mais je ne peux pas en être sur (= je ne peux me fier à l’ordre).

    si j’avais suivi la norme, je n’aurai pas pu demander « le premier élément qui vient ». J’aurais été contraint de d’abord définir un ordre de tri. une opération potentiellement coûteuse et parfaitement inutile dans mon cas!

    Connectez-vous pour répondre ↓
18. -kiki- 11 juillet 2012 à 15 h 54 min

    je crois qu’on a bien la même définition de l’ordre.
    mais l’idée n’est pas de si « fier » à l’ordre (qui est changeant), mais savoir qu’il existe, et donc de savoir qu’on PEUT récupérer « le premier élément qui vient » (ou « concaténer tous les éléments ») sans expliciter un ordre.

    si on veut récupérer « un des éléments du groupe », peu importe lequel.
    si l’on respecte la norme, on doit forcément expliciter quel élément récupérer (ex : MIN, MAX…).
    à mes yeux, ce sera un traitement superfux! (et de plus, bonjour la maintenance! car la requête ne traduit pas exactement ce que l’on veut récupérer…)
    je préfère la version « crade » qui sera plus performante et plus compréhensible!

    de même, si l’on veut récupérer « la liste des éléments du groupe », peu importe leur ordre :
    si l’on respecte la théorie enssembliste, on est obligé de spécifier un ordre. C’est encore un traitement superflux (et encore un truc qui embrouillera l’esprit de celui qui reprendra notre code)

    ca peut paraitre anodin, mais sur de grosses tables, et sur des colonnes non indexées, ce genre de « détails » peut être significatif! (tout de moins, je le crois. je n’ai jamais fait de test, mais ça me semble évident)

    Connectez-vous pour répondre ↓
19. cinephil 11 juillet 2012 à 14 h 17 min

    On ne doit pas avoir la même définition du mot « ordre » !

    1 2 3 4 5 6 7 8 9 10 => Ces nombres sont dans l’ordre ascendant.
    5 1 3 8 9 4 7 10 2 => Il n’y a plus d’ordre logique dans cette suite de nombre, je les ai tapés de manière aléatoire.

    Lancer plusieurs fois un SELECT sans ORDER BY et espérer que les données seront affichées toujours dans le même ordre est un leurre. Et croire que le résultat affiché est forcément dans l’ordre où ont été saisies les lignes est une erreur d’interprétation du résultat.

    Faire un GROUP BY permis par MySQL mais incorrect du point de vue de la norme est un autre leurre qui peut conduire à des erreurs de résultat ou à de mauvaise interprétation des résultats affichés.
    Croire que le nom renvoyé pour chaque service à l’aide du GROUP BY dans la requête donnée plus haut est également une interprétation qui peut être fausse. Elle est vraie dans le cas minuscule qu’on a exposé ici mais c’est à considérer comme une coïncidence que comme une vérité.
    Le résultat affiché par la requête n’a aucune signification et en tout cas ne répond pas à ce qu’est censé faire la requête. On ne peut même pas en conclure que le service auquel appartient André comporte 6 personnes puisque les données sources montrent dévidence que c’est faux !

    Connectez-vous pour répondre ↓
20. -kiki- 11 juillet 2012 à 12 h 00 min

    cinephil/strong> : Le seul moyen d’avoir un ordre de fiable…

    je n’avais pas vu mais voilà un beau lapsus!
    vous êtes donc d’accord : il y a bien un ordre, mais on ne peut s’y fier.

    cependant, ne pas s’y fier ne veut pas dire « ne pas prendre en compte cet état de fait ».

    sqlpro nous dira que GROUP_CONCAT est une abbération car celà suppose un ordre.

    de mon côté je suis content que les développeurs de Mysql soient plus ouverts et acceptent de prendre en compte la notion d’ordre pour créer de telles fonctions! (peut-être crades à vos yeux, mais tellement pratiques!)
    

    Connectez-vous pour répondre ↓
21. -kiki- 11 juillet 2012 à 11 h 48 min

    soit vous faites l’anguille pour essayer d’avoir raison, soit vous ne m’avez pas compris :

    ok, si l’on supprime une ligne en milieu de table et qu’on en insère une autre (sans avoir défragmenté la table), la nouvelle ligne viendra combler le « trou ».

    celà ne contredit en rien mes dires : l’ordre a changé, mais il y a bien une notion d’ordre.

    je n’ai jamais dit que l’ordre était constant, qu’on pouvait s’y fier etc…
    j’ai simplement dit que l’ordre existe.

    Connectez-vous pour répondre ↓
22. cinephil 11 juillet 2012 à 11 h 33 min

    Tant qu’on stocke les données dans les système informatisés actuels, il y aura bien un ordre!
    Eh non !

    En base de données, la ligne contenant le nom de ‘toto’ et qui vous est présentée à l’issue d’une requête sans ORDER BY juste avant la ligne contenant le nom de ‘titi’ peut très bien se trouver à un endroit tout à fiat différent sur le disque du serveur, voire même sur un autre disque !

    Les données d’une table ne sont pas forcément enregistrées physiquement les unes à la suite des autres et le jeu des suppressions, modifications et insertions de lignes peut changer complètement l’ordre apparent des lignes.

    Le seul « ordre naturel » qu’on peut avoir dans une table, c’est si celle-ci est munie d’une clé primaire auto-incrémentée et que vous enregistrez les données de manière chronologique. La ligne 25 enregistrée le 5 juillet 2012 précédera bien la ligne 34 enregistrée le 10 juillet 2012 si vous faites une requête avec ORDER BY id.
    À condition toutefois qu’un gugus n’aie pas eu l’idée saugrenue de « boucher les trous » dans les id après suppression de lignes !

    Bien que ce soit présenté à peu près de la même manière sur les interfaces graphiques, une table de base de données n’est pas une feuille de tableur dans laquelle on écrit sur la ligne 1 puis sur la ligne 2… Si vous avez une masse de données à saisir et que plusieurs personnes s’y mettent, Alain peut saisir les données de juin en même temps que Bernard saisira les données de Juillet et l’ordre des identifiants ne sera plus l’ordre chronologique des données.

    Le seul moyen d’avoir un ordre de fiable est de l’enregistrer spécifiquement et de requêter avec la clause ORDER BY adéquate.

    Renseignez-vous sur la manière dont sont enregistrées et récupérées les données dans les SGBDR et vous comprendrez qu’il n’y a pas d’ordre a priori dans une table SQL.

    Connectez-vous pour répondre ↓
23. -kiki- 11 juillet 2012 à 11 h 08 min

    sqlpro : La encore je reste sidéré de l’inculture crasse des soit_disant informaticien…

    c’est assez insultant et totalement infondé!
    il me semble que c’est vous qui êtes prisonnier de la norme :

    biensûr qu’il n’y a pas de notion d’ordre dans la théorie enssembliste! mais comme je le disait, la réalité dépend du système de stockage. Tant qu’on stocke les données dans les système informatisés actuels, il y aura bien un ordre!

    refuser d’admettre ce genre de choses (et donc suivre de manière bornée la norme), c’est se priver d’une partie des possibilités qui s’offrent à nous, et surtout risquer de bloquer sur certaines (soit-disantes) « incohérences », ce qui est apparemment arrivé à cinephil.
    biensûr que je suis prisonnier du système, mais le jour où une appli aura vraiment besoin de changer de système, les besoins auront tellement changé que l’appli sera recodée de A à Z.
    (donc toutes les manipulations de données un peu « crade » n’auront aucune incidence. il suffit que le modèle de donnée soit cohérent pour ne pas perdre de temps en migration de données)

    Connectez-vous pour répondre ↓
24. ok.Idriss 10 juillet 2012 à 22 h 42 min

    J’aurais voulu rajouter quelque chose à mon propos pour qu’on soit bien clair : il y a une notion d’ordre mais celle-ci n’est pas forcemment cohérente et il faut s’en abstraire le plus possible.

    Connectez-vous pour répondre ↓
25. ok.Idriss 10 juillet 2012 à 22 h 37 min

    « Le fait de retourner la première ligne n’a aucun sens puisque par principe dans un SGBDR il n’y a pas d’ordre« 

    Je mesurerait ces propos : ça c’est plutôt l’aspect théorique qu’on a essayé d’implanter dans les différents SGBDR plus ou moins bien.

    Concernant la notion d’ordre on voit bien qu’elle est omni-présente dans beaucoup de SGBDR dont Oracle, PostgreSQL et MySQL (je ne me prononcerait pas pour les autres mais j’aurais tendance à croire qu’il en est de même).

    On le voit notamment avec les clauses LIMIT sur MySQL et PostgreSQL, les rowid/rownum sur Oracle, … et je dois avouer que c’est souvent bien utile (pas forcemment au niveau de l’application elle même mais quand on investigue sur des anomalies, ce genre de choses).

    Pareillement, la notion d’unicité des tuples qui fait partie intégrante de la théorie relationnelle … on est bien obligé de rajouter des contraintes, l’unicité n’est naturelle.

    Quelque soit le support de stockage (fichier, mémoire partagée, etc), ça n’y change rien, on a une couche d’abstraction qui essaye de nous faire croire au relationnel. On aurait pu implémenter la manière de manipuler les données de façons différentes sur les mêmes supports …

    Là ou je suis parfaitement d’accord c’est sur l’importance capitale de normaliser la chose et de respecter la norme quelle qu’elle soit.

    Connectez-vous pour répondre ↓
26. sqlpro Auteur de l’article10 juillet 2012 à 18 h 09 min

    kiki : Ces deux derniers exemples ne révèlent pas (à mon sens) un vrai problème, mais une « phylosophie » différente :
    un SGBD qui essaye de résoudre notre demande bien qu’elle ne respecte pas la norme, a de gros avantages en regard d’une appli qui refuse toute entorse.

    Vous avez raison, revenons aux temps féodaux ou aucune norme aucun standard n’existait et il fallait acheter auprès du seigneur local ses poids et mesure pour commercer. Loi d’être une liberté, l’absence de norme et de standard empêche tout portage. Vous êtes donc prisonnier du système !!!
    Lisez ceci : http://blog.developpez.com/sqlpro/p9950/ms-sql-server/merci-de-respecter-les-normes/

    kiki : GROUP BY / HAVING
    le résultat dépend du système de stockage (informatique), mais reste logique : la première ligne enregistrée est la première à être lue. Donc il n’y a pas de hasard dans ce résultat.

    La encore je reste sidéré de l’inculture crasse des soit_disant informaticien… Un SGDB relationnel repose sur la théorie des ensemble pour lequel toute notion d’ordre est bannie de prime abord. C’est ce qui en fait son intérêt car il est capable de faire des opérations ensembliste qui portent SIMULTANÉMENT sur plusieurs lignes.
    Le fait de retourner la première ligne n’a aucun sens puisque par principe dans un SGBDR il n’y a pas d’ordre !!!
    Autrement dit, MySQL gère des « fichiers » ligne à ligne et non des tables…
    Rien donc à voir avec un SGBDR….
    lisez ceci : http://blog.developpez.com/sqlpro/p5867/langage-sql-norme/les-donnees-d-une-base-sql-sont-des-ense/

    Connectez-vous pour répondre ↓
27. -kiki- 10 juillet 2012 à 11 h 35 min

    Mysql n’est pas le bon sgbd pour une appli sensible. Mais Ca n’en fait pas un mauvais sgbd pour autant!
    Si on choisit un CMS pour faire du eCommerce, il y aura tôt ou tard des problèmes.
    Si on choisit Mysql pour gérer les transactions de la bourse de Paris… idem!

    Il faut simplement savoir quel outil utiliser dans quel cas!

    Je suis peut être dans un autre monde, mais pour moi la permissivité est un gage de flexibilité, de robustesse et de rapidité de codage (au détriment de la cohérence).
    Certes, les incohérences génèrent parfois des bugs qu’il faut corriger. Mais il faut aussi prendre en compte :
    – les imprévus : toutes les applis et bdd tierces utilisées peuvent changer légèrement. Ou simplement, un cas spécifique qui n’a pas été prévu arrive désormais fréquemment. Et là, un code non permissif peut retourner des erreurs et necessiter des modifs. Et dans ce cas, une partie de l’appli cesse de fonctionner… (un code permissif pourra continuer à fonctionner!)
    – l’évolution de la demande : la permissivité de Mysql permet tout une tas de combines (plus crades les unes que les autres je vous l’accorde) pour modifier les fonctionnalité existantes en un temps record (ou greffer des fonctionnalités sur d’autres). Pour caricaturer : avec vos sgbd trop rigides, le temps que vous repreniez le code, la demande aura encore changé! :p

    Et pour ce qui est des problèmes de cohérence, tout est question d’équilibre :
    -si une partie de l’appli est sensible, on prendra plus de temps pour faire des contrôles côté appli. Ce n’est pas abbérant (tant que la proportion de données sensible reste faible).
    -pour le reste, un minimum de rigueur personnelle permet d’éviter les « grosses bêtises ».

    Connectez-vous pour répondre ↓
28. cinephil 9 juillet 2012 à 22 h 48 min

    Ce que l’on reproche, c’est que MySQL permet de faire de grosses bêtises sans s’en apercevoir… jusqu’au jour où on trouve un résultat incohérent et qu’on ne sait pas pourquoi. Il faut alors des heures de recherche personnelle, puis des heures ou des jours d’attentes dans une discussion sur developpez.com… puis des heures, des jours ou des semaines à reprendre le code de l’application… et se dire que ce @#!?~ de SGBD n’aurait jamais du permettre une telle situation et qu’à l’avenir on ne m’y reprendra plus… tout en priant pour qu’une ou plusieurs applications déjà livrées aux clients ne soient pas dans le même état, en regardant son téléphone d’un oeil inquiet.

    Connectez-vous pour répondre ↓
29. -kiki- 9 juillet 2012 à 18 h 26 min

    Ces deux derniers exemples ne révèlent pas (à mon sens) un vrai problème, mais une « phylosophie » différente :

    un SGBD qui essaye de résoudre notre demande bien qu’elle ne respecte pas la norme, a de gros avantages en regard d’une appli qui refuse toute entorse.
    le problème c’est que pour éviter toute déconvenue, celà necessite une bonne connaissance du comportement de l’outil.

    GROUP BY / HAVING
    le résultat dépend du système de stockage (informatique), mais reste logique : la première ligne enregistrée est la première à être lue. Donc il n’y a pas de hasard dans ce résultat.

    SUM
    la conversion de string en int est tout à fait classique (la conversion s’arrète au premier caractère inconvertible). Donc le résultat est logique.

    là le problème ne vient pas de Mysql mais des CMS :
    ils ne sont effectivement pas fait pour du commerce. je présume qu’il n’y a pas de transaction? qu’il manque plein d’index et que d’autres sont en doublon? que les formes normales ne sont pas respectées et que le modèle de données est mal pensé? et biensur, que les requêtes foireuses foisonnent?
    Mysql n’y est pour rien!

    Connectez-vous pour répondre ↓
30. cinephil 6 juillet 2012 à 1 h 16 min

    Ça fait aussi tout drôle quand on se rend compte que le résultat affiché dans son appli n’est pas celui qu’on attendait !

    Connectez-vous pour répondre ↓
31. ok.Idriss 5 juillet 2012 à 17 h 50 min

    +1 CinePhil, même sans having cela doit générer une erreur (à partir du moment un toute les colonnes sélectionnées ne sont pas présente dans la clause GROUP BY). L’inverse n’étant pas vrai (on peux grouper en priorité sur des colonnes qui ne sont pas sélectionnées).

    Je pense qu’une telle requête sous MySQL, revient à faire cela :

    SELECT nom, COUNT(*) AS nb_employe
    FROM employe
    GROUP BY service, nom
    HAVING COUNT(*) > 2;

    Après c’est sûr qu’il faut savoir ce que l’on fait … et l’absence de messages d’erreurs ne nous aide pas.

    Bref, ce laxisme est un des plus connus sur MySQL car il donne de mauvaises habitudes aux jeunes développeurs qui débutent avec ce type de clauses (ça a été aussi mon cas autrefois et ça m’a fait tout drôle lorsque j’ai changé de SGBDR :aie: ).

    Connectez-vous pour répondre ↓
32. cinephil 5 juillet 2012 à 16 h 58 min

    Celle là est connue depuis belle lurette et discutée dans nos forums à tire-larigot !
    Car je ne pense pas que ce soit à cause du HAVING que ce produit ce phénomène mais tout simplement parce qu’on demande le nom alors qu’on groupe par service.

    Sans le HAVING, voici le résultat :
    nom nb_employe
    andré 6
    fabien 4
    jean 8

    Tout aussi incohérent, puisque la requête est incohérente !

    Ça me rappelle ce bon Professeur Genthon, lors de mon cursus au CNAM de Toulouse, qui nous fit réviser les tables de vérité des opérations logiques dans ses cours d’intelligence artificielle.
    p => q est vrai si p est faux quel que soit q. Autrement dit, à partir du faux, tout est vrai !

    Connectez-vous pour répondre ↓
33. sqlpro Auteur de l’article5 juillet 2012 à 15 h 52 min

    nouveau bug sur le GROUP BY / HAVING…

    Exemple :

    
    CREATE TABLE employe&nbsp;<br />
    
    (nom     VARCHAR(16),&nbsp;<br />
    
    &nbsp;service VARCHAR(16));&nbsp;<br />
    
    &nbsp;<br />
    
    INSERT INTO employe&nbsp;<br />
    
    VALUES ('jean',   'vente'),&nbsp;<br />
    
    &nbsp;      ('marc',   'vente'),&nbsp;<br />
    
    &nbsp;      ('line',   'vente'),&nbsp;<br />
    
    &nbsp;      ('paul',   'vente'),&nbsp;<br />
    
    &nbsp;      ('andré',  'achat'),&nbsp;<br />
    
    &nbsp;      ('louis',  'achat'),&nbsp;<br />
    
    &nbsp;      ('jules',  'achat'),&nbsp;<br />
    
    &nbsp;      ('fabien', 'compta'),&nbsp;<br />
    
    &nbsp;      ('marcel', 'compta');&nbsp;<br />
    
    &nbsp;<br />
    
    SELECT nom, COUNT(*) AS nb_employe &nbsp;<br />
    
    FROM   employe  &nbsp;<br />
    
    GROUP  BY service  &nbsp;<br />
    
    HAVING COUNT(*) &gt; 2;
    
    

    Cette requête fournit la réponse suivante sous MySQL :

    
    nom     nb_employe&nbsp;<br />
    
    ------- -------------&nbsp;<br />
    
    andré   3&nbsp;<br />
    
    jean    4
    
    

    On se demande pourquoi il est allé cherché andré et pas louis ou jules et jean au lieu de marc, line ou paul !!!
    Mais comment faire autrement ? En effet, cette requête est illégale dans le langage SQL…. On ne peut pas avoir simultanément un agrégat et le détail… il faut choisir ou bien utiliser une fonction de fenêtrage qui rend indépendant le calcul de l’agrégat (mais ces fonctions de fenêtrage présentes dans le langage SQL depuis la version de 1999, ne sont toujours pas implémentées dans mySQL !)
    Donc, MySQL sélectionne n’importe quoi, au lieu de retourner une erreur… c’est tellement plus pratique !
    Bref, quand je vous disait que MySQL pollue vos bases de données, il suffit d’imaginer un jeune développeur qui fait des mise à jour de vos données en imbriquant une telle sous requête dans l’update….

    Voici ce que donne cette requête avec les autres SGBDR :

    sur MS SQL Server :

    Msg*8120, Niveau*16, État*1, Ligne*1
    La colonne ‘employe.nom’ n’est pas valide dans la liste de sélection parce qu’elle n’est pas contenue dans une fonction d’agrégation ou dans la clause GROUP BY.

    sur PostGreSQL :

    ERREUR: la colonne « employe.nom » doit apparaître dans la clause GROUP BY ou doit être utilisé dans une fonction d’agrégat
    LINE 1: SELECT nom, COUNT(*) AS nb_employe
    ^
    ********** Erreur **********
    État SQL :42803
    Caractère : 8

    Même topo sous Oracle…

    Connectez-vous pour répondre ↓
34. cinephil 30 juin 2012 à 12 h 09 min

    J’ai l’impression que c’est vrai pour la plupart des CMS et autres outils du même genre. Les modèles de Drupal et de Moodle, ne sont vraiment pas top !

    La cause est sans doute que tous ces outils open source sont « conçus » par des développeurs qui pensent avant tout logiciel avant de penser architecture de données, alors que ce sont pourtant des outis de manipulation de données.

    Dans un autre genre d’outils, le modèle de Jira est un peu mieux mais il persiste des choses génantes, probablement dues à la même cause. Par exemple, la valeur enregistrée pour un champ d’options (cases à cocher, liste de choix…) est la référence de l’option qui est numérique mais elle est stockée dans une colonne VARCHAR alors qu’il existe une colonne numérique pour stocker des valeurs.

    Connectez-vous pour répondre ↓
35. sqlpro Auteur de l’article28 juin 2012 à 12 h 04 min

    Et oui, c’est bien le drame !!! Je me suis livré récemment à l’étude des modèles d’applications spécifiques à MySQL du genre Joomla, Prestathsop ou SPIP pour l’un de mes clients…. et c’est dramatique de voir ce genre d’erreur dedans…
    Du coup, les données exploitées sont corrompues !

    Connectez-vous pour répondre ↓
36. cinephil 27 juin 2012 à 9 h 27 min

    D’accord pour dire que ces comportements de MySQL sont, une fois de plus, inacceptable mais reconnaît que ton exemple avec des montants de débit et crédit en livre comtpable sous format texte est tiré par les cheveux !

    Cependant, on trouve ce genre de perle dans certains messages de nos chers forumeurs MySQLiens !

    Connectez-vous pour répondre ↓
37. sqlpro Auteur de l’article26 juin 2012 à 17 h 57 min

    Autre bug époustouflant, MySQL ne génère pas d’erreur sur certaines requêtes pourtant totalement erronées sur le plan des calculs…

    Attention, c’est du lourd !

    Soit la table suivante :

    
    CREATE TABLE T_LIVRE_COMPTABLE_LVC&nbsp;<br />
    
    (LVC_ID          INT PRIMARY KEY,&nbsp;<br />
    
    &nbsp;LVC_RUBRIQUE    VARCHAR(32) NOT NULL,&nbsp;<br />
    
    &nbsp;LVC_DEBIT       VARCHAR(16),&nbsp;<br />
    
    &nbsp;LVC_CREDIT      VARCHAR(16))
    
    

    Avec les données ci dessous :

    
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (1, 'VENTE', NULL, '123,45');&nbsp;<br />
    
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (2, 'ACHAT', '456,789', NULL);&nbsp;<br />
    
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (3, 'VENTE', '50,00', '2 222,99');
    
    
    
    

    
    La requête suivante : &nbsp;<br />
    
    SELECT SUM(LVC_CREDIT) - SUM(LVC_DEBIT) AS SOLDE, &nbsp;<br />
    
    &nbsp;      LVC_RUBRIQUE&nbsp;<br />
    
    FROM   T_LIVRE_COMPTABLE_LVC;
    
    

    Passe allègrement sur MySQL alors qu’elle est farcie d’erreurs :
    1) absence de GROUP BY
    2) SUM sur des données de type chaine de caractères
    Et le plus étonnant c’est qu’elle donne un résultat :

    
    SOLDE      LVC_RUBRIQUE&nbsp;<br />
    
    ---------- ------------------&nbsp;<br />
    
    -381,      VENTE
    
    
    
    

    Par pur plaisir sado-masochiste, rajoutons une ligne :

    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (4, 'ZIG', '100,00', '1 000,00');

    Notre requête :

    
    SELECT SUM(LVC_CREDIT) - SUM(LVC_DEBIT) AS SOLDE, &nbsp;<br />
    
    &nbsp;      LVC_RUBRIQUE&nbsp;<br />
    
    FROM   T_LIVRE_COMPTABLE_LVC;
    
    

    Donne une nouvelle réponse tout aussi foireuse :

    
    SOLDE      LVC_RUBRIQUE&nbsp;<br />
    
    ---------- ------------------&nbsp;<br />
    
    -480,      VENTE
    
    

    Je n’ose à peine imaginer ce que donne MySQL dans une application de site web marchand ou dans laquelle il y a de la gestion chiffrée !

    Connectez-vous pour répondre ↓
38. sqlpro Auteur de l’article22 juin 2012 à 15 h 39 min

    svaroqui : … principe de base érigé au démarrage de MySQL : elles ne sont que des storage engines au final…
    Finalement vous me rassurez et me confortez dans mon idée que MySQL n’est pas un SGBD Relationnel. Il aurait été plus honnête de le dire dès le départ plutôt que de tenter de comparer cet ersatz aux vrais SGBD relationnels que sont Oracle, SQL Server ou encore PostGreSQL.

    Mais ce qui est particulièrement mauvais dans MySQL est le nombre incroyable de bugs de toutes sortes dont certains ne sont jamais corrigés de versions en versions. Dernière découverte en date dans la partie SIG :

    Soit deux objets géométriques, un polygone et un point… Le point étant situé à l’extérieur du polygone.
    « 
    MySQL le voit à l’intérieur !!! Démonstration :

    
    SET @mpoly = GeomFromText('POLYGON((1 1, 1 5, 3 5, 1 1))');&nbsp;<br />
    
    SET @pnt = GeomFromText('POINT(2 2)');&nbsp;<br />
    
    SELECT Contains(@mpoly, @pnt) AS INTERSECTE;&nbsp;<br />
    
    &nbsp;<br />
    
    INSERTSECTE&nbsp;<br />
    
    --------------&nbsp;<br />
    
    1
    
    

    Surprenant !!!!!

    À lire : http://www.developpez.net/forums/d1230091/bases-donnees/mysql/requetes/probleme-mbrccontains/#post6725777

    A +

    Connectez-vous pour répondre ↓
39. ok.Idriss 4 juin 2012 à 15 h 14 min

    Bonjour.

    Me concernant, je ne suis pas anti-MySQL. Ce qui me gênait c’était principalement le non respect des contraintes d’intégrités référentielles avec MyIsam et je trouvait aussi qu’il était un peu dommage qu’elle ait le monopole sur les SGBDR « libres ». Par exemple, ça m’attriste de voir que de moins en moins d’hébergeurs proposent une alternative comme PostgreSQL sur des hébergements mutualisés bon marchés ou gratuits, voire d’autres projets libres comme Cassandra.

    Après, MySQL je l’utilise régulièrement (ainsi qu’Oracle et Postgre) et j’ai apprécié certains efforts qui ont été fait notamment sur le moteur InnoDB (pour le respect des contraintes, l’ajout d’un langage proche du PL/SQL, et pour l’aspect transactionnel, les reprises sur panne, etc). Et là dessus, je ne vais pas me plaindre qu’un projet libre, gratuit et suffisamment fonctionnel soit moins performant qu’un gros SGBDR commercial (et très coûteux) sur certains aspects. MySQL, c’est libre et gratuit, ça marche et c’est rapide, c’est indéniable. D’ailleurs DVP fonctionne très bien avec . Après, c’est toujours bon de se prendre quelques critiques pour progresser …

    Cordialement,
    Idriss

    Connectez-vous pour répondre ↓
40. svaroqui 4 juin 2012 à 13 h 27 min

    Bonjour,

    Je travail pour MySQL et MariaDB depuis des années, je trouve de nombreux commentaires vraiment insultant pour tout les développeurs open source en général. Un peu d’humilité car tous les ingénieurs de MySQL on une grande expérience des SGBD commerciaux ayant tous au moins travaillé chez l’un ou voir plusieurs d’entre eux.(J’en connait qui travail aussi sur le code de PG). La plupart des algorithmes partent de solutions existantes implémentées dans d’autre SGBDR avec parfois quelques innovations et quelques abandons liés a l’évolution des OS et une architecture plutôt orienté WEB que client/serveur. MySQL et bien le seul framework de base de donnée avec beaucoup de plugabilité: C’est sa force et sa faiblesse car la critique est facile lorsque l’on juge un moteur ou un autre qui permette des caractéristiques vraiment différentes voir non transactionnelles.

    Ce que je comprend en lisant se post c’est pourquoi il n’y pas plus en France de société comme Facebook ou Google. Car le SGBD poudre yeux a permis a la plupart des sites l’utilisant de se positionner dans le top 1000, certains même jusqu’à posséder leur propre équipes de dev MySQL comme Facebook , Booking , Twitter, LinkedIn.

    On se raccroche au fait que certains d’entre eux utilisent maintenant d’autres technologies, mais ces nouvelles technos sont toutes issues du principe de base érigé au démarrage de MySQL : elles ne sont que des storage engines au final. Deplus la plupart des NoSQL, graph databases ont été lancé autour des défauts de MySQL et d’autres SGBD plus précisément la réplication et le partitionnement : Memcache ayant lancer le mouvement.

    Ces batailles du passé sur les foreign key pour chaque tuple insérée en base, le SGBD devrait a faire une recherche de clef pour toutes les dépendances pour vérifier a chaque écriture que le programmeur n’a pas fait une erreur, dans ma logique j’appelle cela un virus. Mais pour Info InnoDB PBXT , TokuDB support les FKs.

    Pour les contraintes sur les champs en effet MySQL par défaut est plutôt laxiste ( quel developeur lui jettera la pierre:) mais sont comportement peu être changer via une variable sql_mode

    InnoDB scale jusqu’a 64 Cores et ne cesse de progresser avec les évolutions hardware
    MariaDB et MySQL( payant) possèdent un thread pool
    InfiniDB et Infobright sont des moteurs en colonnes a la Teradata mais plutôt Vertica ou IQ c’est quand meme une meilleure approche que l’hybridation

    MariaDB possède le support strict sur la norme SQL et GIS

    Bref on ne fait pas rien nous travaillons toujours avec nos moyens et ils sont en plaines progressions avec l’apport des acteurs du WWW qui désormais participe aussi au développement

    Connectez-vous pour répondre ↓
41. cinephil 3 mai 2012 à 9 h 17 min

    Allez, encore une déficience de MySQL qui n’autorise pas les sous-requêtes dans les vues !

    http://www.developpez.net/forums/d1215854/bases-donnees/mysql/requetes/methode-sous-requete-from-clause/

    En tous cas jusqu’à la version 5.0.17 utilisée par ce forumeur.

    Connectez-vous pour répondre ↓
42. sqlpro Auteur de l’article24 avril 2012 à 13 h 41 min

    Malheureusement mon quotidien est fait de conseil sur des installation de gros serveurs (plusieurs TO) avec des config SAN et RAM déficientes.
    A partir d’un certain volume il faut savoir revenir aux fondamentaux et savoir ce qu’une organisation disque, même en SAN veut dire…

    Enfin, UNIX et sa famille (LINUX, AIX…) est plus complexe administration que Windows et cela se ressent fortement aujourd’hui sur les coût d’admin.

    A +

    Connectez-vous pour répondre ↓
43. haliway 17 avril 2012 à 12 h 23 min

    Ce que je reproche à MySQL est simple : faire croire qu’il s’agit d’un SGBD Relationnel, alors que cela n’est pas vrai. C’est une simple encapsulation de SQL sur de la gestion de données en fichiers…

    Bonjour,
    je viens de tomber sur votre blog au demeurant assez intéressant par contre laissez moi mettre en doute vos capacités système (je ne remets pas en doute vos capacités SGBD et j’ai rien à dire à ce niveau la). Je suis moi même ingénieur système Unix (AIX, Linux, Solaris …) et cette petite phrase ainsi que certaines autres m’ont fait tilté assez rapidement. Depuis quand une base de données peut s’affranchir des caractéristiques système ?
    1) Je vous invite à installer Oracle sur un système Unix et voir si le paramétrage des limites n’est pas un prérequis premièrement.

    2) Vous qui dites que le SGBD fait sa tambouille avec la RAM… c’est complètement faux. Le système de page replacement est géré par l’OS quelque soit les affirmations que vous pouvez décrire. C’est d’ailleurs bien pour cela que de nombreuses entreprises, par exemple, ont été obligées de faire des revues de tuning sur les AIX 5.3 avec bases de données installées dont les options sur les permanent pages n’avaient pas été configurées correctement (min_perm, max_perm, lru_file_repage) http://www.ibm.com/developerworks/aix/library/au-vmm/.

    3) C’est l’OS qui gère les PGIN/PGOUT sur la RAM et la SWAP en gèrant les priorités (définies ou pas par des options de configuration).

    4) Concernant le SAN, sur la plupart des baies, le volume n’est pas défini avec un emplacement spécifique sur le disque comme vous souhaitez le préconiser (on faisait ça il y a 10 ans mais vu la complexité d’administration…). De toute façon, une architecture rapide est une architecture tout en un (serveur + disques) car on évite la latence des liens fibre channel en passant par des bus PCI Express (Oracle Exadata ou IBM Netezza)… On revient finalement à une architecture compacte la ou on a passé 20 ans à passer par le SAN prétextant qu’il apporterait une souplesse dans la gestion du stockage.

    Il ne faut pas raconter n’importe quoi sous prétexte de faire du SGBD depuis 10 ans. Je fais moi même du système depuis presque 10 ans.

    Connectez-vous pour répondre ↓
44. cinephil 17 février 2012 à 9 h 24 min

    Je viens de recevoir la newsletter de MySQL qui donne un lien vers un article indiquant que la recherche full text sera possible en InnoDB dans MySQL 5.6.
    http://drdobbs.com/database/231902587

    Il n’y aura donc plus de raison d’utiliser le moteur MyISAM !

    Si par contre c’est un simple portage de la recherche full text de MyISAM vers InnoDB, ce ne sera guère mieux mais bon… Oracle semble vouloir faire évoluer MySQL dans le bon sens quand même !

    Connectez-vous pour répondre ↓
45. cinephil 19 novembre 2011 à 9 h 33 min

    Je viens de lire une perle dans la doc de MySQL sur les types date et heure :

    A noter que MySQL vous permet d’enregistrer certaines dates qui ne sont pas strictement légales, par exemple 1999-11-31. La raison est que nous pensons que la vérification des dates est à faire niveau application.

    De plus, on lit aussi ce qui suit dans la partie sur le type TIME :

    Vous pouvez spécifier une valeur de type TIME avec différents formats :

    *

    Une chaîne au format ‘D HH:MM:SS.fraction’. (Notez que MySQL ne stockera pas la fraction d’une valeur TIME.)

    Pourtant, dans la section sur les fonctions de date et heure, on trouve la notion de MICROSECOND mais je n’ai pas trouvé comment enregistrer ces microsecondes !

    Une lecture rapide de la doc Postgresql semble montrer une plus grande rigueur quant à l’interprétation des dates et on peut sans problème saisir des fractions de secondes (je n’ai pas testé).

    Connectez-vous pour répondre ↓
46. sqlpro Auteur de l’article2 octobre 2011 à 18 h 26 min

    C’est effectivement une anomalie gênante… Mais la gestion de la sécurité sous MySQL est une véritable passoire… C’est aussi lié au fait que les tables génèrent de multiples fichiers que n’importe qui peut « voler » sur le serveur…. !
    Hélas PostGreSQL est du même tonneau en cette matière !

    Connectez-vous pour répondre ↓
47. cinephil 28 septembre 2011 à 10 h 14 min

    Je viens d’être confronté à ce que je considère une nouvelle « anormalité » de MySQL, en tout cas un truc gênant !

    J’ai créé une BDD sur ma machine avec l’utilisateur root de MySQL sans problème, y compris un petit trigger d’incrémentation relative dont j’ai d’ailleurs donné le code dans mon blog.

    Je fais un dump de la BDD pour la transférer sur le serveur qui contient bien mon trigger et j’essaie d’importer ce dump sur la BDD du serveur, cette fois avec l’utilisateur MySQL qui sera celui de l’application cliente, cet utilisateur ayant les droits ALL PRIVILEGES sur la BDD.
    Et là, message d’erreur ! La création du trigger est refusée car il faut les droits SUPER pour le faire !

    Est-ce à considérer comme une sécurité normale ou une bizarrerie supplémentaire de MySQL ? En tout cas, je trouve ça pour le moins embêtant ! Je pense par exemple qu’il doit être impossible de transférer une BDD MySQL contenant des triggers sur la plupart des serveurs partagés des hébergeurs web.

    Connectez-vous pour répondre ↓
48. sqlpro Auteur de l’article14 mai 2011 à 10 h 38 min

    Ce que je reproche à MySQL est simple : faire croire qu’il s’agit d’un SGBD Relationnel, alors que cela n’est pas vrai. C’est une simple encapsulation de SQL sur de la gestion de données en fichiers…
    En revanche je n’ai jamais dit que MySQL n’avait pas sa place ! Pour de petit sites web, avec peu de charge et dans lesquels on se fout de la sécurité ou du transactionnement, alors MySQL peut être parfaitement utilisé. Par exemple pour des blog…

    Connectez-vous pour répondre ↓
49. dudumomo 10 mai 2011 à 12 h 23 min

    Bonjour a tous,
    Merci a SQLPro et autres autres participant pour vos messages. Ils sont tres interessant.
    Parfois difficile a bien tout saisir vu que ca peut etre tres pointu, ou bien difficile de savoir le vrai du faux puisque chacun se renvoi la balle.
    Mais il y a tout de meme des evidences qui sont claires. Et MySQL ne semble pas etre fait pour des gros projets et n’est pas aussi « pro » que les autres.
    En revanche, pour des plus petit projet, il semble qu’un grand nombre d’utilisateurs sont satisfait du produit pour ce qu’ils en font.

    Je suis de mon cote, defenseur du libre, mais utilisateur avant tout.
    Cet article et ses commentaires m’ont fait change d’idee sur le fait de faire tourner un petit proto de Business Intelligence sur MySQL, autant passer a PostGreSQL (Plus libre, moins dependant d’une entreprise et apparament plus abouti) voire carement a Oracle, si je saute le pas, autant le faire avec cette solution et leur version Express qui semble en fait deja assez flexible.

    Bref, je continuerai a suivre les commentaires ici et je vous remercie pour toute cette belle lecture.

    Apres c’est vrai que j’ai trouve que ProSQL y va un peu fort en cassant MySQL, mais il a en tout cas toute ses raisons et cela m’a permis de decouvrir des nouveaux points.
    Je ne serai pas anti-mysql et loin de la, mais je vais maintenant faire un peu plus attention sur ce point la.

    Merci.

    Connectez-vous pour répondre ↓
50. sqlpro Auteur de l’article23 mars 2011 à 15 h 55 min

    contraintes FOREIGN KEY farfelues et non normatives…
    Un petit exemple :

    CREATE TABLE T1 (C1 INT);&nbsp;<br />
    &nbsp;<br />
    INSERT INTO T1 VALUES (1);&nbsp;<br />
    INSERT INTO T1 VALUES (1);&nbsp;<br />
    INSERT INTO T1 VALUES (2);&nbsp;<br />
    &nbsp;<br />
    CREATE INDEX X ON T1 (C1);&nbsp;<br />
    &nbsp;<br />
    CREATE TABLE T2 (C2 INT, C1 INT);&nbsp;<br />
    &nbsp;<br />
    ALTER TABLE T2 ADD CONSTRAINT FK FOREIGN KEY (C1) REFERENCES T1 (C1);

    On peut donc créer une contraintes FOREIGN KEY référençant une colonne NON UNIQUE dans la table mère !!!
    Ahurissant…

    Connectez-vous pour répondre ↓
51. sqlpro Auteur de l’article18 mars 2011 à 12 h 47 min

    ok.Idriss vous confirmez donc ce que je vois souvent : plus de code à pisser parce que MySQL est incapable de bien faire son boulot. Au finish plus de temps pour développer ! Donc un coût supplémentaire par rapport à la concurrence !

    Connectez-vous pour répondre ↓
52. ok.Idriss 18 mars 2011 à 12 h 01 min

    Oui je suis tout à fait d’accord. J’aime autant récupérer et parser les erreurs du SGBDR (avec PostgreSQL ou Oracle par exemple) et mettre en place des triggers et des procédures stockées, plutôt que de faire tout un tas de contrôle avec des regex, des requêtes de vérification, … qui surchargent inutilement le code (bien sur il en faut quand même un minimum).

    Cependant, si on est amené à utiliser MySQL (parce qu’on n’a pas toujours le choix et ça arrive souvent), il faut faire avec et mettre soi-même en place des contrôles suffisants pour sécuriser les échanges avec les utilisateurs.

    Connectez-vous pour répondre ↓
53. sqlpro Auteur de l’article18 mars 2011 à 11 h 26 min

    ok.Idriss, oui, mais c’est justement le rôle du SGBDR !!! Vous voulez faire cela sur les applications clientes ? Donc vous allez devoir coder les mêmes routines autant de fois qu’il y a d’applications ? De plus que ferez vous pour les imports de données ??? En sus qui croyez vous qui soit le plus performant pour valider des données ? Un SGBDR spécialement conçu pour cela, ou votre traitement applicatif ?
    Non, soyons sérieux, c’est dans le SGBDR qu’il faut placer les contraintes et non dans le code client. En sus, contrairement à une idée imbécile largement répandue, les contraintes améliorent les performances… Pour vous en convaincre, lisez l’excellent article de mikedavem sur le sujet…

    Bon, évidemment MySQL ne sait absolument pas faire cela d’autant plus que la moitié des contraintes de table (FOREIGN KEY et CHECK) ne sont peu ou pas du tout implémenté sous ce ersatz de SGBDR !

    Connectez-vous pour répondre ↓
54. ok.Idriss 18 mars 2011 à 10 h 56 min

    Tout a fait, mais bon, les applications professionnelles se doivent de faire des contrôles sur les données saisies avant toute insertion, modification ou suppression …

    Connectez-vous pour répondre ↓
55. sqlpro Auteur de l’article18 mars 2011 à 10 h 30 min

    Cinephil, C’est totalement délirant !!! Je ne demande pas de valeur par défaut et MySQL m’en impose une qu’il choisit ! Depuis quand un SGBDR choisit-il lui même les données à placer dans les tables ?
    Normalement ces requêtes devrait conduire à un message d’erreur et rien ne devrait être introduit dans les tables.
    Imaginons simplement que votre employeur doivent vous verser un salaire et qu’il oublie de spécifier le montant dans une requête… Seriez vous content de d’être payé ZÉRO euros par ce que MySQL l’a décidé ?
    Cela fausse par exemple toutes les statistiques. Imaginons que nous n’ayons pas les notes des absents. La moyenne de la classe plonge alors dramatiquement à cause des faux zéro !!!
    Hallucinant !!!!

    Mais il y a même pire…
    Dans la même veine, il y a les données sciemment corrompues par MySQL !

    Connectez-vous pour répondre ↓
56. cinephil 18 mars 2011 à 1 h 02 min

    Euh… je ne sais pas si c’est hors norme SQL mais dans ce cas là ça me semble tout à fait normal ! Vu que tu spécifies que les colonnes sont NOT NULL, MySQL affecte la valeur par défaut qui est 0 pour les types entier (voire numériques ?) et chaîne vide pour les types alphanumériques.
    Le plus stupide reste quand même le type DATE qui a pour valeur par défaut la date inexistante ‘0000-00-00′ !

    Connectez-vous pour répondre ↓
57. sqlpro Auteur de l’article17 mars 2011 à 21 h 53 min

    Des NULLs pas vraiment NULL !

    Décidément j’en decouvre tous les jours des inepties sous MySQL. Le coup des NULL qui sont pas NULL est particulièrement croustillant… Démonstration :

    
    CREATE TABLE T&nbsp;<br />
    
    (&nbsp;<br />
    
    &nbsp; id    INT         NOT NULL,&nbsp;<br />
    
    &nbsp; text1 VARCHAR(32) NOT NULL,&nbsp;<br />
    
    &nbsp; text2 VARCHAR(32) NOT NULL DEFAULT 'toto'&nbsp;<br />
    
    );&nbsp;<br />
    
    &nbsp;<br />
    
    INSERT INTO T (id)    VALUES (1);&nbsp;<br />
    
    INSERT INTO T (text1) VALUES('test');&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt; SELECT * FROM T;&nbsp;<br />
    
    +----+-------+-------+&nbsp;<br />
    
    | id | text1 | text2 |&nbsp;<br />
    
    +----+-------+-------+&nbsp;<br />
    
    |  1 |       | toto  |&nbsp;<br />
    
    |  0 | test  | toto  |&nbsp;<br />
    
    +----+-------+-------+&nbsp;<br />
    
    2 rows in set (0.00 sec)
    
    

    Et comme par magie les NULLs ont été transformé l’un en chaine de caractère vide et l’autre en zéro. Merci MySQL !

    Connectez-vous pour répondre ↓
    1. Max34 20 février 2013 à 12 h 40 min

       MySQL travaille à corriger ses erreurs:
       Maintenant ceci:
       CREATE TABLE test.T(
       id INT NOT NULL,
       text1 VARCHAR(32) NOT NULL,
       text2 VARCHAR(32) NOT NULL DEFAULT ‘toto’
       );

       INSERT INTO test.T (id) VALUES (1);
       INSERT INTO test.T (text1) VALUES(‘test’);

       génère une erreur sur l’abscence de valeurs par défaut lors de l’insert.
       version MySQL 5.5.28

       Connectez-vous pour répondre ↓
58. ok.Idriss 20 février 2011 à 11 h 19 min

    L’attaque sur l’orthographe est assez basse en effet … surtout que SQLpro à une orthographe tout à fait convenable. Tout le monde fait de fautes et, dans le cadre d’articles ou de tutoriels, il est beaucoup plus intelligent de les signaler gentiment et en privé.

    Je me permet de vous rappeler que Mr SQLpro, en plus d’être un excellent rédacteur et contributeur bénévole, est à la fois professionnel et enseignant dans le domaine. Plutôt que de critiquer son travail, vous feriez bien de concentrer votre énergie et vos connaissances/expériences à en faire de même. C’est beaucoup plus honorable.

    Connectez-vous pour répondre ↓
59. sqlpro Auteur de l’article20 février 2011 à 10 h 27 min

    En réponse à Donino…

    En ce qui concerne les architectures techniques, je ne sais sans doute rien faire…. Mais les quelques clients avec lesquels j’ai travaillé ces sujets ont apprécié mon savoir faire alors que les concurrents présentaient comme indispensable des architectures modernes ineptes, peu adapté et anti performantes, couteuses et complexes, notamment avec force de serveur d’objet, de framework et d’ORM !!!

    Je ne vous donnerais que quelques références :

    – DDE du gard (devenu DDTM) / Schapi – système de prévision des crues (SPC) du grand delta du Rhone (Service de prévision des crues) projet terminé fin 2010 (projet à criticité maximum – risque mortel : catastrophe naturelle). Aujourd’hui ce système qui gère l’évolution des cours d’eau affluent du Rhône depuis Lyon jusqu’à la méditerranée est considéré comme le plus puissant, le plus fiable, le plus rapide et le moins cher des SPC. Il va être repris pour de nombreuses autres surveillances comme remplaçant des systèmes actuels (récemment l’épisode tragique des crues de la Nartuby et donc de l’Argens dans le Var ayant fait 25 morts)
    Mon travail : conseil dans l’architecture technique du système, aide à la rédaction du cahier des charges, choix du sous traitant, surveillance à titre d’expert sur le développement, participation à la recette finale.

    – Santé Service (hospitalisation à domicile, 900 employés, 1200 patients) – ERP permettant de gérer les ressources et les soins à apporter aux patients. Santé Service étant le plus important établissement de soin à domicile en France et le métier étant spécifique à la France (Sécurité Sociale), aucun ERP du commerce ne pouvait donner satisfaction dans un budget assez serré. Là aussi criticité importante : durée d’interruption de service maximale autorisée : 20 minutes. Accès au logiciel : par PC portable sécurisé sans disque dur, accès mobile via RTC ou GSM dans le meilleur des cas. Traçabilité intense systématique pour les mises à jour, et pour certaines données il était indispensable de savoir qui l’a lu et ce que l’on a lu (audit de SELECT…).
    Mon travail : conseil en architecture, modélisation de la base de données, lancement des développements dans le concept « base de données épaisses »

    L’attaque sur l’orthographe est un excellent signe… quand on a plus grand chose à dire, autant attaquer sur n’importe quoi. Oui, je suis dyslexique… en plus de rédiger quelques centaines d’articles bénévolement par an ce qui ne me laisse pas beaucoup de temps pour me relire !
    En ce qui vous concerne, je remarque que vous ne publiez apparemment rien, mais cela ne vous empêche pas de critiquer le travail des autres.
    Ayez au moins un peu d’humilité !

    Connectez-vous pour répondre ↓
60. donino 19 février 2011 à 17 h 05 min

    « Mais ce n’est pas l’apanage de Terradata, cela se fait depuis plus de 12 ans chez SQL Server et 15 ou 20 chez IBM DB2 et Oracle. Jetez un coup d’Å“il aux plans de requêtes générés par SQL Server, et quand vous verrez le symbole avec la double flèche apparaître c’est que l’opération unitaire y est fait en parallèle ! »

    Oui et alors est ce que j’ai dit le contraire quelquepart? J’ai pris l’exemple de teradata car c’est de très loin le plus performant en ce domaine, c’est tout, ne voyez pas le mal partout.

    Has been? Loin de moi cette idée. Vous êtes sans doute compétent dans le domains du SQL et de l’administration/exploitation des SGBD, du moins je vous le souhaite. Vous ne maitrisez en revanche absolument pas les architectures techniques et matérielles, ni les opti avancées des SGBD, et c’est un euphémisme. C’est comme çà, on ne peut pas tout savoir il n’y a pas à en rougir, en revanche il n’est pas très judicieux d’essayer de faire croire à tout le monde le contraire. Un peu d’humilité ainsi qu’un bon correcteur orthographique ne feraient pas de mal.

    Connectez-vous pour répondre ↓
61. sqlpro Auteur de l’article10 février 2011 à 17 h 45 min

    Il est difficile de faire boire un âne qui n’a pas soif….
    Ce proverbe signifie que vous vous complaisez dans votre ignorance.

    Comme je vous l’ais dit les bons SGBDR ont un OS interne qui s’occupe de tout sauf le réseau : accès RAM, accès disque, multi-threading, gestion des caches et de la RAM. Les fonctionnalité de bas niveau de l’OS sont du pipi de chat et inutilisables en regard des problématiques que doit affronter un SGBDR. En revanche MySQL a été conçu sans cet OS interne, et c’est la raison pour laquelle il se comporte comme un veau à la montée en charge, notamment sur les aspects de concurrence.

    La seule chose de correcte que vous avez dit est la suivante :
    « Un SGBD comme Teradata segmentera la table en question pour effectuer en plus un découpage horizontal de la requête: pour simplifier il effectuera par exemple 50 mini tris de la table sur des segments, puis les regroupera afin de produire le résultat final. Ceci afin de garantir que 100% des processeurs de la machine seront utilisées pour résoudre la requête en un temps optimal, soit. « 
    Mais ce n’est pas l’apanage de Terradata, cela se fait depuis plus de 12 ans chez SQL Server et 15 ou 20 chez IBM DB2 et Oracle. Jetez un coup d’Å“il aux plans de requêtes générés par SQL Server, et quand vous verrez le symbole avec la double flèche apparaître c’est que l’opération unitaire y est fait en parallèle !
    http://blog.sqlauthority.com/2010/08/06/sql-server-parallelism-query-in-database/
    http://etutorials.org/SQL/microsoft+sql+server+2000/Part+V+SQL+Server+Internals+and+Performance+Tuning/Chapter+35.+Understanding+Query+Optimization/Parallel+Query+Processing/

    Visiblement vous n’avez donc pas lu ce que j’avais indiqué précédemment !!!
    Pour information, je vous renvoie pour l’exemple à l’OS interne de SQL Server (de nom SQLOS pour « SQL Server Operating System ») sur le blog de Slava Oks (l’un des principaux développeurs de SQLOS… : http://blogs.msdn.com/b/slavao/archive/2005/02/05/367816.aspx

    A partir du moment ou vous resterez buté à ne pas comprendre qu’il existe un OS interne dans les SGBDR, OS interne qui squeeze l’OS externe (Linux, Windows et autres), nous ne pourrons pas nous comprendre, car les problématique de cache de processeurs dont vous parlez ne concerne nullement directement le fonctionnement d’un SGBDR ! Par exemple et comme je vous l’ai déjà dit, les accès disques se font directement par le SGBDR et non pas l’intermédiaire de l’OS.
    Il y a quelques années, Oracle avait même sortie une version de son SGBDR sans OS ! Il suffisait d’introduire le CD pour installer Oracle. Cette version n’a hélas pas pris, car les ingénieurs système y ont vu leurs prérogatives diminuées. Ils se sont donc en quelques sorte « opposés » à cette sortie.

    Donc, je vous réinvite a relire encore une fois mes écrits. Je vous offre aussi l’alternative de suivre les cours de Philippe Rigaux qui a fait un bon support (http://www.info.univ-angers.fr/~gh/internet/cbd.pdf, pages 125 à 164 notamment, un peu incomplet, car introductif et http://barzilouik.free.fr/cnam/DEA_STIC_opt_CONCEPT_APP_MULTIMED_2005/UV_BaseDonneesAvancees/AspectSystemesSGBDR.pdf) sur ces sujets (puisque visiblement vous me prenez pour un andouille, je vous donne les référence d’un prof du CNAM Paris…), ou bien d’assister à un de mes cours au CNAM PACA, à l’université de Toulouse, ou encore dans l’une des écoles d’ingénieurs dans lesquelles j’interviens en 5e année : CESI/EXIA d’Aix en Provence ou bien à l’ISEN à Toulon.
    Sans doute apprendrez vous bien des choses….

    Un petit exemple, extrait des documents cités :
    Sauf exception (par exemple MySQL qui a choisi le parti-pris d’une simplicité maximale), les
    SGBD ont donc leur propre module de gestion de fichiers et de mémoire cache. Leurs principes
    généraux sont décrits dans ce qui suit.
    Dixit Philippe Rigaux. Je n’invente rien !

    Et pour ma part, ma rencontre avec les SGBDR remonte à 1982 !
    Mais j’ai au moins eu la curiosité d’aller voir à l’intérieur comment cela se passe ! Et le livre que je vous recommande à ce sujet est celui de Stonebraker « Readings in Database Systems », chez Morgan Kaufman.

    Sans doute me considérerez vous comme un has been, c’est aussi sans doute pour cela que je suis MVP SQL Server depuis 2003…

    A +

    Connectez-vous pour répondre ↓
62. donino 9 février 2011 à 19 h 25 min

    « Comprenez que si le SGBDR connais l’ensemble des « storages » et que ces derniers sont placés sur des disques physiquement indépendant (donc pas du RAID 5 !) alors il lui est possible de traiter en parallèle certaines opérations que l’OS ne pourra jamais faire. Par exemple, calculer un agrégat de type SUM ou COUNT sur une grosse table dont les données ne seraient pas déjà en RAM, oblige le moteur de stockage à monter les lignes en mémoire.
    …
    Et croyez moi, j’audite cela à longueur de journée pour mes clients et depuis 10 ans !!! »

    Vous n’avez strictement rien compris aux architectures RAID. Si vous disposez d’une baie de stockage de 16 disques en RAID 10, chaque table sera répartie sur tous les disques, et monter une table en RAM pour votre SUM sera parallélisé à la vitesse maximale autorisée par le matériel, c’est à dire avec un gain grosso modo 8 fois plus rapide dans le cas d’un RAID 10, environ 15 * plus rapide dans le cas d’un RAID 5, si bien entendu les contrôleurs sont dimensionnés correctement. Vous semblez croire, si j’ai bien compris, que 2 grappes de 8 disques en RAID 10 sont plus performantes qu’une seule de 16 disques, ce qui est mathématiquement totalement faux.

    « En fait c’est vous qui n’avez pas compris comment fonctionnent un SGBDR… Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM. »

    Heu merci pour la remarque mais j’ai l’impression qu’on ne parle pas du même domaine. Je compléterais même votre phrase en disant qu’aucune requête ne s’effectue sur la RAM, vous avez oublié les caches processeurs de niveau 1 et 2… Et pourquoi pas les registres tant qu’on y est. Essayons de rester un minimum sérieux, même si j’avoue que ce n’est pas facile. Toutefois vous êtes peut être de bonne foi, je vais donc expliciter ma remarque sur le parallélisme qui n’avait strictement rien à voir avec cette histoire de RAM.
    Imaginons un machine de 64 processeurs, une table très volumineuse sur laquelle on souhaite faire une lourde requête de type jointures + group by. MySQL saura effectuer un découpage vertical de la requête et créer des process distincts pour les jointures, le tri et l’aggrégation, fonctionnant parallélement en pipe. La machine sera ultra sous-utilisée, puisque seuls quelques processeurs seront sollicités, avec une forte contention sur le processeur chargé du tri. Un SGBD comme Teradata segmentera la table en question pour effectuer en plus un découpage horizontal de la requête: pour simplifier il effectuera par exemple 50 mini tris de la table sur des segments, puis les regroupera afin de produire le résultat final. Ceci afin de garantir que 100% des processeurs de la machine seront utilisées pour résoudre la requête en un temps optimal, soit.

    Dans ce genre de cas de figures, sur un même matériel les écarts de perf entre MySQL et Teradata/Oracle peuvent varier sans problème d’un facteur de 100. Le genre de facteur qui peut faire tourner la tête à plus d’un DSI et le pousser à engloutir les millions d’euros pour une migration. Seulement, que se passe t-il si on a cette fois 50 requêtes de ce type simultanées? MySQL sollicitera maintenant lui aussi la majorité des ressources et la courbe de perfs se rapprochera de ses camarades parallélistes. On peut même dire qu’à partir d’un certain seuil de taux d’occupation des processeurs, la gestion du parallélisme finit par coûter plus qu’elle ne rapporte. Mais pour comprendre cela, il faut avoir une volonté de compréhension des algorithmes ensemblistes que visiblement vous n’avez pas.

    « Mais certains SGBRD vont plus loin.. Par exemple dans SQL Server, il est possible que le moteur de requête profite du balayage en cours sur une table pour greffer un autre processus dessus. Le deuxième processus qui profite ainsi du SCAN n’aura plus qu’a finaliser ses lectures avec le début qu’il a raté…. »

    MySQL comme tous les autres SGBD ne va transférer un bloc du disque vers la RAM que si il n’est pas déjà présent en RAM, donc n’y a pas déjà été placé par un autre process en cours ou qui vient de se dérouler. Cela ne correspond certes pas tout à fait à ce que vous décrivez, mais revient dans la pratique presque au même. Attention de ne pas trop se faire flouer par des pseudos capacités heuristiques vendues par les éditeurs, qui ne sont bien souvent efficaces que sur les jolies plaquettes glacées de présentation.

    Pour ce qui est de votre livre ou de votre site merci bien mais vu les énormités que j’ai lues et la farce de certains liens (la palme revenant aux « benchmarks depuis une décennie » donnés en appui) je crains devoir m occuper autrement ce soir.

    Aprés 15 années de consulting en Data Warehouse, je n’ai acquis qu’une seule certitude: les crises d’un projet n’ont jamais pour véritable origine les outils (les fusibles parfaits), mais toujours les personnes qui les ont mal utilisés soit par ignorance soit par capacités insuffisantes. A vous de trouver votre catégorie.

    Connectez-vous pour répondre ↓
63. cinephil 9 février 2011 à 11 h 03 min

    Pour appuyer ce que dit SQLPro sur ce point :

    Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM. or le SGBDR conserve toutes les données en mémoire tant qu’il y a de la RAM, donnant ainsi l’impression d’aller de plus en plus vite. Plus vous requêterez, plus vous placerez en RAM, plus ce sera rapide…

    Je viens de faire un petit test sur ma machine démarrée ce matin donc vierge de toute donnée MySQL en RAM.
    Soit les tables des communes, des départements et des régions françaises et soit la requête suivante :

    SELECT c.cmn_nom, d.dpt_numero, d.dpt_nom, r.rgn_nom&nbsp;<br />
    FROM tr_commune_cmn c&nbsp;<br />
    INNER JOIN tr_departement_dpt d ON d.dpt_id = c.cmn_id_departement&nbsp;<br />
    &nbsp;&nbsp;INNER JOIN tr_region_rgn r ON r.rgn_id = d.dpt_id_region

    Première exécution en 0,00134 s, extraction des données d’une autre table puis seconde exécution de la requête en 0,0005 s, soit près de 63% plus vite parce que les données étaient présentes en RAM.
    Et cette différence n’est que sur 36682 communes, 100 départements et 26 régions. Ce serait sans doute beaucoup plus sensible sur des centaines de milliers de lignes, voire sur des millions, tant que ça peut tenir en RAM.

    Connectez-vous pour répondre ↓
64. sqlpro Auteur de l’article9 février 2011 à 8 h 14 min

    donino :
    « Il y a bien longtemps que ce n’est plus au SGBD de gérer le parallélisme des E/S sur plusieurs disques… »
    Là vous vous trompez complétement. L’intérêt que le SGBDR maitrise la répartition des IO depuis son moteur de stockage et non par le biais de l’OS est plus qu’évident et tous les jours je me bat contre les administrateur système qui tuent les performances des SGBDR en mettant des gros SAN en RAID 10 par exemple sans aucun discernement.
    Alors pour votre culture, lisez les articles que j’ai déjà écrit à ce sujet :
    http://blog.developpez.com/sqlpro/p8589/ms-sql-server/question-sur-les-fichiers-et-le-stocakge/
    http://blog.developpez.com/sqlpro/p5859/ms-sql-server/fragmentation-physique-des-fichiers-et-t/
    Comprenez que si le SGBDR connais l’ensemble des « storages » et que ces derniers sont placés sur des disques physiquement indépendant (donc pas du RAID 5 !) alors il lui est possible de traiter en parallèle certaines opérations que l’OS ne pourra jamais faire. Par exemple, calculer un agrégat de type SUM ou COUNT sur une grosse table dont les données ne seraient pas déjà en RAM, oblige le moteur de stockage à monter les lignes en mémoire. Pour ce faire, si la table a été stockée sur une seul espace de stockage la vitesse de remontée des informations sera celle du sous système disque (par exemple avec un RAID 10 cela peut être jusqu’à 4 fois plus rapide). Mais si la table a été stockée en répartissant les IO dans différents espaces de stockage (ce que permet des SGBDR comme DB2, Oracle ou SQL Server) alors la remontée des données pourra être fait en parallèle sur tous les storages simultanément. Ainsi avec 4 espaces de stockage sur 4 agrégats physiques organisés en RAID 10, la vitesse théorique peut allers jusqu’à 16 fois plus vite !
    Et croyez moi, j’audite cela à longueur de journée pour mes clients et depuis 10 ans !!!
    Sauf que MySQL en est encore à l’âge de pierre dans ces technologies car le pari qui a été fait avec MySQL est de se passer de l’OS interne que tous les bon SGBDR incorporent pour aller justement plus vite !
    La tentative de partitionnement qu’a fait MySQL n’est qu’un pis allé pour simuler maladroitement ce que font naturellement et sans partitionnement la plupart des bons SGBDR !

    donino :
    « MySQL est à la ramasse pour une requête mono très complexe, puisque il n’effectue en effet pas de découpage « horizontal » dans sa résolution, mais plus il aura d’utilisateurs/requêtes simultanées, plus il se rapprochera des performances de ses concurrents, pour des raisons assez simples a comprendre. « 
    En fait c’est vous qui n’avez pas compris comment fonctionnent un SGBDR… Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM. or le SGBDR conserve toutes les données en mémoire tant qu’il y a de la RAM, donnant ainsi l’impression d’aller de plus en plus vite. Plus vous requêterez, plus vous placerez en RAM, plus ce sera rapide… Il n’y a que lorsque la RAM est saturée que les données les moins utilisées sont déchargée au profit de nouvelles données (algorithme LRU). Cela ne fait que 30 ans que les SGBDR fonctionnent ainsi !
    Mais certains SGBRD vont plus loin.. Par exemple dans SQL Server, il est possible que le moteur de requête profite du balayage en cours sur une table pour greffer un autre processus dessus. Le deuxième processus qui profite ainsi du SCAN n’aura plus qu’a finaliser ses lectures avec le début qu’il a raté….

    donino :
    « Je ne suis pas qu’il existe en France des personnes suffisamment pointues pour définir avec rigueur à partir de quelle dimension de projet on ne devrait plus utiliser MySQL, mais il y a une chose dont on peut être tout à fait certain: l’auteur de l’article n’en fait pas partie « 
    Mis à par le fait que vous avez oublié le « sûr » au début de votre phrase, je vous invite un jour à vous documenter sur le fonctionnement des SGBDR que visiblement vous ne maîtrisez pas du tout. Il est vrai que la prolétarisation de la société informatique fait que n’importe qui peut dire n’importe quoi sur n’importe quel sujet et passer pour un expert !
    En ce qui vous concerne, mon livre, comme mon site web peuvent vous êtes d’une grande utilité pour acquérir les manquent évident de votre culture… En sus, le must pour comprendre comment fonctionne un SGBDR est le livre de Stonebraker qui est le physicien des SGBDR (c’est lui qui a inventé la plupart des mécanismes et algorithmes des SGBDR actuels) : http://www.amazon.com/Readings-Database-Systems-Joseph-Hellerstein/dp/0262693143/ref=sr_1_1?s=books&ie=UTF8&qid=1297235585&sr=1-1

    Connectez-vous pour répondre ↓
65. donino 9 février 2011 à 1 h 43 min

    Quant aux fameux « benchmark depuis une décennie » cités en référence, je vous conseille d’aller les lire si vous avez l’âme un peu tristounette ça vous redonnera le sourire.

    Connectez-vous pour répondre ↓
66. donino 9 février 2011 à 1 h 29 min

    « Déjà que MySQL ne sait pas faire du parallélisme d’accès sur les disque pour répartir les IO d’une même requête… Alors je me marre doucement sur l’intérêt du partitionnement ! »

    A moins que l’on parle de la préhistoire de l’informatique, faut pas raconter n’importe quoi non plus. Il y a bien longtemps que ce n’est plus au SGBD de gérer le parallélisme des E/S sur plusieurs disques. La moindre petite architecture multi-disques sérieuse de nos jours inclut un RAID 5 ou 10 Hardware, rendant strictement inutile un partitionnement en amont dont l’objectif serait de paralléliser les E/S… Passons.

    Dans le même ordre d’idée, « 2) que le volume de la table partitionnée dépasse la capacité d’un disque » n’a que très peu de sens, et strictement aucun sur un système RAID.
    Pour avoir fait de nombreux tests sur ce thème je peux vous assurer que si une table volumineuse est par exemple partitionnée sur le mois, et que la clause WHERE sélectionne un mois, le gain de performance d’une requête type agrégat sera quasi-proportionnel au nombre de partitions de la table (si les mois sont « Ã©quilibrés » bien sur). Par ailleurs les index étant partitionnés en même temps que la table, les indexes des partitions « chaudes » (mois courant, année courante…) pourront plus facilement être entièrement gardés en RAM et améliorer encore plus les performances.

    Je ne reviendrai pas sur le parallélisme tant les remarques sont simplistes et à charge pour ce pauvre MySQl. Simplement sur le fait que c’est exactement le contraire de ce qui est évoqué: MySQL est à la ramasse pour une requête mono très complexe, puisque il n’effectue en effet pas de découpage « horizontal » dans sa résolution, mais plus il aura d’utilisateurs/requêtes simultanées, plus il se rapprochera des performances de ses concurrents, pour des raisons assez simples a comprendre.

    Loin de moi l’idée de dire que MySQL est aussi performant sur gros volumes que les Oracle, DB2 et autres Teradata… Et je suis d’accord sur certains manques cruels dans le domaine de l’exploitation, mais de là à dire que c’est ultra-buggé, de l’ersatz, qu’il faut tout casser dés qu on atteint le To ou 100 users parce que on a eu le malheur de choisir MySQL c’est absolument n’importe quoi.

    Je ne suis pas qu’il existe en France des personnes suffisamment pointues pour définir avec rigueur à partir de quelle dimension de projet on ne devrait plus utiliser MySQL, mais il y a une chose dont on peut être tout à fait certain: l’auteur de l’article n’en fait pas partie

    Connectez-vous pour répondre ↓
67. cinephil 26 janvier 2011 à 9 h 57 min

    Nouvelles découvertes de ma part au désavantage de MySQL à l’occasion de http://www.developpez.net/forums/d655502-2/general-developpement/conception/modelisation/schema/heritage-association-entre-sous-types/#post5736426cette discussion.

    Il me semblait que, sous certaines conditions très limitantes, on pouvait faire un INSERT sur une vue, mais je n’en ai pas retrouvé mention dans la doc.

    Par contre, j’y ai trouvé qu’on ne peut pas faire un trigger sur une vue, alors que chez Postgresql, d’après la doc, on peut créer une vue qui pourra se comporter comme une table.

    Voir références dans le message cité.

    Et dire qu’on m’oblige à continuer de travailler avec MySQL !

    Connectez-vous pour répondre ↓
68. cinephil 18 décembre 2010 à 21 h 46 min

    La version 5.5 de MySQL vient de sortir… et toujours pas de contrainte CHECK !

    Connectez-vous pour répondre ↓
69. -kiki- 17 décembre 2010 à 18 h 24 min

    Salut!

    C’est bientôt Noel, et j’ai dans ma hotte une belle question à la con

    J’essaye de faire précisément le point sur les tables MyIsam…
    Elles n’ont pas de cache de données et c’est le page cache de linux qui prend le relais. Apparemment, le page cache de linux fonctionne comme le cache de données des sgbdr : par petites pages de quelques Ko. Une différence notable tout de même : par défaut, linux ne semble pas écrire dans le cache et différer l’écriture sur disque. Je pense qu’il vide le cache lorsqu’il écris une donnée dans une page.
    (tout ceci n’est pas sûr… c’est ce que j’ai cru comprendre. il faudrait déjà m’arrêter si je me trompe)
    Ma question est alors :

    Lors d’une insertion, puisque la donnée à écrire n’est pas présente en cache, les pages resteront-elle en cache?

    C’est assez important de savoir car un des intérêts que je porte aux tables Myisam est la possibilité de faire des insertions sans locker aucune lecture.
    Par rapport à innoDB, l’avantage est de pouvoir faire de gros range (ou des full scans) en même temps qu’une grande quantité d’insert.
    Mais si la moindre insertion vide le cache d’une table MyIsam, cet « avantage » ne sert plus à rien…

    sur ce, joyeux Noel!

    Connectez-vous pour répondre ↓
70. -kiki- 1 décembre 2010 à 14 h 12 min

    Allez, je vais encore voler au secours de Mysql :p

    Pour moi c’est une aubaine ce rachat : Mysql n’était pas vraiment libre? Qu’à celà ne tienne, MariaDB le sera! (enfin… j’ose espérer^^)

    Faire un site de commerce sous Mysql c’est effectivement pas top, mais utiliser une cms c’est vraiment mal^^.

    L’utilisation de mysql, passe encore. Car les transactions existent sur mysql! c’est le moteur de stockage Myisam qui ne gère pas les transactions. C’est le moteur par defaut, mais il vaut mieux ne le garder que pour quelques cas spécifiques. Par exemple, en ce moment je suis sur un site editorial (presque sans concurrence) et pourtant je n’ai même pas 10% de tables Myisam.
    Avec Mysql on a plus de chances de se retrouver avec des données incohérentes, mais certains marchands s’en moquent. Alors Mysql ou pas, ça dépend de ce qu’on attend.

    En ce qui concerne les cms de commerce, je ne connais que prestashop. Mais vue que c’est un des 2 plus côtés, je me dit qu’il n’est pas pire qu’un autre… Du coup j’ai tendance à me dire que les cms ont été réalisés par des manchos borgnes! :p
    Je ne m’y connais pourtant pas plus que ça en bdd, mais je connais au moins les bases qui font qu’un site ne rame pas dès que tu commence à remplir un peu la base et avoir pas mal d’utilisateurs… visiblement ce n’est pas le cas des développeurs de ces cms!
    Bref, Mysql n’y est pour rien, les cms sont juste mal développés.

    Connectez-vous pour répondre ↓
71. jacqueline 26 novembre 2010 à 22 h 52 min

    Merci aussi pour le lien de votre cours..

    Au vu des premières pages, ça me semble bien fait, parce que j’ai horreur des tutos : fais ci , fais ça, et puis voilà , ça y est !

    Résultat on a rien capté des principes.

    super

    Connectez-vous pour répondre ↓
72. jacqueline 26 novembre 2010 à 22 h 38 min

    Bonsoir

    Je suis une utilisatrice modeste des bases de données.

    J’ai découvert MySQL lorsqu’une amie m’a suppliée de lui faire un site de e-commerce, avec un CMS , bien sur.

    Au niveau de l’utilisation de MySQL les CMS c’est encore l’étage en dessous : un seul user avec les mêmes droits sur toutes les tables, connecté en permanence.. On ne distingue même pas le simple visiteur du client authentifié.

    Puis est arrivé le rachat de Sun par Oracle. Panique à bord dans le monde du libre ! Et là on découvre que c’est pas si libre que ça et que le coté gratuit peut disparaitre du jour au lendemain..

    J’ai pas trop paniqué parce que j’avais un OpenBSD et PostgreSQL, une occasion de voir l’autre SQL.

    Je découvre ça seule chez moi, ça me semble plus compliqué que MySQL, mais par exemple sur les transactions , je comprend bien l’exemple qui est donné : « on ne débite un compte bancaire que lorsque l’autre est crédité, sinon on efface tout »( merci !!! ) et quelques autres exemples dans le genre.. Par exemple les clés qui sont mieux expliquées que dans MySQL et leur rôle dans la sécurité des données ou l’intégrité de la base.

    Ca m’a donné envie de poursuivre avec PostgreSQL.

    La licence , il me semblait qu ‘à une époque c’était une licence BSD, je viens de voir que c’est une Licence PostgreSQL, mais leur modèle économique m’a rassurée, ils ne sont pas pendus à une seule boite, qui peut se faire racheter lorsqu ‘elle s’endort sur ses lauriers.. ( les ZZ Tops sont fatigués ? )

    Les boites utilisatrices qui apportent l’argent nécessaire au développement , ne sont que des « sponsors ». parmi elles il y a Sun , mais ça ne remet pas tout en cause.

    L’été dernier j’avais acheté une revue qui présentairt la version 8.0, mais il faut laisser le temps d’assimiler toutes ces nouveautés.

    Je ne suis pas une intégriste du libre , mais aujourd’hui c’est le tour d’ OpenOffice, après c’est le tour de Novell et d’OpenSuse ( mais eux s’ils coulent c’est pas un malheur avec le souq qu’ils ont mis par rapport à la Suse version Derrick, assez bien déboguée ).

    Plus du tout envie de me former davantage à MySQL qui peut disparaitre du jour au lendemain si l’autre a un pêt de travers.

    En tous cas merci de ce sujet comparatif, qui me sera fort utile quand je replongerais dans PostgreSQL.

    Connectez-vous pour répondre ↓
73. sqlpro Auteur de l’article21 novembre 2010 à 10 h 49 min

    La seule chose à faire est de faire des tests en grandeur nature : test avant partitionnement avec toutes les requêtes passées en une journée de production par exemple, sur un volume de données réaliste et avec mesure du coût et des temps de réponse. Ensuite partitionnement puis mesurer de ces même requêtes, dans les mêmes conditions de concurrence (donc simuler autant d’utilisateurs…). Si globalement il y a une nette amélioration, alors cela vaut le cout.
    Déjà que MySQL ne sait pas faire du parallélisme d’accès sur les disque pour répartir les IO d’une même requête… Alors je me marre doucement sur l’intérêt du partitionnement !

    A +

    Connectez-vous pour répondre ↓
74. -kiki- 17 novembre 2010 à 11 h 46 min

    ça peut paraître étrange (ou idiot?^^), mais les raisons qui m’ont amenées à vouloir partitionner sont autre que le volume de la table vs la taille du disque…

    Le seul critère que je remplissais était le point 5 : la colonne de partitionnement fait partie de TOUS les WHERE. je voulais partitionner pour pouvoir simplifier les indexs composés (j’ai peur d’avoir des problèmes de perfs avec plusieurs gros indexs, car avec le temps la table va devenir énorme…).

    L’idée est-elle mauvaise? La gestion des partitions est-elle lourde au point d’être moins performante qu’ajouter la colonne en question dans chaque index?
    (a lire votre dernier post je me doute de la réponse, mais j’aimerai confirmation)

    Connectez-vous pour répondre ↓
75. sqlpro Auteur de l’article17 novembre 2010 à 10 h 33 min

    Pour que le partitionnement soit intéressant il faut remplir de multiples conditions, dont les principales sont :
    1) une gestion des espaces de stockage permettant par exemple de prétailler les « storage » pour pouvoir recevoir n Go de données, ceci afin d’éviter les croissance de fichier et l’inévitable fragmentation physique qui va avec…
    2) que le volume de la table partitionnée dépasse la capacité d’un disque
    3) qu’on puisse définir des partitions « READ ONLY » c’est à dire faire des lectures sans verrou
    4) que l’on puisse partitionner les index indépendamment de la table
    5) que la colonne de partitionnement fasse partie d’un critère WHERE de la grande majorité des requêtes, avec un prédicat sargeable et en tête du vecteur de recherche s’il y a lieu
    6) que l’on puisse gérer les partitions : fusion, découpage, permutations…
    etc…
    A lire :
    http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/

    Aucune des fonctionnalités spécifique au SGBDR pour pouvoir faire du partitionnement n’est implémenté sous MySQL (points 1, 3, 4, 6). Pour le point 2 c’est en fonction du volume de la table et pour le point 5 c’est à vous d’écrire correctement vos requête.

    Bref, ce que fait depuis longtemps Oracle, IBM DB2 ou SQL Server, MySQL n’en arrive même pas à la cheville. C’est inexploitable… C’est ce que je dénonce sous le terme de fonctionnalité poudre aux yeux !

    A +

    Connectez-vous pour répondre ↓
76. -kiki- 16 novembre 2010 à 10 h 09 min

    D’ailleurs, à propos du partitionnement…

    Je ne l’ai encore jamais fait, et j’en aurais eu besoin. Je harcelais mon hébergeur pour qu’il mette à jour Mysql (ma version actuelle ne permettait pas les partitions)
    Mais depuis que j’ai lu ce topic, j’ai laissé en suspend…

    Le partitionnement « contre performant »… Comment est-ce possible? dans quelle mesure est-il contre performant?

    J’ai des opérations marketings qui nécessitent chacune plusieurs centaines de milliers d’enregistrements, avec pas mal de lecture/écriture (et ponctuellement, quelques stats à sortir). Dans ce cas, si je partitionne la table pour chaque opé marketing, ce sera moins performant que tout laisser d’un bloc?? (sachant qu’aucune requête n’ira chercher les informations de plusieurs opé simultanément)

    ps : désolé, j’ai l’impression de « sous-traiter » mon taff^^ mais je n’ai pas l’occasion de faire de réels tests

    Connectez-vous pour répondre ↓
77. sqlpro Auteur de l’article15 novembre 2010 à 23 h 23 min

    Comme vous dites : « Ã§a aurait pu être un outil intéressant », et c’est comme cela pour bien des fonctionnalités de MySQL, ce que j’appelle de la poudre aux yeux ! Exemple : Full Text inexploitable, SIG à pisser de rire, partitionnement a s’en mordre les doigts…

    Connectez-vous pour répondre ↓
78. -kiki- 15 novembre 2010 à 12 h 49 min

    Salut,

    Pour ce qui est du type ENUM, pour moi le seul problème est l’obligation de faire un « alter table » quand on veut ajouter un type. (problème proportionnel à la taille de la table^^)
    Son fonctionnement, lui, est tout à fait compréhensible! On m’avait déjà renvoyé vers ce topic du site du zero, mais ça n’a fait que confirmé ce que je pensais avoir compris… je trouve tout ça assez logique!
    Je ne dis pas que ça respecte la norme, mais encore une fois, sortir de la norme pour faire un outil pratique n’est pas blâmable (sauf que là, l’outil a un gros problème, mais ça aurait pu être un outil intéressant)

    Connectez-vous pour répondre ↓
79. cinephil 15 novembre 2010 à 9 h 09 min

    Encore un bug chez MySQL :
    http://www.developpez.net/forums/d998839/bases-donnees/mysql/inserer-espace-champ/#post5591140

    Si une donnée n’est constituée que d’un espace, c’est équivalent à la chaîne vide !

    Connectez-vous pour répondre ↓
80. sqlpro Auteur de l’article12 novembre 2010 à 14 h 27 min

    Voici quelques horreurs (ce terme afin d’éviter de parler franchement de bug et faire comme tout le monde, du consensus mou !) qui m’ont été communiquées par un certain peufeu :
    http://www.siteduzero.com/forum-83-578392-p1-quel-interet-de-faire-cette-requete.html#r5596787
    http://www.siteduzero.com/forum-83-578392-p1-quel-interet-de-faire-cette-requete.html#r5597752
    Croustillant non ? C’est la problématique des types ENUM !

    Problématiques du type ENUM :

    
    mysql&gt;  &nbsp;<br />
    
    SELECT x, x+1, x-1, x=1, x='3' &nbsp;<br />
    
    FROM   meeeeeh;&nbsp;<br />
    
    &nbsp;<br />
    
    +------+------+------+------+-------+&nbsp;<br />
    
    | x    | x+1  | x-1  | x=1  | x='3' |&nbsp;<br />
    
    +------+------+------+------+-------+&nbsp;<br />
    
    | 3    |    2 |    0 |    1 |     1 |&nbsp;<br />
    
    +------+------+------+------+-------+
    
    

    La solution est bien sûr que x est un ENUM( ‘3’,’2′ ). Or ENUM est en interne un entier, et par la magie des couches d’abstraction poreuses, x est donc compatible avec toutes les opérations sur les entiers, comme +, -, etc. Comme ‘3’ est la première étiquette de l’ENUM, ‘3’ vaut 1 (attention aux quotes). Donc ‘3’+1 vaut 2, logique. Bien évidemment la signification de tout INSERT ou UPDATE dépend de la présence de quotes ou non autour de la valeur.

    Autres exemples :

    
    mysql&gt;  &nbsp;<br />
    
    CREATE TABLE meeeeeh &nbsp;<br />
    
    (x        ENUM( '3','2' ), &nbsp;<br />
    
    &nbsp;y        ENUM( '3','2' ), &nbsp;<br />
    
    &nbsp;z        ENUM( '2','3' ), &nbsp;<br />
    
    &nbsp;peutetre ENUM( 'true','false'));&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    INSERT INTO meeeeeh &nbsp;<br />
    
    VALUES (1, NULL, NULL, 1),&nbsp;<br />
    
    &nbsp;      (2, NULL, NULL, 0);&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    SELECT * &nbsp;<br />
    
    FROM   meeeeeh;&nbsp;<br />
    
    &nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | x    | y    | z    | peutetre |&nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | 3    | NULL | NULL | true     |&nbsp;<br />
    
    | 2    | NULL | NULL |          |&nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    UPDATE meeeeeh &nbsp;<br />
    
    &nbsp; SET y = x+1, &nbsp;<br />
    
    &nbsp;     z = x;&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt; &nbsp;<br />
    
    SELECT * &nbsp;<br />
    
    FROM   meeeeeh;&nbsp;<br />
    
    &nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | x    | y    | z    | peutetre |&nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | 3    | 2    | 3    | true     |&nbsp;<br />
    
    | 2    | 3    | 2    |          |&nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    UPDATE meeeeeh &nbsp;<br />
    
    &nbsp; SET y = x+1, &nbsp;<br />
    
    &nbsp;     z = x+0, &nbsp;<br />
    
    &nbsp;     peutetre = NOT peutetre;&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    SELECT * &nbsp;<br />
    
    FROM   meeeeeh;&nbsp;<br />
    
    &nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | x    | y    | z    | peutetre |&nbsp;<br />
    
    +------+------+------+----------+&nbsp;<br />
    
    | 3    | 2    | 2    |          |&nbsp;<br />
    
    | 2    | 3    | 2    | true     |&nbsp;<br />
    
    +------+------+------+----------+
    
    

    Quel florilège ! Ce truc rend fou. Certains défendent bec et ongles l’utilité du type ENUM : une bonne question pour un entretien d’embauche, je pense.

    Bien évidemment modifier la liste des valeurs de l’enum nécessite un ALTER TABLE avec réécriture complète de la table (et des index) et lock exclusif (ZZZzzzzz).

    
    mysql&gt;  &nbsp;<br />
    
    SELECT 0 IN ('a','b');&nbsp;<br />
    
    &nbsp;<br />
    
    +----------------+&nbsp;<br />
    
    | 0 IN ('a','b') |&nbsp;<br />
    
    +----------------+&nbsp;<br />
    
    |              1 |&nbsp;<br />
    
    +----------------+
    
    

    Ici, on a un mariage consanguin avec PHP où on trouve les mêmes tares génétiques (où 0 vérifie toujours la première étiquette d’un switch case si celle-ci est une chaîne par exemple) ; cette petite subtilité mysqliste ne manque pas de se manifester dans les cas les plus inattendus ; on trouve de nombreuses variantes, par exemple il est tout à fait possible d’ajouter un nombre à une date et d’obtenir n’importe quoi, la date étant réinterprétée comme un nombre.

    Problématique des types entiers :

    Pour ce qui est des INT et UNSIGNED qui font des overflow et reviennent à 0, c’est sidérant (en plus ça dépend de la version 32/64 bits).

    
    mysql&gt; &nbsp;<br />
    
    CREATE TABLE truc &nbsp;<br />
    
    (x INT PRIMARY KEY );&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    INSERT INTO truc &nbsp;<br />
    
    VALUES (10),(20),(19),(30);&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt; &nbsp;<br />
    
    UPDATE truc &nbsp;<br />
    
    &nbsp; SET x = x/2;&nbsp;<br />
    
    ERROR 1062 (23000): Duplicate entry '10' for key 'PRIMARY'&nbsp;<br />
    
    &nbsp;<br />
    
    mysql&gt;  &nbsp;<br />
    
    SELECT * &nbsp;<br />
    
    FROM   truc;&nbsp;<br />
    
    &nbsp;<br />
    
    +----+&nbsp;<br />
    
    | x  |&nbsp;<br />
    
    +----+&nbsp;<br />
    
    |  5 |&nbsp;<br />
    
    | 10 |&nbsp;<br />
    
    | 19 |&nbsp;<br />
    
    | 30 |&nbsp;<br />
    
    +----+
    
    

    Cas classique : utilisation d’UPDATE sur plusieurs lignes d’une table MyISAM, ça se passe mal. Pas de rollback possible… et c’est toujours le moteur par défaut…

    Autres problématiques :

    Il y en aurait beaucoup d’autres, un plus sérieux est : l’obtention d’une valeur de la PK auto_increment sur une table InnoDB est soumise à un gros lock, résultat en cas d’inserts massifs multiprocessus, ce petit goulot d’étranglement limite tout.

    Et je termine sur l’index FULLTEXT que tu as l’air de beaucoup aimer : as-tu remarqué que toute modification de la table entraîne la modification d’une grande partie de l’index ? Si l’index ne rentre pas dans le key_buffer (en RAM), paf, tu insères un post de forum, 300 Mo d’IO… ça m’avait couché un serveur XD

    Connectez-vous pour répondre ↓
81. sqlpro Auteur de l’article5 novembre 2010 à 9 h 24 min

    Il y a effet un risque important que j’ai dénoncé depuis des années. En effet la plupart des « gratuits » de société commerciales deviennent payant lorsque les utilisateurs sont biens ferrés tel le pécheur avec son poisson.
    C’est pourquoi je recommande plutôt PostGreSQL qui est du vrai libre et largement plus professionnel que MySQL très limité et brouillon !

    Connectez-vous pour répondre ↓
82. ok.Idriss 4 novembre 2010 à 21 h 23 min

    Tout à fait, je dis simplement que c’est dommage. De toute façon, tel qu’ils sont partis, ça ne m’étonnerait pas qu’Oracle lâche MySQL même s’ils prétendent le contraire.

    Connectez-vous pour répondre ↓
83. sqlpro Auteur de l’article31 octobre 2010 à 18 h 05 min

    M’enfin bon, je travaille beaucoup avec les deux mais un des facteur qui fait que MySQL est plus utilisé dans le Web c’est les hébergeurs (gratuits du moins), il ne proposent pas tous l’administration d’une base Postgre (MySQL) et c’est bien dommage …

    C’est normal : MySQL vient d’une société commerciale qui a fait du lobbying pour être présent chez tous les hébergeurs et a plutôt bien réussit son coup puisque grâce à cela elle a bien sut se vendre à SUN puis Oracle. En revanche PostGreSQL n’appartient à personne et il n’y a aucune compagnie au cul pour la pousser quelque part…
    Bien souvent en informatique on se retrouve avec des outils populaires, mais médiocre. Cela a été le cas avec les premiers PC dont le choix de microprocesseur a été le plus mauvais. Il a fallu près de 30 ans pour en faire quelque chose d’acceptable !

    Connectez-vous pour répondre ↓
84. ok.Idriss 8 octobre 2010 à 18 h 52 min

    J’ai toujours crus que MySQL était plus rapide que Postgre aux SELECT et que PostgreSQL était plus rapide que MySQL aux INSERT …

    M’enfin bon, je travaille beaucoup avec les deux mais un des facteur qui fait que MySQL est plus utilisé dans le Web c’est les hébergeurs (gratuits du moins), il ne proposent pas tous l’administration d’une base Postgre (MySQL) et c’est bien dommage …

    C’est dommage parce que Postgre est tout aussi bien géré dans la quasi-totalité des langages permettant l’utilisation de SGBD (en PHP notamment) et il force les développeurs à respecter les schémas relationnels et leur différentes contraintes. [Et puis je n’ai jamais vue de tables corrompues avec Postgre].

    Cordialement,
    Idriss

    Connectez-vous pour répondre ↓
85. sqlpro Auteur de l’article30 septembre 2010 à 13 h 42 min

    Sur la mise en cache des données en général

    Ce ne sont pas les tables qui sont mise en mémoire, mais les pages les plus lues. Ainsi si une table de 500 Go n’est fréquemment lue que pour ses données les plus récentes, ce seront les pages concernées qui persisterons en RAM. De manière générale, la mise en cache obéit à un algorithme du genre « plus j’ai demandé à lire (ou écrire) cette page, plus elle persistera longtemps ». Inversement, les pages les moins lues dégageront en premier pour laisser la place aux suivantes.
    En sus, comme tout ce qui est code dans une base de données (vue, procédure, fonction, déclencheur…) est en fait constitué de données dans des tables système, même le code SQL est donc mis en cache avec la même fréquence d’utilisation, y compris les plans de requêtes que génèrent lesdits codes.

    Sur la réplication en général

    La réplication ne consiste pas à dupliquer une base, mais à répliquer certaines informations de certaines tables d’une base à l’autre entre différents serveurs.
    Dans une réplication, il n’y a aucune obligation que les tables soient identiques. En effet on s’intéresse à répliquer de l’information et non des objets !

    Beaucoup confondent la réplication et la haute disponibilité. La haute disponibilité consiste à avoir une seconde base de données contenant les mêmes objets et données que la base source pour qu’en cas de défaillance de la base source on puisse utiliser la base de secours afin d’assurer une certaine continuité applicative.

    L’intérêt de la réplication est double :

    a) pouvoir augmenter la surface d’attaque des données (scale out) :

    Par exemple en répliquant toutes les données de certaines tables d’une base sur plusieurs serveur, on peut servir plus de client qui utilise l’application.

    MAIS… l’inconvénient de la chose est qu’une bonne partie des ressources physique des machines est occupé à gérer la réplication, et globalement, la puissance disponible pour servir les clients est très notablement amoindrie par le simple fait de l’exécution des processus de réplication.

    En effet, pour cela soit intéressant il faudrait que la réplication soit faite en mode synchrone, hors c’est impossible, car cela reviendrait à verrouiller la même table sur tous les serveurs simultanément avec un allongement dramatique des temps de blocage lié au transit réseau. C’est pourquoi la réplication est toujours asynchrone et il vaut mieux pour la mobilisation des ressources que le temps de latence soit au moins que quelques minutes….

    Ce n’est dont pas généralement une bonne solution, et en pratique on utilise cela en dernière limite lorsque le scale up n’est plus possible. Ainsi, si l’on ne peut pas changer le serveur actuel pour un serveur plus puissant (64 CPU, 512 Go de RAM et quelques centaines de To de disque en SAN…), on devra se résigner à faire du scale out, mais il faudra trouver un processus (toujours couteux) pour tenter de synchroniser les données (le commit à deux phases n’ayant aucune garantie de bonne fin…).

    En fait il existe très peu de solutions fiables de scale out synchrone et c’est souvent très cher. Le seul exemple que je connaisse est Oracle RAC mais le prix des licences et le cout en installation/admin est extrêmement élevé. La solution proposée par MySQL est encore un embryon peu performant… En effet, allez donc lire les commentaires de ceux qui ont fait des benchmarks sur le sujet : http://forums.mysql.com/read.php?25,257168
    Bref, en doublant les ressources on gagne pratiquement rien !!!

    Bref, no silvestre boulette comme disent no cousins d’outre atlantique !

    b) pouvoir découper une application en différentes bases fonctionnelle

    Par exemple pour un site web marchand, on peut découper la base en deux : d’un côté la base « front office » qui présente les produits, les commentaires, les habitudes d’achat et le profilage des clients ainsi que les commandes passées.
    De l’autre on peut avoir dans une base « back office » les éléments suivants : client, produits, commandes (données communes), mais aussi stock, facturation, expédition…
    Dans ce cas on utilisera différents flux de réplication :
    – l’un du BO vers le FO pour les nouveaux produits, avec par exemple un temps de latence de 24h
    – l’autre du FO vers le BO pour toute nouvelle commande passée, avec par exemple un temps de latence de 5mn.
    Ainsi chaque serveur est indépendant et l’arrêt du BO ne pénalise pas la vente !

    C’est plutôt dans ce sens que la réplication est intéressante : le découplage de différentes bases de données et donc serveur qui fonctionnent en mode asynchrone afin de fournir un service complet et répartit.
    C’est d’ailleurs dans ce sens qu’évolue les SGBDR aujourd’hui en base de données réparties.

    12000 tables et qq milliers d’utilisateurs simultanés

    Le nombre de table est élevé, mais ne signifie par forcément un volume de données gigantesque. Ce qui importe est plus le volume global et l’indexation. A ce titre MySQL ne sait pas gérer par exemple les matrices creuses (non stockage des NULL) et son indexation est plus que pauvre :
    – pas d’index calculés
    – pas d’index couvrant (INCLUDE)
    – pas d’index partiaux ou filtrés (WHERE)
    Рpas de vues mat̩rialis̩es ou index̩es
    – pas d’indexation possible des données XML ni SIG (spatial)

    Le nombre d’utilisateur simultané supportable par un serveur unique du type SQL Server, oracle ou IBM DB2 est de plusieurs dizaines de milliers en pratique. Mais à cela, il faut la machine correspondante. Pensez à fnac.com, tgv.com, amadeus ou encore euridile, des bases ayant régulièrement des pics à plusieurs dizaines de milliers d’utilisateurs sans broncher, avec un très fort aspect transactionnel, contrairement à facebook qui ne fait quasiment aucune transaction ! (et pour lequel la perte de données et de transactions est acceptable !!!

    Bref ma problématique générale est : PostgreSql semble souffrir de problèmes de réplication et de clusterisation. Qu’en est-il précisément? Peut-on contourner ces problèmes?

    En définitive, si vous avez réellement ce besoin, je ne choisirait ni MySQL ni PostGreSQL qui ne sont pas encore au point sur ces technologies. Je prendrais Oracle ou SQL Server (ces deux éditeurs maîtrisant ces concepts en production depuis plus d’une décennie) et ce choix à terme à toutes les chances de s’avérer bien moins cher que d’investir sur du soit-disant gratuit qui peut s’avérer très couteux en terme matériel et plus encore en terme d’administration voire catastrophique en cas de perte de données !

    Connectez-vous pour répondre ↓
86. -kiki- 21 septembre 2010 à 15 h 09 min

    Je tombe des nues!
    Certains types de tables de Mysql peuvent être mises en RAM (MyIsam compressé, NDBCluster…), je pensais que c’était un atout… en fait c’est un boulet car normalement (avec les autres sgbdr) les tables les plus utilisées sont automatiquement mises en RAM !?

    Du coup PostgreSql devient séduisant, mais il y a 2 points que j’aimerai que vous développiez :

    1- parler nous de la réplication PostGreSQL,… dans la vraie vie
    (tempoxav, quelques commentaires plus haut)

    2- L’implémentation PGPool II pour PostgreSQL réalise bien une répartition de charge en lecture sur plusieurs instances parallèles de PostgreSQL, mais présent un défaut majeur pour la clusterisation d’une base de données complète. En effet, la négociation des séquences lors d’écritures multiples provoque des erreurs de séries dans les indices, car ce mode de clusterisation n’intègre pas une synchronisation d’écriture dans les différentes bases.

    Et puisque vous aimez les gros sites, pour ce 2eme point je tiens à préciser que c’est un extrait d’un compte rendu pour un gros projet (12000 tables et qq milliers d’utilisateurs simultanés) et qu’au final, Mysql a été retenu (pour son NDBCluster)…

    Bref ma problématique générale est : PostgreSql semble souffrir de problèmes de réplication et de clusterisation. Qu’en est-il précisément? Peut-on contourner ces problèmes?

    En tout cas, merci pour vos explications
    En effet étant autodidacte et pas très expérimenté, je manque de connaissances.

    Connectez-vous pour répondre ↓
87. sqlpro Auteur de l’article19 septembre 2010 à 13 h 33 min

    Visiblement KIKI, vous manquez de culture sur les SGBDR en général ! Alors allons-y…

    kiki

    1- Vous dites qu’il n’y a pas de mécanisme « haute disponibilité ». Que faites-vous du Cluser Mysql?

    Il s’agit avant tout d’une solution système et non au niveau du SGBDR. Par exemple sous PostGreSQL et SQL Server vous avez le log shipping, sous SQL Server vous avez le mirroring, la réplication et Service Broker, sous Oracle, le système RAC….
    Bien entendu, tous les OS modernes proposent des solutions de gestion de cluster depuis des années. Pas exemple la solution Microsoft Windows Cluster existe depuis la version 2000 de Windows… Il suffit que le logiciel soit conçu pour être « cluster aware » !

    2- L’exécution parallèle des requêtes serait limitée? Pourtant je pense qu’il n’y a que Mysql qui permette à 2 threads de lire et écrire en même temps sur la même table. niveau parallélisation c’est plutôt pas mal!

    Tous les SGBDR sauf MySQL savent paralléliser les écritures et lectures, et même les calculs d’agrégats sur TOUS les CPU simultanément. Actuellement SQL Server a été testé avec 96 CPU en //. MySQL est donc très loin du compte !

    3- l’utilisation outrancière des tables temporaires… il ne tiens qu’à nous d’écrire des requêtes qui ne nécessitent pas de tables temporaires! (pas toujours possible j’avoue.)
    D’autant moins possible que comme MySQL n’implémente ni les requêtes récursives (voir : SQL récursif ), ni les fonctions OLAP, de ranking ou les fonctions analytiques (voir : fonctions fenêtréess ), la plupart du temps il faudra y recourir, alors que sous PostGreSQL, Oracle ou SQL Server cela existe depuis des années (norme SQL 1999) !

    4- l’index full text « poudre aux yeux » ? je dirais plutôt outil moyennement performant mais très pratique pour les boulets du sql comme moi car très simple.
    Lisez le chapitre 8 de la dernière édition de mon livre sur SQL. Il est consacré à l’indexation textuelle selon la norme SQL. Il compare MySQL et SQL Server. Bref, sur 13 types de recherches textuelle, MySQL n’en supporte que 5 et encore avec beaucoup de manques comme une gestion multilangue des mots noirs. En comparaison, SQL Server en supporte 11 avec une gestion multilangue des mots noirs.

    5- Mysql deviendrait problématique lorsque le site deviens trop gros? Alors là vous ne jouez pas dans la même catégorie que la pluspart des entreprises! Et ce commentaire concerne finalement peu de monde (je pense). En ce moment par exemple je bosse pour un site relativement gros, il y a un seul serveur mysql qui se prend 600 connexions secondes avec des requêtes pas toutes optimisées, et ça tourne plutôt pas mal…
    Pour vous, un site « qui deviens gros » c’est quoi? 10K connexions secondes? C’est quoi vos sites? Youtube?

    fnac.com, Amadeus, United Airlines, Musiwave, Euridile…. des bases de données de plusieurs TO avec SQL Server et quelques milliers d’utilisateurs simultanés.
    france telecom, TGV …. des bases de données de plusieurs TO avec Oracle et quelques milliers d’utilisateurs simultanés.

    En suite, y’a un ptit truc que je trouve magique dans Mysql, et je ne sais pas si des moteurs de tables d’autres sgbdr savent le faire…
    roulements de tembours…
    mettre des champs à taille dynamique en RAM! (comme Varchar ou Text)
    Si seul Mysql sais le faire, c’est quand même la honte pour tous les autres!
    (je dis ça car innoDB de mysql ne sais pas le faire, j’imagine donc que innoDB des autres sgbdr ne savent pas non plus)

    Preuve que vous ne connaissez pas grand chose aux SGBDR. Tous les SGBDR fonctionnent exclusivement en RAM et le stockage sur disque est un épiphénomène lié à la persistance et aux limites des tailles des RAM ! Dans l’absolu on devrait pouvoir se passer des disques, ce qui n’est pas le cas de MySQL du fait de son architecture simplifié intimement liée à l’OS système… Tous les autres SGBDR intègrent un OS interne pour obtenir des performances nettement supérieures (notamment en terme de concurrence)…

    6- pas de collation insensible aux accents?? pour ne prendre qu’un exemple : utf8_unicode_ci est insensible à la casse et aux accents (comme prévu)
    Nous avons eu cette discussion sur le fil suivant : Critique MySQL
    Il en ressort que piloter l’insensibilité aux accents est impossible. En effet, dans MySQL soit les collations sont sensibles à tout (casse et accents) soient sensibles à rien.. Aucune solution intermédiaire n’est disponible, par exemple CI_AS ou CS_AI.
    De plus le terme de « accents sensitive » est trompeur. En effet, il ne s’agit pas que des accents mais de tous les caractères dit diacritiques… (diacritique : dia = 2, critique = différence, symbole composé de deux éléments qui le différencie). Par exemple la cédille, mais aussi les ligature comme l’e dans l’o de cÅ“ur, bÅ“uf….
    Allez donc faire comprendre à un utilisateur qu’il ne pourra jamais trouver de bÅ“uf parce que MySQL ne sait pas faire !!!!
    Enfin, il y a pire : la recherche dans l’index textuelle (Full Text Search) est victime du même phénomène…
    Bref, inexploitable pour des sites web en langues latines (français, espagnol, italien…) !

    Quand à a fiabilité, aucun logiciel n’est fiable à 100%. Même Oracle et SQL Server comportent de nombreux bugs, mais au moins les produits sont largement testés avant d’être diffusé et les outils de suivi de bugs (comme connect de Microsoft) sont efficaces et les corrections très réactives. Mais quand on a de nombreux bugs et que l’on préfère sortir des nouveautés à peine testées, il est difficile ensuite de les corriger !

    Connectez-vous pour répondre ↓
88. -kiki- 15 septembre 2010 à 14 h 01 min

    re!

    j’ai encore une remarque :

    6- pas de collation insensible aux accents?? pour ne prendre qu’un exemple : utf8_unicode_ci est insensible à la casse et aux accents (comme prévu)

    et j’ai une autre remarque pour tempoxav :

    Mysql fiable?? je ne connais pas d’autres sgbdr, mais à partir du moment où il y a des bugs je ne considère pas mysql comme fiable! Et j’ai vu plusieurs fois Mysql sortir de jolis bugs sur des requêtes bien faites (lourdes, mais bien faites).

    A mes yeux, Mysql est un bon sgbdr, mais seulement si on est peu regardant sur la fiabilité (cohérence des données ou bugs), ce qui est tout de même le cas pour la majorité des sites de contenu, qui eux même représentent une grosse partie des sites web.
    Du coup je rejoins finalement tempoxav sur un point : Mysql or not Mysql, ça dépend de nos besoins. Enfin, je crois…

    Connectez-vous pour répondre ↓
89. -kiki- 14 septembre 2010 à 17 h 38 min

    je me suis un peu mélangé, et du coup je me pose une question :

    Peut-on mettre les tables InnoDB en RAM?
    Je vais me renseigner, mais je pose la question au cas où… et pour montrer qu’en fait j’en sais rien.

    (c’est la fin de journée, faut être indulgents :p en fait je pensais aux tables HEAP quand je disais qu’on ne pouvait mettre des champs à taille dynamique en RAM)

    Connectez-vous pour répondre ↓
90. -kiki- 14 septembre 2010 à 17 h 25 min

    Salut,

    Par avance, excusez moi si je suis à côté de la plaque mais je suis développeur php (pour vous donner une idée du niveau en sql :p) et je ne connais que Mysql (je n’ai donc aucun point de comparaison)

    1- Vous dites qu’il n’y a pas de mécanisme « haute disponibilité ». Que faites-vous du Cluser Mysql?

    2- L’exécution parallèle des requêtes serait limitée? Pourtant je pense qu’il n’y a que Mysql qui permette à 2 threads de lire et écrire en même temps sur la même table. niveau parallélisation c’est plutôt pas mal!

    3- l’utilisation outrancière des tables temporaires… il ne tiens qu’à nous d’écrire des requêtes qui ne necessitent pas de tables temporaires! (pas toujours possible j’avoue.)

    4- l’index full text « poudre aux yeux » ? je dirais plutôt outil moyennement performant mais très pratique pour les boulets du sql comme moi car très simple.

    5- Mysql deviendrait problématique lorsque le site deviens trop gros? Alors là vous ne jouez pas dans la même catégorie que la pluspart des entreprises! Et ce commentaire concerne finalement peu de monde (je pense). En ce moment par exemple je bosse pour un site relativement gros, il y a un seul serveur mysql qui se prend 600 connexions secondes avec des requêtes pas toutes optimisées, et ça tourne plutôt pas mal…
    Pour vous, un site « qui deviens gros » c’est quoi? 10K connexions secondes? C’est quoi vos sites? Youtube?

    En suite, y’a un ptit truc que je trouve magique dans Mysql, et je ne sais pas si des moteurs de tables d’autres sgbdr savent le faire…
    roulements de tembours…
    mettre des champs à taille dynamique en RAM! (comme Varchar ou Text)
    Si seul Mysql sais le faire, c’est quand même la honte pour tous les autres!
    (je dis ça car innoDB de mysql ne sais pas le faire, j’imagine donc que innoDB des autres sgbdr ne savent pas non plus)

    @tempoxav : Mysql 5.5?? la dernière version stable c’est pas 5.1 par hasard?…

    Connectez-vous pour répondre ↓
91. dbaffaleuf 17 août 2010 à 17 h 10 min

    En MyISAM, tu as aussi le pb de ulimit sur le nombre de file descriptors ouvert pour un process. Sinon je suis assez partagé, il y a des trucs sympa aussi sur MySQL. Mais le développement open source n’a pas le même rythme et le même cadrage que dans une corp de la taille de MS ou Oracle, avec des armées de développeurs, des responsables d’équipes qui sont des sacrées tronches avec ça. Et pour leur décharge, depuis l’éclatement de l’équipe à l’origine d’AB, il n’y a plus trop d’avancées significatives. Mais si tu regardes du côté de Percona par exemple, tu verras qu’ils continuent de pousser sur d’autres variantes d’InnoDB.

    Et on dira ce qu’on veut, mais ni Larry Ellison, ni Dave Campbell ni Bob Epstein n’ont écrit leur SGBD sans une équipe solide avec eux. Monty, lui, était tout seul avec son vi et son gcc.

    David B.

    Connectez-vous pour répondre ↓
92. Chtulus 26 juillet 2010 à 23 h 19 min

    Bonsoir,

    Merci pour ces explications !

    Énorme ^^

    @ Bientôt

    Connectez-vous pour répondre ↓
93. sqlpro Auteur de l’article26 juillet 2010 à 14 h 33 min

    Chtulus :

    les opérations de lecture des méta données ne sont pas transactionnelle (on peut donc obtenir un résultat faux) :
    En effet, MySQL ne stocke pas les méta données des bases dans des tables systèmes, mais parcoure les différents objets pour les présenter sous forme tabulaire. Pendant qu’il effectue ce travail, la structure des objets peut changer ! Dans les SGBDR bien fait, cela est fait à l’aide de table système qui sont verrouillées (par exemple sous SQL server, verrous de type Sch-M et Sch-S pour verrou de schéma Modif et Shared) le temps de lire ou de modifier la structure de l’objet, garantissant ainsi l’aspect transactionnel !

    du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse :
    En effet suivant le système d’exploitation retenu (Distribution Linux, Editions Windows, Novell, Solaris, UX, AIX…) les noms des tables seront plus ou moins limités car ils sont très dépendant de l’OS (au départ dans MySQL : une table = un fichier…)

    des index sur des colonnes calculées ou des expressions sont impossibles :
    MySQL ne supporte pas les colonnes calculées, donc pas d’indexation non plus dessus. MySQL ne supporte pas non plus la création d’index sur fonction, sauf dans un cas particulier : une fonction limitant le nombre de caractère dans le cas d’une colonne littérale.

    Connectez-vous pour répondre ↓
94. Chtulus 25 juillet 2010 à 17 h 44 min

    Salut Fred,

    Tu pourrais juste me donner des explications rapide là dessus s’il te plait ?

    Рles op̩rations de lecture des m̩ta donn̩es ne sont pas transactionnelle (on peut donc obtenir un r̩sultat faux).

    – du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse

    Ça par contre c’est énorme !

    Рdes index sur des colonnes calcul̩es ou des expressions sont impossibles

    

    Connectez-vous pour répondre ↓
95. sqlpro Auteur de l’article23 juillet 2010 à 11 h 14 min

    Smashou : vous avez tout à fait raison, dans vos commentaires, mais j’y mettrais un bémol important : tous les éditeurs de gros SGBDR proposent une version gratuite (certes limité), mais parfaitement capable de ce que vous dites (par exemple pour MS SQL Server 2008 R2 Express c’est des bases limitées à 10 Go mais sans limites ni de nombre, ni d’utilisateurs). Or le problème c’est qu’il arrive régulièrement qu’une petite base devient grosse et c’est là que le problème survient, car passer de MySQL à SQL Server, Oracle ou même PostGreSQL coûtre très cher aux entreprises ! En particulier lorsqu’il faut faire de la haute disponibilité ou de la réplication car ces techniques ne sont qu’embryonnaires et rarement stable dans MySQL et nécessite beaucoup de travail de mise en Å“uvre et administration au quotidien, alors que par exemple sous MS SQL Server, cela se fait les doigts dans le nez (mettre en place une haute disponibilité via mirroring synchrone d’une base demande 5 minutes et aucune connaissance particulière grâce aux assistants).
    En définitive, il n’y a pas de temps gagné en choisissant MySQL (je dirais même qu’il y a beaucoup de temps perdu pour contourner les nombreuses fonctionnalités manquante sans parler des bugs…) et qu’au final le choix de ce SGBDR peut couter très cher à un moment critique ! (celui du passage à un vrai SGBDR).

    Connectez-vous pour répondre ↓
96. Smashou 22 juillet 2010 à 17 h 50 min

    J’ajouterais quelques points important qu’il faut préciser. Mysql est loin d’être le meilleur SGBD du monde (Personne ne reviendra dessus), cependant il à ses avantages (loin d’être exhaustif):
    * Il est suffisant pour de petites applications qui n’auront pas forcément propension à grossir (exemple de nombreux développements interne dans les sociétés pour faire du partage de planning, de la petite CRM, de l’édition de facture simple, …)
    * On peut dire ce que l’on veut sur le coût, mais cela ne revient pas au coût de SQL server ou Oracle et loin de là.
    * Enfin pour les petites structures, installer un SQL server ou un Oracle à un coût bien trop important et demande malgré tout des connaissances supérieures qui coûtent encore une fois très chère! N’oublions pas que, malheureusement, c’est l’argent qui fait tourner les entreprises!

    Et bien heureusement qu’il a été offert aux hébergeurs, vous imaginez les coûts liés aux hébergements mutualisés sinon?!

    On est tous d’accord que Mysql est loin d’être le SGBD parfait, mais il est tout de même amplement suffisant pour un nombre gigantesque de cas! (Personnellement je trouve cela parfaitement idiot d’installer, par exemple, un Oracle pour une petite application qui possède 5 utilisateurs…, allez justifier les coûts auprès du client après…).
    N’oublions pas SVP qu’il y a beaucoup plus de petites structures dans le monde que de grosses!

    Enfin je suis tout à fait d’accord sur les qualités de PostGreSQL qui n’a malheureusement pas connu la même publicité que Mysql.

    Je m’excuse d’avance, votre argumentaire n’était pas basé sur ces points et était plutôt orienté sur la technique. Mais mon commentaire à plus une vocation à complémenter le votre qu’a le démonter.

    Connectez-vous pour répondre ↓
97. sqlpro Auteur de l’article22 juillet 2010 à 12 h 42 min

    tempoxav : ce que vous dites est faux au sujet de la sauvegarde online. Il est toujours impossible de faire des sauvegardes consistante à chaud. Des sauvegardes à chaud sont possible, mais ont de grandes chances d’être inconsistantes. Le mode de sauvegarde de MySQL consiste à balayer chaque table pour la sauvegarder. Dans un tel scénario, il est possible de sauvegarder la table des clients puis la table des commandes et qu’entre les deux un nouveau client soit ajouté avec une commande. A la restauration vous vous retrouvez donc avec une commande sans client et votre base est incohérente. Ceci est le point noir de MySQL depuis des lustres et comme c’est relatif à l’architecture spécifique de MySQL, c’est pas près d’être rectifié. Je précise que mes sources sont celles d’un architecte de l’équipe MySQL AB encore en poste à ce jour.
    Encore une fois facebook est un très mauvais exemple sur le plan des performances transactionnelles, car il n’y a aucune concurrence de mise à jour dans le site… En effet, chaque abonné ne peut modifié que sa propre page, il n’y a donc jamais qu’un seul processus concurrent en écriture ! Or faire des transactions sur une non concurrence revient à ne pas faire de transaction du tout !
    En sus, les paiements CB sont généralement externe (solutions propres aux banques) et sont là, fait sur du Oracle ou du IBM DB2….
    Quand à parler de fiabilité pour MySQL, je crois que c’est une plaisanterie vu le nombre de posts dans lequel le serveur plante. Personnellement, je n’ai jamais vu un serveur MS SQL, ou Oracle ou IBM DB2 planté, sauf en cas de panne matérielle grave (CPU par exemple).
    Enfin, les nombres que vous annoncez en terme d’installations, sont basés sur aucune étude sérieuses et les études sérieuses de Gartner par exemple ne peuvent même pas mesurer les PDM de MySQL tellement elles sont infimes (Gartner a établi de son côté qu’ils [les SGBDR open source] représentent moins de 1% du marché). Il est vrai que si c’est 100 millions d’installation chez des particuliers, cela ne rime à rien !

    Un petit exemple de ce que le moteur SQL ne sait pas optimiser (alors que les autres le font) est donné par Peter Gulutzan dans cette vidéo.

    Connectez-vous pour répondre ↓
98. tempoxav 22 juillet 2010 à 11 h 26 min

    Votre billet à charge n’est pas à jour sur les évolutions de MySQL 5.5 :
    – perfs démultipliées sur les multi-coeurs (un séminaire de 4 heures à Paris a détaillé cela devant 140 participants assidus)
    – online backup
    – performance schema

    Un peu de prétention en moins ça aurait fait mieux : allez tous voir les pres et retour d’expérience de Mark Callaghan sur la perf MySQL : il est resp BD de Facebook, après l’avoir été chez Google, avoir été à la R&D Oracle et R&D Informix.

    Je rajouterais des paiements CB, des transactions de bourse qui sont gérées par des bases MySQL pour des millions de transactions par jour. transactionnel MySQL ?

    Bcp comme vous voudrait reproduire la même architecture avec MySQL que celle utilisée avec MS SQL : c’est une erreur car le design n’est pas le même.

    PostGreSQL et les autres bases sont bonnes et vont dans la course à la fonctionnalité. MySQL a suivi une autre approche :
    MySQL a été conçue pour la légéreté, la performance, la scalabilité (parler nous de la réplication PostGreSQL,… dans la vraie vie) et la fiabilité.
    MySQL ne fait pas la course à la fonctionnalité, car cela amène de la lourdeur et des problèmes de fiabilité!

    MySQL c’est juste différent et ça répond à un besoin. Au moins il y a du vrai choix en terme d’architecture pour les utilisateurs!
    Rappel : 100 Millions d’installations actives
    ce n’est plus un hasard!

    Connectez-vous pour répondre ↓
99. cinephil 22 juillet 2010 à 9 h 21 min

    Et même dans le cas d’un CMS, certains ont des plugins pour en faire un site marchand !

    Connectez-vous pour répondre ↓
100. sqlpro Auteur de l’article22 juillet 2010 à 8 h 47 min

     cinephil : c’est bien là le problème… devoir intervenir quand il faut tout refaire, alors qu’il serait si simple de faire bien en utilisant un autre SGBDR. Je ne dit pas qu’il faut éviter MySQL dans tous les cas, mais dans le cas d’application fortement transactionnelle comme c’est le cas général des sites web marchand, c’est une catastrophe. En revanche utilisé comme outil de gestion de contenu de site, ça va très bien (exemple SPIP) parce qu’il n’y a en principe qu’un seul éditeur et même s’il y en a plusieurs ce n’est pas sur les mêmes données qu’ils travaillent et que l’essentiel des opérations est en lecture.

     Connectez-vous pour répondre ↓
101. cinephil 21 juillet 2010 à 23 h 46 min

     Fred, je pense que plus de 80% des utilisateurs de MySQL, dont moi, ne connaissent pas 20% des fonctionnalités dont tu reproches l’absence chez MySQL.
     Ce SGBD n’est certes pas le meilleur mais leur est suffisant… jusqu’au jour où le petit site qu’il ont plus ou moins bien développé rencontre le succès et qu’ils sont obligés de faire appel à des spécialistes comme toi pour leur expliquer pourquoi leur bébé est devenu un escargot.

     A titre perso, ce qui m’a décidé à passer à Postgresql pour ma BDD perso, c’est l’absence de contrainte CHECK dans MySQL.

     Connectez-vous pour répondre ↓
102. sqlpro Auteur de l’article21 juillet 2010 à 18 h 44 min

     Zabriskir : FireBird n’est pas très bon en transactionnel. Préférez PostGreSQL, sinon, optez pour du commercial comme SQL Server (le moins cher des payants).

     tulipebleu : Google utilise sans doute MySQL mais pour quelle fonctionnalité ? En général c’est pour du stockage de données sans aucune concurrence de mise à jour. Pas vraiment l’usage standard d’un SGBDR, mais plus du COBOL amélioré ! Quand aux listes, cela ne veut rien dire, surtout lorsqu’elles viennent de l’éditeur lui même. En revanche MySQL n’est présent dans aucun site de records de volume comme http://www.wintercorp.com ni de benchmark officiel comme tpc.org…
     En comparaison PostGreSQL possède quelques records non négligeables… http://www.computerworld.com/s/article/9087918/Size_matters_Yahoo_claims_2_petabyte_database_is_world_s_biggest_busiest

     daredare : je crois effectivement qu’en matière de commentaires, il va y avoir du sport !!!

     Connectez-vous pour répondre ↓
103. daredare 21 juillet 2010 à 14 h 14 min

     Très bons les arguments tulipebleu, il faut que je me les garde pour un prochain coup, histoire de faire rire les collègues !

     ….

     Si Google utilise MySQL, ce n’est certainement pas pour leur moteur de recherche !

     Quant à Oracle Express, je l’ai installé « il y a quelques années » sur un PC modeste (HP Pavilion P4 2 GHZ, 2Go de RAM, Windows 2000 serveur), et je n’ai pas rencontré de souci. Par contre, un jour, en mangeant des cacahuètes, mon PC a pris feu ! Faut-il y voir une relation de cause à effet ?

     Ceci étant, je ne suis pas un expert BDD, mais je trouve ce billet tout bonnement excellent (sans compter la poilade liée aux commentaires ;-).

     Connectez-vous pour répondre ↓
104. tulipebleu 21 juillet 2010 à 13 h 58 min

     Voici une liste d’entreprise qui utilise MySQL :
     http://www.mysql.fr/customers/

     Connectez-vous pour répondre ↓
105. tulipebleu 21 juillet 2010 à 13 h 56 min

     Et ça recommence …
     Oui c’est vrai, MySQL n’a pas toutes les fonctionnalités des concurrents, mais de la a dire que MySQL n’est pas un SGBD.
     Si vous ne l’aimez pas, parfait, ne l’utilisez pas. Mais ne faites pas croire qu’il est tellement null qu’aucun projet ne l’utilise.
     Google l’utilise pour son moteur de recherche.

     A titre presonnel, je trouve MySQL beaucoup plus rapide pour faire des select, update, delete qu’Oracle. Mes tests automatisé mette 3h30 en MySQL et 4h en Oracle.

     Et en parlant d’Oracle, il y a quelques années, j’ai installé Oracle Express sous windows sur un PC. A la fin de l’installation du PC, l’alimentation a commencé à faire des étincelles, et elle a grillé. Je l’ai donc installé sur un autre PC, et la c’est la carte graphique qui est morte. Comme quoi le SGBD d’Oracle est un très bon surconsommateur de ressource. Si on arrive a l’installé sur un PC, alors on peu dire qu’il a au moins plusieurs mois à vivre.

     Connectez-vous pour répondre ↓
106. Zabriskir 21 juillet 2010 à 13 h 42 min

     Que pensez-vous de Firebird ?
     J’ai des problèmes de performances sur une application propriétaire qui tourne avec Firebird. Je ne sais pas si cela vient du SGBD lui-même ou des développeurs de l’appli…

     Très bon billet.

     Connectez-vous pour répondre ↓