Un comparatif intéressant sur le sujet, doublé d'un test de performances avec ses sources.
Un comparatif intéressant sur le sujet, doublé d'un test de performances avec ses sources.
vu la sortit de mysql5
que fait PostgreSQL et pas Mysql ?
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.
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 :
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 SELECT * FROM a LEFT JOIN b ON a.id = b.id, c WHERE 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...
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;
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.
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
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.
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
...
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/ * * * * *
Partager