Discussion :

[philnext]

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.

[Vladislav IV]

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.

[Marc Lussac]

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.

[Vladislav IV]

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.

[Marc Lussac]

On ne publie pas habituellement de communiqués de presse, mais je vais faire une exception pour faire taire un certain nombre d'amateurs inexpérimentés et incompétents qui spamment actuellement des propos faux sur un certain nombre de forums amateurs (pour une raison que j'ignore). Même si ce qui suis est présenté de façon spécialement "favorable", le fond est très certainement juste, et plusieurs très grandes sociétés ont obtenus des résultats tout à fait similaires :

Bonjour,

Le leader français des solutions logicielles pour les émetteurs de courrier industriel embarque MySQL 5.0 et divise par 400 les temps de traitement de ses applications.

Le directeur générale de Valispost, est à votre disposition pour commenter son choix et les bénéfices gagnés pour son entreprise et ses clients industriels.

Avec MySQL, Valipost affiche des performances inégalées en matière d’éditique

Le leader français des solutions logicielles pour les émetteurs de courrier industriel embarque MySQL 5.0 et divise par 400 certains temps de traitement de ses applications.

Paris, le 4 septembre 2007 – En choisissant la base de données open source MySQL pour sa suite logicielle, Valipost, la 1ère société Française agréée pour les systèmes d’impression SILOE® (*), augmente significativement ses performances, et permet à ses clients industriels de gagner en productivité, fiabilité et traçabilité.
La suite logicielle de Valipost permet à ses clients de bénéficier d’une solution d’éditique complète et modulaire pour faciliter les besoins de production et de préparation d’envois industriels de courriers (tri paramétrable, impression d'étiquettes, suivi, planification des productions et facturation). Capable de traiter le courrier de l’ensemble des postes européennes, en s’adaptant à chaque norme, la solution est suffisamment rapide pour optimiser financièrement les dépôts et gérer des fichiers de plusieurs Gigaoctets.

MySQL 5.0 couvre tous les besoins en haute disponibilité et performance de Valipost, en permettant le traitement de plus de 20 millions d’adresses à l’heure sur une machine bi processeurs.

L’application est hautement critique puisque 95% des systèmes de Valipost sont connectés en ligne avec les machines de production de courrier rapide. 170 clients de Valipost gèrent 8, 5 milliards de courriers, soit 3,25 milliards d’Euros d’affranchissement par an, et un seul arrêt du système pourrait s’avérer financièrement pénalisant pour les utilisateurs. Le développement d’un système de réplication de données permettant d’éliminer instantanément les modules ou machines défaillantes sur un serveur de secours confère une haute disponibilité à la solution. Les clients n’ont désormais plus de machines à affranchir, et les compteurs de plis sont directement enregistrés dans la base de données.

Tant au plan technique que fonctionnel, le choix de MySQL s’est imposé pour Valipost sur des critères d’évolutivité, de performance (bibliothèque d’accès en c++) et de sécurité, mais aussi pour la qualité de son support et de la formation, c’est pourquoi Valipost a souscrit aux services d’assistance technique « Gold » de MySQL.

Les solutions sont installées, préparées, pré-configurées et testées chez Valipost, puis déployées à l'identique chez les clients. Cette étape de préparation permet de gagner beaucoup de temps, pouvant être utilisée pour la formation du personnel exploitant.

Pierre coupé, Directeur Général de Valipost, explique : « Nous avons divisé par 400 certains temps de traitement de nos applications. La performance de MySQL et de nos systèmes permettent aujourd'hui de répondre aux besoins de simulation financière des dépôts postaux qui atteignent souvent plusieurs millions d'Euros. La fiabilité et la sécurisation des données nous ont permis de diminuer de 30% le support technique vers nos clients. Tout le monde y a gagné ».

(*) SILOE est le Système Informatisé de suivi des Lots Expédiés – Une norme logistique de La Poste pour identifier les contenants postaux.

À propos de Valipost

Crée en 2002 par Mrs Haddouche, Coupé et Danzin, la société Valipost est spécialisée dans le développement de logiciels pour les clients producteurs de courrier industriel. L’entreprise a construit une offre globale qui répond aux exigences de prévision et de suivi du courrier tant au niveau de la production qu’au niveau financier.

Grâce à une flexibilité accrue de ses logiciels, Valipost positionne déjà ses solutions en Europe, dans l’océan indien et les caraïbes sans attendre l’ouverture des marchés à la concurrence

En cinq années Valipost a installé 1250 postes SILOE® chez 170 clients. Les nouvelles normes postales pour le courrier publicitaire permettront d’atteindre les 4 milliards d’euros de facturation d’affranchissement qui transiteront par les systèmes installés.

Quelques références clients : La Société Générale, B.N.P, Crédit-Mutuel, Crédit Du Nord, CIC, Orange France, Groupe Diffusion Plus, La Redoute, Groupe 3suisses, Groupe Routex, AGF…

Aujourd’hui, pour répondre à cette croissance forte, à la demande internationale et dans le souci de toujours être plus proche du client, Valipost a rejoint le groupe Néopost depuis le 16 février 2007.

À propos de MySQL

MySQL AB développe et supporte une gamme de produits de base de données à hautes performances et abordables. L’offre phare de la société est MySQL Enterprise, une offre unifiée incluant une base de données de classe entreprise, services de surveillance, et assistance.

MySQL est la base de données Open Source la plus populaire au monde, avec plus de 11 millions d’installations actives. Beaucoup des sociétés les plus importantes et à forte croissance telles que Google, Yahoo ! Lafarge, EADS, Alcatel, Nokia et Youtube, réduisent de manière significative leurs coûts en utilisant MySQL pour leurs sites Web, leurs applications critiques d’entreprise, ou en embarquant MySQL au sein de leurs logiciels.

Le siège de MySQL AB est en Suède et aux Etats-Unis. Avec un terrain d’opération mondial et une présence en France, MySQL AB supporte à la fois les valeurs de l’Open Source et les besoins des entreprises de façon profitable et pérenne.

Pour plus d’informations sur MySQL, consultez le site : www.mysql.fr

MySQL est une marque déposée de MySQL AB aux États-Unis et dans d’autres pays. Les autres produits cités peuvent être des appellations commerciales de leurs détenteurs respectifs.

Valipost est une marque déposée de Valipost en France. Les autres produits cités peuvent être des appellations commerciales de leurs détenteurs respectifs.

[mlequim]

Bonjour,

J'hésite justement dans le choix d'une base de donnée. Je développe une petite application en JAVA (swing) que j'aimerais vendre, j'ai donc besoin d'embarquer une base de donnée.

Je lis dans ce forum que MySQL et PostGreSQL ne sont pas chèr, mais je me demandais s'il existait une SGBD totalement gratuite à embarquer dans des logiciels commerciaux ? Je recherche une base de donnée qui serait compatible avec un générateur gratuit de rapports (je pense que je vais prendre Birt). Au pire si rien de gratuit n'existe je recherche la solution la moins chère car je ne suis pas sur de vendre le programme que je crée. Quelqu'un à t'il aussi une idée approximative du prix de MySQL ou PostGRE lorsqu'ils sont embarqués ?

Pour le moment je penche vers la combinaison BIRT / MySQL.


Merci d'avance pour votre aide.

[Davboc]

Aux dernières nouvelles PostgreSQL est gratuit quelquesoit l'usage, tandis que mysql est payant lorsque l'on veut que le code soit fermé.

Donc PostgreSQL semble être le mieux adapté pour toi, mais je ne connais pas Birt donc je ne saurai t'en dire plus

[Linio]

Aux dernières nouvelles PostgreSQL est gratuit quelquesoit l'usage, tandis que mysql est payant lorsque l'on veut que le code soit fermé.

Tu peux être plus clair?

Je fais une appli php&mysql, je dois m'inquiéter?

[mlequim]

je viens de voir que PostGreSQL fonctionne avec BIRT, donc c'est parfait !

merci pour ton aide

[mlequim]

Tu peux être plus clair?

Je fais une appli php&mysql, je dois m'inquiéter?

J'ai lu que si tu inclu mysql dans une application que tu distribues et que tu veux la commercialiser il faut payer une licence commerciale.

[Marc Lussac]

C'est expliqué dans la F.A.Q MySQL

[Linio]

Je ne distribue rien, et c'est un produit à but non lucratif, donc ça doit être bon pour moi.

Merci pour le renseignement.

[Jean-Marc68]

Salut à toutes et à tous,

Actuellement en phase de recherche du système de BDD que nous allons utiliser, voici mes tendances du moment.

D'avance nous savons que nous allons avoir une micro (au pire une mini) BDD avec très peu d'utilisateurs (max 30). Je vois tout le monde crier "prend MySQL".
La où le porblème se pose c'est que nous travaillons dans une compagnie de géomatique, donc avec de gros besoins en SIG. "Ben prend PostgeSQL et PostGIS."

Ben justement, je ne sais plus trop lequel prendre. Vu la grosseur et la quantité de requêtes, MySQL semble mieux, mais tout ce qu'il gère en géométrie est un point 2D en MYISAM (donc sans gestion d'intégrité etc ...). Autant vous dire qu'on ne peur RIEN faire avec ça. Actuellement je me pense donc contraint et forcé d'utiliser PostgreSQL et PostGIS uniquement à cause de la géométrie.

