En fait, sur beaucoup de tes points, tu compares deux manières de fonctionner différentes : MySQL intègre plein de trucs dans la base alors que PostgreSQL a plus une philosophie de faire du SGBDR et c'est tout. MySQL est plus pragmatique ce qui a certains avantages, au mépris parfois de la cohérence, du fait que le comportement soit correct et du respect des standards.
Après, il est difficile de savoir ce qui va mieux te convenir. Je me suis limité ici aux points que tu as cités vu que ça doit être ce qui est important pour toi, je suppose.
> MySQL
--- Commande SHOW trés simple et pratique
Mouaif. C'est lesquels de SHOW que tu trouves pratique ?
--- Planificateur de tache intégré
Il existe pgAgent qui est configurable via pgAdmin III. Mais effectivement, ça demande un composant complémentaire. Personnellement, je préfère faire ce genre de trucs via une crontab.
--- Pas mal polyvalent grace aux différents moteurs, une base de donnée de cache par exemple n'a pas besoin de transactions
Well, une base de données, c'est fait pour conserver des données. Si tu veux du cache ou des sessions, memcached et sharedance sont probablement plus adaptés. Encore une fois, on retrouve la philosophie UNIX (une tâche, un outil) dans PostgreSQL.
--- Trés utilise, énormement de documentation
Je ne pense pas qu'on puisse le retenir contre PostgreSQL. La doc PostgreSQL officielle est vraiment une mine d'informations et le wiki commence à être bien rempli aussi.
--- Mode Embedded
Oui, ça, PostgreSQL ne le fait pas et ne le fera probablement jamais. Ce n'est pas son objectif.
Si tu as besoin de cela, il faut soit aller voir côté Sqlite, soit effectivement rester sur du MySQL.
--- Possibilités de monitoring énorme
C'est à dire ?
PostgreSQL a quelques outils pas mal non plus : des plugins Munin, un plugin Nagios très bien fichu, pgFouine...
--- Les bases de données prennent peut de place par apport a Postgresql
Euh ? Ca me paraît sorti du chapeau ça. J'ai notamment vu pas mal de gens se plaindre de la place prise par des bases InnoDB. Après, je dois avouer que le stockage est rarement un problème pour nous donc je n'ai jamais fait trop gaffe.
Je n'ai jamais eu l'impression d'avoir une taille déconnante, notamment parce que le stockage des champs en PostgreSQL est très optimisé et très souple, mais encore une fois, jamais trop fait gaffe.
--- Systeme de backup complexe dues aux differents moteurs, mais la 6.0 corrige ca si j'ai bien comprit
Attention quand même aux annonces MySQL. La 5.1 vient juste de sortir après 3 ans de développement. Je ne suis pas sûr qu'il faille compter sur une 6.0 rapidement (même si tout le monde espère qu'ils ne vont pas refaire le coup de la 5.1).
> PostgreSQL
> Ce que je n'aime pas :
--- Pas la possibilité de désactiver l'aspect relationnel sur certaines tables (pour une table de cache par exemple)
Répondu plus haut, PostgreSQL ne traite effectivement pas cette problématique, il y a d'autres outils pour ça.
--- Pas de commande show, donc certaines commandes sont assez complexes
Tu prends mal le problème là. Je ne suis pas persuadé que ce soit plus complexe mais même si ça l'est, si tu choisis un SGBDR pour un bout de temps, tu vas te construire ton petit référentiel de vues qui te remontent toutes les informations que tu veux comme tu les veux.
Je serai curieux de savoir ce que tu trouves complexe tout de même. Les versions récentes (genre la 8.3) sont vraiment simples à manipuler de ce point de vue là. Le fait que ce soit du SQL rend en plus les manipulations très simples et cohérentes : on peut faire des vraies requêtes.
--- Performances moins bonne que Mysql (surtout avec MyISAM quand l'on a pas besoin de transactionnel)
Dépend de ce que tu appelles performances. Ca dépend beaucoup de la complexité de tes requêtes, de ton nombre d'utilisateurs concurrents.
Bref, difficile à dire sans avoir une idée de la typologie de charge qu'il y aura.
# Quelques éléments
Posté par Guillaume Smet (site web personnel) . En réponse au message Quelle base de donnée open source est la plus polyvalente ?. Évalué à 8.
Après, il est difficile de savoir ce qui va mieux te convenir. Je me suis limité ici aux points que tu as cités vu que ça doit être ce qui est important pour toi, je suppose.
> MySQL
--- Commande SHOW trés simple et pratique
Mouaif. C'est lesquels de SHOW que tu trouves pratique ?
--- Planificateur de tache intégré
Il existe pgAgent qui est configurable via pgAdmin III. Mais effectivement, ça demande un composant complémentaire. Personnellement, je préfère faire ce genre de trucs via une crontab.
--- Pas mal polyvalent grace aux différents moteurs, une base de donnée de cache par exemple n'a pas besoin de transactions
Well, une base de données, c'est fait pour conserver des données. Si tu veux du cache ou des sessions, memcached et sharedance sont probablement plus adaptés. Encore une fois, on retrouve la philosophie UNIX (une tâche, un outil) dans PostgreSQL.
--- Trés utilise, énormement de documentation
Je ne pense pas qu'on puisse le retenir contre PostgreSQL. La doc PostgreSQL officielle est vraiment une mine d'informations et le wiki commence à être bien rempli aussi.
--- Mode Embedded
Oui, ça, PostgreSQL ne le fait pas et ne le fera probablement jamais. Ce n'est pas son objectif.
Si tu as besoin de cela, il faut soit aller voir côté Sqlite, soit effectivement rester sur du MySQL.
--- Possibilités de monitoring énorme
C'est à dire ?
PostgreSQL a quelques outils pas mal non plus : des plugins Munin, un plugin Nagios très bien fichu, pgFouine...
--- Les bases de données prennent peut de place par apport a Postgresql
Euh ? Ca me paraît sorti du chapeau ça. J'ai notamment vu pas mal de gens se plaindre de la place prise par des bases InnoDB. Après, je dois avouer que le stockage est rarement un problème pour nous donc je n'ai jamais fait trop gaffe.
Je n'ai jamais eu l'impression d'avoir une taille déconnante, notamment parce que le stockage des champs en PostgreSQL est très optimisé et très souple, mais encore une fois, jamais trop fait gaffe.
--- Systeme de backup complexe dues aux differents moteurs, mais la 6.0 corrige ca si j'ai bien comprit
Attention quand même aux annonces MySQL. La 5.1 vient juste de sortir après 3 ans de développement. Je ne suis pas sûr qu'il faille compter sur une 6.0 rapidement (même si tout le monde espère qu'ils ne vont pas refaire le coup de la 5.1).
> PostgreSQL
> Ce que je n'aime pas :
--- Pas la possibilité de désactiver l'aspect relationnel sur certaines tables (pour une table de cache par exemple)
Répondu plus haut, PostgreSQL ne traite effectivement pas cette problématique, il y a d'autres outils pour ça.
--- Pas de commande show, donc certaines commandes sont assez complexes
Tu prends mal le problème là. Je ne suis pas persuadé que ce soit plus complexe mais même si ça l'est, si tu choisis un SGBDR pour un bout de temps, tu vas te construire ton petit référentiel de vues qui te remontent toutes les informations que tu veux comme tu les veux.
Je serai curieux de savoir ce que tu trouves complexe tout de même. Les versions récentes (genre la 8.3) sont vraiment simples à manipuler de ce point de vue là. Le fait que ce soit du SQL rend en plus les manipulations très simples et cohérentes : on peut faire des vraies requêtes.
--- Performances moins bonne que Mysql (surtout avec MyISAM quand l'on a pas besoin de transactionnel)
Dépend de ce que tu appelles performances. Ca dépend beaucoup de la complexité de tes requêtes, de ton nombre d'utilisateurs concurrents.
Bref, difficile à dire sans avoir une idée de la typologie de charge qu'il y aura.