+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2013
    Messages
    189
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2013
    Messages : 189
    Points : 4 648
    Points
    4 648
    Billets dans le blog
    1

    Par défaut PostgreSQL surpasserait MySQL et MariaDB en lecture ?

    PostgreSQL surpasse-t-il MySQL et MariaDB en lecture ?
    Un ingénieur logiciel partage son test de performance des trois systèmes de gestion de bases de données

    Faire le choix de la base de données à utiliser dans un projet peut être un choix difficile pour un développeur dans des petites équipes de développements où une même personne peut accumuler plusieurs rôles à la fois. Dans certaines équipes il n’est pas rare que le développeur joue en même temps le rôle de concepteur de bases de données par exemple. Pour aider ses pairs dans leur choix technologique, un ingénieur logiciel partage les résultats de son test de performance avec la communauté. Ce qui a retenu son attention, souligne-t-il, c’est les performances de Postgres en lecture. D’après les résultats publiés par l’auteur du test de performance, MariaBD et MySQL ont pris les devants quand il s’agit des requêtes d’écriture en base de données. Cependant pour les requêtes de lecture en base de données, Postgres s’est démarqué de manière assez nette des deux autres aussi bien pour des requêtes simples que les requêtes complexes.

    L’environnement utilisé par l’auteur du Benchmark est Ubuntu Wily Werwolf qui est la version 15.10 du système d’exploitation utilisé sur une machine avec un environnement processeur monocœur et une capacité de 1024 Mo de mémoire RAM. Pour les versions des systèmes de gestion de bases de données utilisés, il s’agit de la version 10.1.11 de MaraiDB, la version 5.7.10 de MySQL et de la version 9.5.0 de Postgres. La figure suivante représente les différentes requêtes de lecture en base de données qui ont été faites sur les trois systèmes de gestion de bases de données.

    Nom : Screen Shot 2016-02-13 at 15.48.21.png