Quelqu'un sait-il si une vraie gestion géométrique est prévue dans une prochaine version (pas dans 15 ans, mais disons quand quelques mois) de MySQL ou si elle exite déjà quelque part et que cela m'aurait échapé? Auquel cas je pourrais attendre un peu, mais pas indéfiniment.

Conclusion, je ne suis ni pro ni anti MySQL et pas plus pro ou anti PostgreSQL, mais je choisis PostgreSQL à cause des besoins spécifiques que j'ai. Je suis donc ouvert au changement si mes besoin étaient comblés en MySQL.

Jean-Marc

[Marc Lussac]

S'il n'y à pas de problème attendues de perfs, dans ce cas ce qui importe c'est les fonctionnalités dont vous avez besoin, et si vous avez besoin d'une fonctionnalité qui existe dans PostgreSQL dans ce cas le choix PostgreSQL me semble évident, je ne voie pas très bien ou est l'hésitation ?

J'ai déjà expliqué que MySQL à toujours la faveur de la grand majorité des hébergeurs Web par sa capacité à servir massivement et à peu de cout RAM et CPU un trés grand nombre de requêtes simples, mais si vous n'êtes pas dans ce cas de figure, de prendre le SGBD qui vous offre le plus de fonctionnalités, comme PostGreSQL semble être le choix évident.

