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

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

Décisions SGBD Discussion :

Choisir Mysql ou PostGreSQL ? [Débat]


Sujet :

Décisions SGBD

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Par défaut
    Un comparatif intéressant sur le sujet, doublé d'un test de performances avec ses sources.

  2. #2
    Membre extrêmement actif
    Avatar de kedare
    Homme Profil pro
    SRE
    Inscrit en
    Juillet 2005
    Messages
    1 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Espagne

    Informations professionnelles :
    Activité : SRE

    Informations forums :
    Inscription : Juillet 2005
    Messages : 1 549
    Par défaut
    vu la sortit de mysql5
    que fait PostgreSQL et pas Mysql ?

  3. #3
    Membre Expert Avatar de philnext
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    1 553
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 1 553
    Par défaut
    Une nuance importante pour le choix est que, contrairement à beaucoup d'affirmations, dans le cas d'une application commerciale 'fermée', la licence est payante pour MySQL & gratuite pour PostGreSQL.

    Par contre dans le cas de besoin d'hébergement (Web) MySQL est largement plus répandu.

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    93
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 93
    Par défaut
    J'ai passé ces deux mois à développer une application Web 2 de gestion du courrier pour un organisme public, qui se basait auparavant sur MS Access.

    Tout juste sorti de l'école, j'ai voulu appliquer mes quelques connaissances, et principalement déporter la logique applicative dans la BDD. Ce fut tout simplement impossible.

    La gestion des contraintes d'intégrité semble d'abord inexistante, sauf quand on se torture la cervelle pour comprendre comment MySQL les gère. Il faut créer à la main des index sur chaque table, et ensuite indiquer les clés étrangères. En l'absence d'outil graphique, j'ai tapé mes scripts à la main, et j'ai rapidement abandonné ces contraintes, l'écriture devenant trop lourde.

    Les triggers sont suffisament primitifs pour que l'on puise les considérer comme inexistants : il est impossible de programmer un déclencheur exécutant des requêtes. Aucun intérêt.

    Les demi-jointures sont une horreur : on indique leurs conditions dans la clause FROM des requêtes de sélection. Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    SELECT *
    FROM a LEFT JOIN b ON a.id = b.id,
         c
    WHERE a.fk = c.id;
    Ca devient moins marrant quant on doit faire plusieurs demi-jointures :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    SELECT *
    FROM a LEFT JOIN b ON a.id = b.id,
         a2  LEFT JOIN d ON a2.id = d.id,
         c
    WHERE a.id = a2.id
    AND a.fk = c.id;
    En clair, pour N demi-jointures centrées sur une table, il faut faire apparaître N fois ladite table, avec bien sûr N-1 jointures totales de cette table sur elle-même. J'ai renoncé à aller au-delà de N = 2...

    Bref, MySQL est présenté comme mature. Avec ce que j'ai vu (et l'absence du type élémentaire qu'est le Booléen, soit dit en passant), je trouve que certains ont une étrange conception de la maturité, et un sacré culot de le comparer aux géants de ce monde.

    Pour ce qui est de la montée en charge, les quelques graphiques que j'ai vu récemment montrent une montée rapide de MySQL, puis une chute libre dès que le seuil maximal est atteint. PostgreSQL a la décence de maintenir son rythme en toute circonstances. A noter que les bases de données les plus importantes ne tournent pas sous MySQL. Mais c'est vrai que les bricoleurs font parfois des miracles...

    A ceux qui me répondront que "des tas d'entreprises tournent sous MySQL", je répondrai que si toutes les entreprises ne faisaient que des bons choix, aucune ne coulerai. Ce qui est loin d'être le cas.

    Pour ce qui est des hébergeurs Web, je tiens à souligner ce mot : Web. Que trouvez-vous dans le fichier clients de ces hébergeurs ? Quelques entreprises qui ont besoin d'une présence sur la Toile, et une majorité de particuliers. Ces derniers n'ont généralement pas les connaissances nécessaires à l'utilisation d'une BDD (c'est assez facile de cliquer sur "créer mon blog"). Dans tous les cas, un site ne demande pas la complexité, le contrôle et la rigueur qui justifiraient l'usage d'un SGBDR plus costaud. Et les entreprises qui ont un site vraiment poussé, l'hébergent la plupart du temps sur leurs propres serveurs.


    Pour conclure, je dirai qu'il ne faut pas oublier ce pour quoi MySQL a été créé : une utilisation personnelle. Le développeur en herbe serai bête de s'encombrer avec une usine comme PostgreSQL. Certaines applications n'ont pas besoin d'une telle complexité. Mais dès que l'on parle du domaine professionnel, j'entends par là non pas la vitrine de l'entreprise, ou la messagerie faite maison, mais bien de bases de données constituant le système d'information, on ne peut pas se permettre de gérer la cohérence des données avec trois scripts PHP.

    Je ne suis pas militant anti-MySQL, mais il ne faut pas se voiler la face : tant qu'il n'aura pas atteint le niveau de ses "concurrents", il se cantonnera logiquement à un rôle de service limité. Chaque chose à sa place.

  5. #5
    Rédacteur en Chef
    Avatar de Marc Lussac
    Homme Profil pro
    Responsable marketing opérationnel
    Inscrit en
    Mars 2002
    Messages
    28 683
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable marketing opérationnel
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2002
    Messages : 28 683
    Par défaut
    Vladislav IV,

    Pour ce qui est des fonctionnalités supérieures sur PostGreSQL, tous le monde est d'accord la dessus.

    Pour ce qui est des performances, je pense que vous n'avez pas bien compris que les performances diffèrent considérablement suivant les traitements faits, le nombre d'utilisateurs connectés, et le type de serveur. Par conséquent, vous trouverez toujours un bench ou PosgreSQL est devant MySQL et inversement.

    Le bench dont vous parlez, je le connais et il est totalement faussé car généralement mysql arrive à servir les requêtes en un temps record et il y à rarement plus de 10 connexions à la fois, alors un écrasement à plus de 100 users n'est que théorique vu qu'on dépasse jamais 10. Tout cela dépend d'un très grand nombre de facteurs comme le serveur, la ram, le type de traitement, de connexions, etc... Pire encore le bench dont vous parlez à été fait sur MySQL 4.X , qui lançait un process par tache, ce qui n'est plus le cas avec la version 5.X qui est capable comme Sybase de suporter x requetes avec un seul process... Bref ce bench est périmé.

    Si PosgreSQL était devant MySQL dans tous les cas, MySQL il aurait été abandonné par les hébergeurs et les gros sites, ce qui n'est pas le cas.

    Dans certains cas d'utilisation simples, et avec certains machines, MySQL est jusqu'à 2 fois plus rapide que PosgreSQL. Ce qui reviendrais pour un hébergeurs à multiplier son parc de machines par deux à et doubler ses couts, ce qui n'est pas rien...

    Certains hébergeurs ont même abandonné totalement PostgreSQL au profit de MySQL pour cette raison, et quand vous dites que MySQL n'est pas utilisé par les gros sites c'est faux archi faux.
    Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

    15 000 offres d'emploi développeurs et informatique
    Cours et tutoriels développeurs et informatique
    Les FAQ's & Les Livres
    Codes sources
    Téléchargements

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    93
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 93
    Par défaut
    OK tout le monde, je reprends sur un ton plus professionnel :

    MySQL :
    + Pas cher.
    + Léger.
    + Facile à mettre en oeuvre, à maintenir.
    + Interfacage avec tous les logiciels.
    + Dispo chez tous les hébergeurs.
    -----
    - Pas de Booléens (ça me vexe).
    - Pas de triggers exploitables.
    - Les demi-jointures sont affreuses (quand on les fait à la main).


    PostgreSQL :
    + Pas cher non plus
    + Plus de types de données, personnalisation des types.
    + Héritage.
    + Triggers complets.
    -----
    - Plus lourd à installer et configuer.
    - Moins accessible.
    - Moins de logiciels gratuits pour s'interfacer.
    - Très peu d'hébergeurs le proposent.


    Ca, c'est dit. Maintenant, voici ma vision des choses au niveau emploi :
    • Pour un particulier, MySQL fera toujours l'affaire.
    • Pour un site Web particulier ou pro, MySQL fait aussi l'affaire.
    • MySQL implique un fort couplage avec les applications. Si vous avez un système d'information avec des BDD centrales et plein d'applications satellites, il vaut mieux prendre un autre SGBDR (pour être dans le débat : Postgres).
    • Dans tous les cas où vous avez "une application - une BDD", MySQL fait l'affaire.
    • Si vous avez une BDD importante de votre SI (exploitée par plusieurs applis, données critiques, etc.) qui doit être accessible via l'Internet, je crois savoir que MySQL monté en première ligne (comme interface) peut servir à augmenter la sécurité et les performances.


    Edit : pour le dernier point, il me semble que certains ETL disposent de fonctionnalités temps-réel. C'est l'idéal dans ce type d'architecture : le logiciel ajoute un contrôle supplémentaire, et permet de facilement modifier ou rediriger les flux de données en cas de besoin.

  7. #7
    Membre Expert Avatar de Maximil ian
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 622
    Par défaut
    Langage procédural plus avancé avec support de plusieurs langages de programmation
    Triggers et vues plus avancés (triggers peu utilisables sous MySQL)
    Rôles
    Partitionnement de tables
    Index bitmap
    ...

  8. #8
    Rédacteur

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

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 001
    Billets dans le blog
    6
    Par défaut
    En terme de respect de la norme SQL PostgreSQL en est très près et MySQL très éloigné. Cela à son importance et pour deux raisons :
    1) la portabilité (ce n'est d'ailleurs pas pour moi le critère le plus important)
    2) l'intelligence relationnelle (ça c'est plus important !)

    Quand je voit des opérateurs anti relationnel dans mySQL comme LIMIT ou des types de données qui n'existe pas en SQl comme INT(2) je trouve que c'est de la même nature que ce qui à conduit IBM a être écartés par certains informaticiens : des trucs spécifiques, incongrus, inutiles, contre performants et dangereux afin de capter un marché et d'enferrer les utilisateurs sur MySQL.

    De plus le niveau transactionnel de MySQL est loin d'être satisfaisant alors que celui de PostGreSQL est même en avance sur Oracle ou SQL Server.

    De fait mon choix est vite fait, entre un gestionnaire de fichiers encapsulant du SQL et qui vient de se mettre récemment à faire (péniblement) des transactions et un vrai SGBDR transactionnel il n'y a pas photo, PostGreSQL et pas MySQL !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. De MySQL vers PostGreSQL
    Par vcaudron dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 11/06/2006, 11h48
  2. conversion mysql vers postgresql
    Par backus dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 04/07/2005, 18h42
  3. Migrer de MySQL vers PostgreSQL
    Par Acti dans le forum PostgreSQL
    Réponses: 9
    Dernier message: 25/02/2005, 14h20
  4. Mysql ou postgresql
    Par agro dans le forum Décisions SGBD
    Réponses: 10
    Dernier message: 22/10/2003, 13h01
  5. Réponses: 4
    Dernier message: 28/09/2002, 00h00

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