Affichages : 8822
Taille : 74,1 Ko

    Les bons résultats obtenus avec Postgres pourraient s’expliquer d’après l’auteur du benchmark par le fait que ce système de gestion de bases de données respecte les standards SQL, en tout cas plus que les deux autres.

    Source : résultats du benchmark

    Et vous ?

    Avez-vous testé les performances de ces différents systèmes de gestion de bases de données ?

    Vos résultats confirment-ils les performances de Postgres par rapport aux deux autres ?

    Voir aussi

    la rubrique Bases de données

  2. #2
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 516
    Points : 5 626
    Points
    5 626

    Par défaut

    Bonsoir,

    quelques remarques concernant ce sujet :
    Citation Envoyé par Victor Vincent Voir le message
    Faire le choix de la base de données à utiliser dans un projet peut être un choix difficile pour un développeur
    - Les développeurs n'ont jamais eu leur mot à dire quand au choix de la base de données
    - Les performances sont rarement le critère de choix de la base, le budget intervient le plus souvent en premier, et les compétences en interne dans l'entreprise sont en général le 2eme critère
    - Si la performance des requetes est un critère de choix, alors pourquoi privilégier les requetes en lecture, plutôt que celles en màj ? pour des infocentres, oui, mais en ce cas aucun des 2 sgbd cités n'est concerné
    - toutes choses égales par ailleurs, My SQL présente de telles lacunes, que le choisir pour une base de données d'entreprise est un choix risqué

  3. #3
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 760
    Points
    18 760
    Billets dans le blog
    15

    Par défaut L'auteur du deuxième Quote est bien escartefigue et non Victor Vincent

    Bonsoir,


    Citation Envoyé par Victor Vincent
    Les bons résultats obtenus avec Postgres pourraient s’expliquer d’après l’auteur du benchmark par le fait que ce système de gestion de base de données respecte les standards SQL, en tout cas plus que les deux autres.
    Bigre ! Qu’est-ce que la norme SQL vient faire dans cette histoire ? Elle traite du Quoi, plutôt que du Comment ! Si l’auteur parlait de la supériorité de l’optimiseur du SGBD, de la structure des espaces physiques, index et autres éléments sous le capot, soit. Mais pour comparer, encore faut-il être très pointu à la fois sur toutes ces choses quant aux SGBD dont il est question, or il est pratiquement impossible d’être spécialiste dans les tréfonds de plus d’un SGBD. Ainsi, il est des études comparatives et autres benchmarks qui laissent songeur, tel celui-ci...



    Citation Envoyé par escartefigue
    Si la performance des requêtes est un critère de choix, alors pourquoi privilégier les requêtes en lecture, plutôt que celles en màj ? pour des infocentres, oui, mais en ce cas aucun des 2 sgbd cités n'est concerné.
    Voilà des paroles frappées au coin du bon sens !

    Pour ce qu’il en est de lire le plus vite possible des tables comme celle du benchmark (j’utilise le singulier : « celle », car je n’ai pas vu de jointure ou d’union, mais peut-être suis-je mauvaise langue, la table « testing » est-elle en fait une vue de jointure et/ou d’union ? ), les fichiers plats (même sophistiqués comme ceux qui utilisent VSAM d’IBM) sont sans doute les meilleurs candidats...

    Mais, comme le sous-entend escartefigue, faire des mises à jour concurrentes, avec célérité, en toute sécurité et sans gêner les voisins, c’est une autre paire de manches, comparer en toute objectivité devient bigrement compliqué, il faut faire intervenir des DBA expérimentés, spécialistes de leur SGBD respectif...

    Cela dit, comme le fait encore observer escartefigue, MySQL est sans doute un choix risqué, mais, pour ma part, ne l’ayant pas suffisamment secoué pour prétendre être véritablement spécialiste de ce SGBD, je suis obligé de suivre la proposition 7 de Wittgenstein (même chose au sujet de PostgreSQL)...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  4. #4
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 516
    Points : 5 626
    Points
    5 626

    Par défaut

    Citation Envoyé par fsmrel Voir le message
    Voilà des paroles frappées au coin du bon sens !
    Attention, ces propos étaient les miens, Victor Vincent pourrait en prendre ombrage

  5. #5
    Membre régulier
    Homme Profil pro
    Inscrit en
    décembre 2012
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : décembre 2012
    Messages : 44
    Points : 123
    Points
    123

    Par défaut

    quand on voit pour la même requête :

    MariaDB : 741 ms
    Mysql : 6686 ms
    PostgreSQL : 229.33 ms

    voir un tel écart avec mysql sur la même requête et la même architecture physique, ça me laisse seulement penser qu'il y a un soucis ailleurs et me fait douter fortement du benchmarK

    Après je n'ai pas une connaissance assez approfondie des SGBD

  6. #6
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 094
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 094
    Points : 2 586
    Points
    2 586
    Billets dans le blog
    10

    Par défaut

    Avez-vous testé les performances de ces différents systèmes de gestion de bases de données ?
    Oui, j'ai même réalisé un benchmark (fin 2014) mais comme les données avaient étés généré aléatoirement et que le système de transaction par défaut diffère entre les deux bases, je considère remettre à jour mon article car tel qu'il est je le considère un peu obsolète.

    Vos résultats confirment-ils les performances de Postges par rapport aux deux autres ?
    Oui et non. L'auteur a fait en sorte de prendre les cas où Postgres bat ses concurrents. Par expérience je peux dire que Postgres gère mieux quand :
    • Une requête contient des fonctions d’agrégat (sum, max etc)
    • Une requête retourne plusieurs centaines de tuples.
    • Une requête contient beaucoup de jointure.


    Par contre MySQL bat PostgreSQL sur ce type de requête simple :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT champ1, champ2 FROM ma_table WHERE id = 1;
    Pas de fonction d'agrégat, simple tuple en retour (généralement moins de 50 tuples), pas (ou peu) de jointure.

    Pour ce qui est des insertions mon test mettait en avant PostgreSQL, mais je n'avais pas pris en compte que MySQL faisait des auto-commit Bon après pour le cas d'une base entre insertion et lecture, on sait que les cas de lecture sont plus importants que l'écriture.

    Ma conclusion : PostgreSQL reste plus polyvalent, MySQL semble plus adapté pour les sites web simples qui ne nécessitent pas de requêtes complexes.


    PS :
    Coquilles :
    Psostgres en lecture
    Postgres en lecture
    Postges par rapport aux deux autres
    Postgres par rapport aux deux autres
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  7. #7
    Responsable Livres

    Avatar de MaitrePylos
    Homme Profil pro
    DBA & Dev PHP
    Inscrit en
    juin 2005
    Messages
    4 412
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA & Dev PHP
    Secteur : Service public

    Informations forums :
    Inscription : juin 2005
    Messages : 4 412
    Points : 10 111
    Points
    10 111

    Par défaut

    Citation Envoyé par Gugelhupf

    Par contre MySQL bat PostgreSQL sur ce type de requête simple
    Avec quel moteur ? myIsam ou InnoDb ?

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 760
    Points
    18 760
    Billets dans le blog
    15

    Par défaut

    Bonjour,


    Citation Envoyé par escartefigue
    Attention, ces propos étaient les miens, Victor Vincent pourrait en prendre ombrage
    Dont acte, distraction de ma part, merci à Victor Vincent d'avoir rectifié...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #9
    Expert éminent Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    2 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 77
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 2 402
    Points : 7 201
    Points
    7 201

    Par défaut

    Salut à tous.

    @ Gugelhupf : tu ne serais pas lorrain, par hasard ? Je dis cela car en Alsace, on écrit plutôt kouglouf, et en Allemagne Kugelhupf.

    J'ai regardé ton benchmark que je trouve bien plus intéressant que le message de "Victor Vincent".
    J'ai jeté un coup d’œil dans la partie MySql et je trouve que rien n'est optimisé. Inversement, je ne connais pas Postgre.

    Voici quelques remarques (juste un survol) concernant les différents points de ton sujet :

    1) hormis les primary key et foreign key de tes trois tables, je ne voie rien concernant le choix du moteur, du charset, du collation, ainsi que l'usage de la compression ou pas.
    Il serait plus opportun d'adapter tes tables à chaque SGBDR au lieu de faire quelque chose de standard.

    Concernant les déclaratives de tes index (une foreign key, c'est déjà un index), il ne manque rien, vis-à-vis de tes requêtes.
    Il suffit de faire un explain pour se rendre compte de son utilisation.

    2) tu fais usage des nombres aléatoires, d'accord.
    Mais pour tester les performances, il faut que tes données soient aussi exactement les mêmes.
    Or cela ne sera pas le cas ! Il faut adopter une autre méthode que les nombres aléatoires.

    3) tes deux premiers tests sont très similaires dans la façon dont tu gères les insertions
    Je fais aussi une procédure stockée afin de simuler les insertions.
    Je prends un exemple que j'ai fait chez moi, j'ai charger dans une table 'test' 1.000.000 de lignes.
    Heure Début : 13:15:32,53
    Heure Fin : 13:16:33,78

    Soit en gros 1 Minute 1 Seconde et 25 Centièmes ! Alors que tu indiques 25 min 4.53 sec !
    Il y a un très sérieux problème avec l'optimisation !!!

    4) tu fais "select *". Il faut éviter d'extraire des colonnes dont tu n'as pas besoin.

    5) tu fais une jointure, d'accord, mais j'aimerai que tu précises quel type de jointure.
    Un "inner join", un "left outer join", autre chose ... Je n'aime pas les déclaratives par défaut.

    6) quand tu as trois tables en jointure, il y a un ordre à respecter.
    En général, on commence par la table charnière (je réutilise ton vocabulaire).
    Et ensuite, on fait le jointure sur les autres tables.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin
    FROM t_charniere_medecin_patient MP
    INNER JOIN t_medecin M
    ON M.id = MP.id_medecin
    INNER JOIN t_patient P 
    ON P.id = MP.id_patient;
    Inversement, si tu veux optimiser tes accès, commence par les tables les plus petites.

    7) Un exemple mal formulé :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin 
    FROM t_charniere_medecin_patient MP
    INNER JOIN t_medecin M
    ON M.id = MP.id_medecin
    INNER JOIN t_patient P 
    ON P.id = MP.id_patient
    WHERE M.id  = 40;
    Pourquoi faire un "where M.id = 40" ?
    Car en faisant cela, tu récupères tout, puis ensuite, tu sélectionnes ce dont tu as besoin.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin 
    FROM t_charniere_medecin_patient MP
    INNER JOIN t_medecin M
    ON  M.id = MP.id_medecin
    AND M.id = 40
    INNER JOIN t_patient P 
    ON P.id = MP.id_patient
    WHERE M.id  = 40;
    8) il y a des images qui ne s'affichent plus dans ton didacticiel. Du coup, je voie nul part tes explain ???
    Il serait très utile de voir ce qui a été fait sur ce point.

    9) tu as fait l'effort de créer un benchmark entre MySql et Postgre. C'est très bien d'avoir pris le temps de le faire.
    Mais tu devrais donner les valeurs moyennes en lançant, disons un milliers de fois, chaque test !
    Un seul test par cas n'est pas représentatif d'un bon benchmark.

    10) qu'est-ce qui a été fait en terme de paramétrage système pour MySql et Postgre ?
    C'est le cœur même du SGBD qui va rendre optimal tes accès.
    Tu as beau rajouter des index, ou faire des explains, si le paramétrage est mal fait, tu n'obtiendras rien de bon.

    10) en conclusion, je considère que vos tests ne sont pas très représentatif de ce que l'on peut obtenir.
    C'est comme si tu veux comparer une ferrari et une 2CV. Et pour ce faire, tu conduis en restant que sur la premier vitesse.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  10. #10
    Membre du Club
    Inscrit en
    mai 2008
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 18
    Points : 53
    Points
    53

    Par défaut

    Citation Envoyé par fsmrel Voir le message
    Bigre ! Qu’est-ce que la norme SQL vient faire dans cette histoire ?
    Rien effectivement, l'auteur du blog n'a jamais dit ça... Victor Vincent ne lit probablement pas très bien l'anglais d'où sa confusion.

  11. #11
    Membre émérite
    Avatar de RyzenOC
    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    2 847
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 2 847
    Points : 2 399
    Points
    2 399
    Billets dans le blog
    8

    Par défaut

    Pour faire des benchmark correcte faudrait prendre compte le dommaine d'application (site wordpress ou bigdata) et aussi utiliser des syntaxe optimisé (pour Orable DB par exemple)
    Par exemple les SGBD les plus performant pour des requêtes simple (un simple select par exemple) c'est la famille NoSQL, c'est très utilisé en big data.

    Sinon je m'étais laissé entendre dire que pour des petites BDD, Mysql était plus performant que postgres et inversement.
    J'imagine que les perf dépende aussi de la taille des tables.

    Concernant MySQL, c'est un sgbd un peu spéciale, car on peut choisir son moteur. MyIsam ou InnoDB, les 2 ont leurs forces et leurs faiblesses en terme de perf.
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  12. #12
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 094
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 094
    Points : 2 586
    Points
    2 586
    Billets dans le blog
    10

    Par défaut

    Citation Envoyé par MaitrePylos
    Avec quel moteur ? myIsam ou InnoDb ?
    InnoDb (c'était indiqué dans l'en-tête du tableau dans mon article).

    @Artemus24,

    1. Comme indiqué dans l'en-tête du tableau, il s'agit d'InnoDb, pour ce qui est du charset ou collation j'ai laissé les valeurs par défaut, je doute que ce soit un critère important car je ne fais pas de traitement particulier sur les chaines.

    2. C'est bien ce que je dis, je n'ai pas utilisé un fichier statique pour charger les données mais utilisé une fonction qui génère des valeurs random (même si on obtient le même nombre de tuple entre les deux bases), d'où 1 des 2 défauts que j'ai cité concernant mon benchmark.

    3. Ce n'est pas un défaut d'optimisation, c'est un problème chaise-clavier (moi ). Là tu fais référence au 2ème défaut de mon benchmark, je suis en mode auto-commit true, d'où le fait d'avoir un temps d'insertion aussi conséquent.

    4. Je fais SELECT * pour PostgreSQL et MySQL donc pas de souci, on considère qu'il faut récupérer tous les champs.

    5. Il s'agit d'une jointure interne, c'est la jointure par défaut (SQL-92 : If a <qualified join> is specified and a <join type> is not specified, then INNER is implicit).

    6. Je ne savais pas qu'il y avait un ordre à respecter (si tu as une référence n'hésite pas), moi j'ai tendance à commencer par la table la plus importante. Le terme "table charnière" ne vient pas de moi mais de mes professeurs.

    7. Pourquoi faire un "where M.id = 40" ? : parce que id = 40 n'est pas une condition de jointure, mais un élément variable. Je n'ai pas testé la différence entre les performances entre ON et WHERE, mais je suis sur que le SGBD optimise cela à la lecture de la requête.

    8. Les images font références à mon ancien site qui n'existe plus. Voici l'extrait du benchmark qui t'intéresse.

    9. Je dirais que c'est le 3ème défaut de ce benchmark, mais je vais être honnête, pour faire un vrai benchmark il faudrait des outils adaptés, à l'époque je n'en connaissais pas et nous étions à court de temps pour fournir nos benchmark, et second problème ces outils sont spécifiques aux bases, ils sont tous différents et on ne sait pas comment ils sont implémentés. Mais bon j'ai tout de même exécuté ces requêtes plusieurs fois, il n'y avait pas de grosses différences.

    10.1. Aucune optimisation particulière n'a été effectuée, nous avons les paramètres par défaut pour les deux systèmes (si tu connais aussi bien MySQL tu sais tout). J'imagine que les éditeurs font en sorte de distribuer leurs logiciels avec les paramètres les plus nazes qui soient, et que ce soit à nous de tuner leur outil.

    Bon je dis ça pour plaisanter N'hésite pas à dire comment tu aurais tuné pour faire le benchmark.

    10.2. Critique subjective, n'hésite pas à nous faire un benchmark, nous verrons ce qu'il vaut.

    Non je ne suis pas lorrain, je pensais à l'Alsace lorsque j'ai créé mon pseudo, je ne suis pas alsacien non plus, juste un gueux de parisien
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 760
    Points
    18 760
    Billets dans le blog
    15

    Par défaut

    Bonsoir,


    Citation Envoyé par lecbee
    Citation Envoyé par fsmrel
    Bigre ! Qu’est-ce que la norme SQL vient faire dans cette histoire ?
    Rien effectivement, l'auteur du blog n'a jamais dit ça... Victor Vincent ne lit probablement pas très bien l'anglais d'où sa confusion.
    L’auteur du benchmark, a bien fait mention de la norme SQL, je le cite :

    « As a result, I think that choosing PostgreSQL is a better options for RDBMS - provided that PostgreSQL comes with more features and following standard SQL. »
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 760
    Points
    18 760
    Billets dans le blog
    15

    Par défaut D’amour mourir me font, belle Marquise, vos beaux yeux...

    Bonsoir,


    Citation Envoyé par Artemus24
    6) quand tu as trois tables en jointure, il y a un ordre à respecter.
    En général, on commence par la table charnière (je réutilise ton vocabulaire).
    Et ensuite, on fait le jointure sur les autres tables.
    Pourquoi respecter un tel ordre ? Et s’il y a 10 tables « charnières » à joindre, par quel bout commence-t-on ? Au passage, je fais observer que la jointure naturelle est une opération commutative et associative, faisant que l’ordre ne joue pas.



    Citation Envoyé par Artemus24
    Inversement, si tu veux optimiser tes accès, commence par les tables les plus petites.
    S’il s’agit là encore d’un ordre à respecter, autant dire qu’un optimiseur s’en tamponne le coquillard ! Il sait ce qu’il a à faire et comment le faire.



    Citation Envoyé par Gugelhupf

    Citation Envoyé par Artemus24
    Pourquoi faire un "where M.id = 40" ?
    Car en faisant cela, tu récupères tout, puis ensuite, tu sélectionnes ce dont tu as besoin.
    7. Pourquoi faire un "where M.id = 40" ? : parce que id = 40 n'est pas une condition de jointure, mais un élément variable. Je n'ai pas testé la différence entre les performances entre ON et WHERE, mais je suis sur que le SGBD optimise cela à la lecture de la requête.
    Vous avez parfaitement raison, Gugelhupf, c’est bien le SGBD qui optimise.

    En fait, "where M.id = 40" correspond à l’opération relationnelle de restriction. Il est évident qu’un optimiseur quel qu’il soit va commencer par effectuer cette opération qui est la plus rentable de toutes quant aux performances (sous réserve bien sûr que l’on ait défini l’index ad-hoc).

    Ainsi, que l’on code « Belle Marquise, vos beaux yeux me font mourir d’amour » :

    
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin 
    FROM t_medecin M 
    JOIN t_charniere_medecin_patient MP 
    ON M.id = MP.id_medecin 
    JOIN t_patient P 
    ON P.id = MP.id_patient
    WHERE M.id  = 40
    ;
    
    
    Ou bien « D’amour mourir me font, belle Marquise, vos beaux yeux » :

    
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin 
    FROM t_medecin M, t_charniere_medecin_patient MP, t_patient P 
    WHERE M.id = MP.id_medecin 
    AND P.id = MP.id_patient
    AND M.id  = 40
    ;
    
    
    ou encore « Vos yeux beaux d’amour me font, belle Marquise, mourir » :

    
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin 
    FROM t_charniere_medecin_patient MP
    INNER JOIN t_medecin M
    ON  M.id = MP.id_medecin
    AND M.id = 40 
    INNER JOIN t_patient P 
    ON P.id = MP.id_patient
    WHERE M.id  = 40;
    
    
    Eh bien, un optimiseur n’en a cure car, comme aurait dit Monsieur de La Palice, sa mission c’est ... d’optimiser ! Dans tous les cas, il applique donc d’abord la restriction très juteuse « where M.id = 40 », ce que montre bien un EXPLAIN, même avec MySQL :

    1re requête :




    2e requête :




    3e requête :






    Citation Envoyé par Artemus24
    une foreign key, c'est déjà un index
    Les auteurs de MySQL en ont certes décidé ainsi, mais c’est un diktat insupportable, une erreur de leur part, ils confondent les niveaux, relationnel d’une part, physique d’autre part. Une clé étrangère (foreign key) d’une table T1 n’est pas un index, mais une référence à une clé candidate (voire une surclé) d’une table T2 (non nécessairement distincte de T1). On est en l’occurrence au niveau relationnel. Sorti de MySQL, que le DBA décide au niveau physique de mettre en œuvre pour T1 un index dont les colonnes sont celles de la clé étrangère, pourquoi pas, mais seulement en cas de nécessité, il est le seul juge.


    Par exemple, avec PostgreSQL, sans index sur la colonne id_medecin, la requête ci-dessous va provoquer un balayage complet de la table t_charniere_medecin_patient :

    select * from t_charniere_medecin_patient where id_medecin = 40 ;

    =>

    "Seq Scan on t_charniere_medecin_patient "

    Avec un tel verdict de la part de l’optimiseur, on créera un index, mais là encore, c’est une décision du DBA (après tout, pour une table de quelques lignes, genre titres de civilité, le jeu n’en vaut sans doute pas la chandelle). Dans le cas présent, avec PostgreSQL, on codera par exemple :

    create index t_charniere_medecin_patient_x1 on t_charniere_medecin_patient (id_medecin) ;

    Et notre DBA peaufinera dans la soute, jusqu’à ce qu’il obtienne la performance recherchée. En passant, avant de s’occuper de la performance, afin d’éviter que cette table ne se transforme en « sac à tuples » (présence de doublons, donc mise en danger de l’algèbre relationnelle qui ne sait opérer correctement que sur des ensembles), il la dotera d’une clé primaire {id_medecin, id_patient} (avec pour conséquence la mise en œuvre implicite ou non de l’index de type UNIQUE correspondant...)



    5) tu fais une jointure, d'accord, mais j'aimerai que tu précises quel type de jointure.
    Un "inner join", un "left outer join", autre chose ... Je n'aime pas les déclaratives par défaut.
    Les sentiments ne sont pas de mise ! SQL est un langage pour lequel il existe une norme, et il y est écrit (cf. par exemple WG3:HBA-003 = H2-2003-305 = 5WD-02-Foundation-2003-09, WD 9075-2 (SQL/Foundation), September, 2003, aux pages 312-313) :


    7.7 <joined table>

    Function

    Specify a table derived from a Cartesian product, inner join, or outer join.

    Format

    <joined table> ::=
    <cross join>
    | <qualified join>
    | <natural join>

    <cross join> ::=
    <table reference> CROSS JOIN <table factor>

    <qualified join> ::=
    <table reference> [ <join type> ] JOIN <table reference> <join specification>

    <natural join> ::=
    <table reference> NATURAL [ <join type> ] JOIN <table factor>

    <join specification> ::=
    <join condition>
    | <named columns join>

    <join condition> ::= ON <search condition>

    <named columns join> ::= USING <left paren> <join column list> <right paren>

    <join type> ::=
    INNER
    | <outer join type> [ OUTER ]

    <outer join type> ::=
    LEFT
    | RIGHT
    | FULL

    <join column list> ::=
    <column name list>

    Syntax Rules

    [...]

    3) If a <qualified join> or <natural join> is specified and a <join type> is not specified, then INNER is implicit.

    [...]


    La norme ayant décrété (dès SQL:1992, il y a donc belle lurette !) qu’INNER était implicite, chacun est libre d’en faire usage ou non. Maintenant, si les règles en vigueur dans l’entreprise imposent INNER (ou NATURAL ou USING, etc.), chacun devra évidemment se conformer à ces règles.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  15. #15
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2009
    Messages
    974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : avril 2009
    Messages : 974
    Points : 1 987
    Points
    1 987

    Par défaut

    J'ajouterai que le fait d'inclure un LIMIT dans un requête non ordrée et un non sens total.

    Comment voulez-vous prendre les x premiers enregistrements d'un ordre non déterminé ? Encore pire c'est souvent matérialisé par le SGBD par une opération de tri (sur on ne sait pas quoi, merci la pertinence du benchmark Mme Irma) et ça peut se transformer en un tueur de performance sur certaines requêtes.

    Je passerai rapidement sur le post indiquant qu'il faut mettre une condition de sélection sur la jointure, s'il a déjà été expliqué que ça ne change rien au niveau de l'interpréteur de requête du SGBD, ça change énormément au niveau de l'interpréteur ICC (détruit la lisibilité de la requête, augmente le risque d'erreur en maintenance en devant modifier la variable de condition à plusieurs endroits). J'en ai encore les yeux qui saignent.

    C'est un article/benchmark sponsorisé par les fabricants de pince à couder les néons ?

  16. #16
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 516
    Points : 5 626
    Points
    5 626

    Par défaut

    Citation Envoyé par sinople Voir le message
    J'ajouterai que le fait d'inclure un LIMIT dans un requête non ordrée et un non sens total.
    Tout à fait d'accord, sauf le cas particulier où l'on souhaite prélever un échantillon quelconque parmi une population
    Cas d'espèce : identifier quelques lignes pour un test, on filtre avec where les cas de tests souhaités et on limite avec LIMIT (ou autre selon le SGBD) pour ne retenir que les n 1ers cas.

  17. #17
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2009
    Messages
    974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : avril 2009
    Messages : 974
    Points : 1 987
    Points
    1 987

    Par défaut

    Sous SQL Server, J'ai déjà vu des requêtes sur des vues ou le simple fait d'enlever le TOP(200) mis par défaut par le management studio faisait passer le temps d'exécution de 5 secondes à 0.00 secondes (en affichant plus de ligne...).

    Dans certains cas, je presque certain que les TOP, LIMIT (ou autre syntaxe) forcent une opération de tri.

    J'ajouterai que d'effectuer un benchmark de tri sur des données non standardisée c'est aussi relativement dangereux (et donne surtout un résultat non fiable).

  18. #18
    Expert confirmé
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    février 2005
    Messages
    3 379
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : février 2005
    Messages : 3 379
    Points : 5 413
    Points
    5 413

    Par défaut

    Citation Envoyé par Artemus24 Voir le message
    Salut à tous.
    ...
    6) quand tu as trois tables en jointure, il y a un ordre à respecter.
    En général, on commence par la table charnière (je réutilise ton vocabulaire).
    Et ensuite, on fait le jointure sur les autres tables.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT 
        P.*, 
        M.nom AS nom_medecin, 
        M.prenom AS prenom_medecin
    FROM t_charniere_medecin_patient MP
    INNER JOIN t_medecin M
    ON M.id = MP.id_medecin
    INNER JOIN t_patient P 
    ON P.id = MP.id_patient;
    Inversement, si tu veux optimiser tes accès, commence par les tables les plus petites.
    ....
    @+
    -4000 .Nimp ! Lorsque tu créés une jointure c'est pas toi qui décide, c'est le moteur qui décide du meilleur ordre de lecture de la table à moins que tu le forces via un mot clé à placer dans la requête mais c'est extrêmement rare de l'employer.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  19. #19
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 57
    Points : 84
    Points
    84

    Par défaut

    ♪♫ MySQL ... SGBD ...

    Pourquoi pas faire une comparaison avec Access tant qu'on y est ?

  20. #20
    Membre éprouvé Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2007
    Messages
    416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : juin 2007
    Messages : 416
    Points : 931
    Points
    931

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    - Les développeurs n'ont jamais eu leur mot à dire quand au choix de la base de données
    A part contraintes techniques particulières, j'ai toujours utilisé ce que je voulais comme bases de données (Postgres en l’occurrence).
    D'ailleurs pour mon dernier projet on m'a suggéré Mysql sur Windows ... je suis en train de configurer Postgres sur Debian ;-)
    Mais bon je bosse dans une petite structure, j'imagine que c'est pas partout pareil.
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

Discussions similaires

  1. MySQL / PostgreSQL / MariaDB
    Par Oxore dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 16/04/2016, 12h13
  2. Red Hat Enterprise Linux 7 Beta abandonne aussi MySQL pour MariaDB
    Par Cedric Chevalier dans le forum RedHat / CentOS / Fedora
    Réponses: 6
    Dernier message: 24/12/2013, 15h53
  3. Google va abandonner MySQL pour MariaDB
    Par Hinault Romaric dans le forum MySQL
    Réponses: 22
    Dernier message: 19/09/2013, 16h03
  4. Tables liées avec MySQL en lecture seule
    Par alex38 dans le forum Access
    Réponses: 5
    Dernier message: 20/04/2006, 13h32
  5. Faire une liste plus jolie de ma liste:lecture de base mysql
    Par CyberTwister dans le forum Requêtes
    Réponses: 8
    Dernier message: 17/02/2006, 00h31

Partager

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