[jnore]

Moi non plus je ne vois pas où est le problème !

Au niveau perf je ne suis pas sûr qu'un utilisateur puisse faire une différence entre Mysql et Postgresql même avec un chrono à la main !!

On rentre ici, à mon avis, dans un débat qui n'a pas (ou plus) lieu d'être.

Par contre au niveau fonctionalité, "je pense" que Postgres prend le dessus, notamment avec son langage PL/PGSQL qui a fait ses preuves depuis longtemps.
Le module GIS est étonnament complet et puissant, et on peut féliciter les équipes de développement pour ce projet bien élaboré.(Il manque juste davantage de documentation).


Mysql a accusé un retard qu'il commence à ratraper, pour le bonheur de tous les utilisateurs de ce SGBD.

[azertyman]

Il suffit de dotter le SGBD d'un serveur digne de ce nom et l'utisateur aura l'impression que c'est sa machine qui fait les calculs

[kedare]

j'ai l'impression que plus le temp passe , plus mysql grimpe sur postgresql (meme si perso je prefere pgsql), par exemple le fait d'avoir plusieurs moteurs de stockage (en contrepartie ils ne sont pas dispo partout , par exemple innodb n'est pas activé sur free), et la syntax parfois plus simple (genre les SHOW pour afficher des informations utile alors qu'on doit generalement passer par un select assez complexe sur postgresql)
par contre au niveau des langages procedurales mysql a l'air toujours en retard :/
j'ai pas vu postgresql beaucoup evolué ces derniers temps (sauf niveau performances depuis la 8.1)
qu'en pensez vous ?

[scheu]

Depuis peu il y a des avancées intéressantes sur postgresql, notamment le log shipping qui permet de répliquer une base quasiment en temps réel
Postgresql semble s'adapter beaucoup plus aux besoins de l'entreprise (haute dispo, sécurité, réplication, ...) alors que MySQL reste simple, grand public mais avec moins de fonctionnalités

[tnodev]

Bonjour

nous avons développé une application J2EE pour des intranet d'études de 5 à 60 personnes et nous avons longuement hésité entre MySql et postgreSql, et finalement, nous avons choisi postgreSql pour trois raisons :

1. aucun cout de licence dans le cadre d'une application commercial
2. gestion des séquences
3. gestion des transactions

Globalement, nous sommes très content de postgreSql, nous n'avons pas de souci majeur.

[kedare]

Depuis peu il y a des avancées intéressantes sur postgresql, notamment le log shipping qui permet de répliquer une base quasiment en temps réel
Postgresql semble s'adapter beaucoup plus aux besoins de l'entreprise (haute dispo, sécurité, réplication, ...) alors que MySQL reste simple, grand public mais avec moins de fonctionnalités

donc et pour un particulier ? tu pense que c'est quoi le plus adapté pour toute utilisation ?
tnodev: il me semble que mysql supporte les sequences et les transactions via InnoDB