Monsieur Bordage, J'ai lu avec attention la version PDF de votre article sur Décision Informatique n°606 du 4 octobre 2004 (pages 28 à 34, avec des trous). Je m'occuppe par ailleurs activement du projet PostgreSQL pour la France. A ce titre, j'ai créé avec quelques amis le site http://www.PostgreSQLFr.org. Mon courriel synthétise les pensées de bons nombres d'utilisateurs de PostgreSQL en France. Pour m'en assurer, j'ai fait relire et corriger ce courriel par les lecteurs de la liste de diffusion « pgsql-fr-generale ». Il n'y a à ce jour pas encore d'entité officielle autour de PostgreSQL en France. C'est en cours, nous montons avec des amis (toujours les mêmes), une loi 1901 à ce titre. Ce mail aurait pû tout aussi bien venir de cette association, si elle avait existé ce jour. Nous tenons à vous manifester notre profond regret et désaccord quant à la façon avec laquelle vous traitez le SGBDR que nous utilisons au quotidien: PostgreSQL. Nous n'avons pas l'intention de nous faire aussi les avocats de la défense de MySQL. Nous laissons le soin à MySQL A.B. de le faire, avec ses vrais avocats internationaux. J'ai pris la peine de re-taper toutes les phrases qui nous semblaient fausses ou discuttables, et de les classer par thème. -*- (1) Ce que vous affirmez est faux ================================= a)p.34 « uniquement GPL » PostgreSQL n'est pas sous licence GPL, mais BSD. C'est une différence de taille! Manifestement vous n'avez pas lu la licence de PostgreSQL. b)p.30 et ailleurs: « Pas de sauvegarde à chaud » pg_dump et pg_dumpall sont les deux outils livrés avec PostgreSQL (quelle que soit la version et/ou son packaging (rpm red hat, paquet debian...). Il permettent justement de faire des sauvegardes à chaud. Je dis bien sauvegardes. Pas seulement un export de données. c)p.31 et ailleurs « Les SGBD propriétaires proposent en plus la gestion de XML » Manifestement, vous êtes passés à côté. C'est dans le répertoire "contrib" de PostgreSQL qu'on trouve les fonctions nécessaires pour l'utilisation de XML. Voir postgresql-8.0.0beta3/contrib/xml2/README.xml2 par exemple pour la version la plus à jour (version sources en tarball, sinon installer le paquet postgresql-contrib). d)p.29: « (PostgreSQL): son installation laborieuse nécessite des compétences très pointues, rarement disponibles en PME » p.31: « (PostgreSQL) installation et paramétrage: 90 Minutes » « (PostgreSQL) nécessite des compétences pointues » C'est faux, complètement. L'installation par paquet RPM (Red Hat, Mandrake, et d'autres...) ou DEB (Debian et assimilés) prends montre en main 5 minutes, dont 3 passées à télécharger le paquet depuis un repository. Le paramétrage par défaut est efficace pour créer et utiliser une base de données sur un serveur de données, en compte postgresql. Le paramétrage avancé n'est pas plus compliqué que sur les autres systèmes. Il se concrétise par un fichier de configuration pour le moteur de données «postgresql.conf» et un autre pour la politique de sécurité «pg_hba.conf». C'est tout. Quant à l'administration... Il suffit de mettre un vacuum dans une crontab et de surveiller son espace disque, tout le reste est dans les deux fichiers ci-dessus. Cela en fait-il un SGBDR-OO difficile à administrer? e)p.31: « Pas de mécanisme de réplication » Certes, par défaut, PostgreSQL ne s'encombre pas de cela. Cependant vous trouverez sur internet une foules de projets libres, en licence BSD, dédiés à cette tâche pour PostgreSQL. Reste que ces réplications sont du type assynchrone uniquement pour le moment. Je vous invite à vous informer notament sur Slony, qui est parmi ces solutions, à notre sens la plus stable et la plus performante: http://gborg.postgresql.org/project/slony1/projdisplay.php f)p.30 « Les bases de données propriétaires disposent en plus de fonctions supplémentaires qui garantissent une reprise sur incident rapide (option cluster, contrôle d'intégrité en continu, etc.). » PostgreSQL propose la reprise sur incident rapide dans la mesure où le mécanisme de "Write Ahead Log" est effectif depuis plusieurs versions stables. Il s'agit d'un mécanisme équivalent à celui d'Oracle qui garanti une reprise sur incident au plus près. Quant à votre « contrôle d'intégrité en continu », de quoi parlez vous exactement?... Vous supposez par cette affirmation gratuite qu'une base de données PostgreSQL pourrait avoir à un instant des données inconsistantes? C'est de nouveau une affirmation fausse. PostgreSQL possède le mécanisme MVCC (comme Oracle : Multiversion Concurrency Control). Je vous invite à lire la documentation en ligne sur ce point: http://www.postgresql.org/docs/current/static/mvcc.html ou encore cet article: http://www.developer.com/net/vb/article.php/877181 Ce mécanisme garanti la consistance des données de manière formelle. (2) Vous confondez SGBD{R|OO} et serveur d'applications ======================================================= p.28: « Les outils open source sont fonctionnellement plus pauvres. Ils se limitent aux fonctionnalités de base (SQL). PostgreSQL, par exemple, ne prends pas en compte XML, ni les services web. » « Oracle propose un mini-atelier logiciel (HTML-db) [...] Ce type de fonctions avancées est clairement réservé aux outils propriétaires. » p.31: « SQL Server orffre la possibilité d'exposer n'importe quel objet de la base sous forme de service Web » p.34: « il lui manque encore la gestion de XML, des services web, et d'autres fonctions avancées comme Olap. » p.34: « (PostgreSQL) Bonne couverture fonctionnelle. Manque la gestion d'Olap, de XML et des services Web, pas de fonction de reporting » Cette confusion est révélatrice d'une chose: les services marketing d'IBM, Oracle et Microsoft sont très forts. Vous êtes tombés dans le panneau comme nombre de « décideurs ». Vous confondez clairement serveur de données et serveur d'application. Je ne comprends pas la confusion d'autant qu'on trouve à cheval sur les pages 30 et 31 un schéma où vous distinguez clairement le serveur de données du serveur d'application? Dire que « les outils open source sont fonctionnellement plus pauvres parcequ'ils se limitent au SQL » est complètement délirant. Vous reprochez aux serveurs de données de ne s'occupper que du SQL? Pour ce qui est de la partie applicative, le monde de l'Open Source n'a *strictement rien* à prouver. Dois-je vous signifier qu'Apache est le serveur web le plus utilisé au monde? D'autant que PostgreSQL est parmis les SGBD les plus ouverts et les plus extensibles qu'il soit à en juger par le nombre impressionant de clients différents avec lesquels il peut s'interfacer... (3) Des affirmations gratuites et sans fondement technique: à but publicitaire? =============================================================================== a) p.28 : « Au delà du prix, l'utilisateur choisira un SGBDR libre ou propriétaire, selon qu'il privilégie la richesse fonctionnelle et l'évolutivité, ou la performance en lecture » Vous prenez gratuitement 3 critères de sélection ici. Pourquoi ceux-là? Je trouve complètement curieux de mettre en rapport ces 3 termes... Et encore plus curieux d'affirmer qu'ils seront déterminant dans le choix d'une solutions libre ou propriétaire. b) p.29 : « À l'inverse, SQL Server 2000 Standard Edition se révèle très en avance du côté des services web et son module d'import-export (DTS). » « tandis que DB2 [...] peut accéder à différentes bases de données au sein d'une même requête » Comment démontrez-vous cette avance? Je ne vois nulle part dans l'article un passage qui en parlerait. De plus vous parlez d'un module d'import-export... Ça existe pour la quasi totalité des SGBD testés. Par exemple, Oracle possède depuis fort longtemps un outil d'import, un outil d'export, et un outil de chargement de données externes (SQL*Loader) d'un qualité inégalée.... Pourquoi ne pas en avoir parlé?... « tandis que DB2 [...] peut accéder à différentes bases de données au sein d'une même requête » Une fois encore, ce n'est pas une particularité par rapport aux autres bases de données. Oracle permet déjà de le faire (et même de manière impressionante depuis la 9i, où toute source de données peut être visible comme une table SQL) avec les DB Links par exemple. Le DBLink " à la oracle " existe aussi pour PostgreSQL... « Les SGBD d'Oracle et d'IBM automatisent certaines opérations de maintenance pour augmenter la disponibilité des données » Encore un petit coup de pub gratuit (vraiment gratuit?)... On peut faire la même chose avec PostgreSQL : mettre un vaccuum dans un cron unix... En revanche, vous ne parlez pas des 10aines de patches pour Oracle et/ou SQL Serveur... Des problèmes d'attaques distances avec déni de service possible pour ces SGBDR?... C'est bizzare non? (faites une recherche sur http://www.cert.org avec Oracle en mot clé ou SQL SERVER...) c) p.29 : « (les outils propriétaires:) Ceux cis se distinguent aussi par leur ergonomie. IBM annonce par exemple avoir réduit de 65M la charge nécessaire à l'administration quotidienne de sa dernière génération de serveurs. » Tiens donc? Comment une affirmation en provenance d'IBM, sans fondement technique, sans rapport avec le test, se retrouve dans votre article?... Comment allez-vous légitimer cette phrase? Je ne trouve pas cela très sérieux. Vous parlez d'ergonomie... Doit-on comprendre que tout ce qui n'a pas d'interface graphique n'est pas ergonome? Vous faut il nécessairement une interface graphique pour que vous vous sentiez en sécurité? Le client psql de PostgreSQL de part sa richesse fonctionelle est largement plus ergonomique que son homologue Oracle (sqlplus). Ne serait-ce que grâce au support du readline... d) p.29 « La qualité des outils d'administration (console client-serveur et web, import-export, requêteur, etc), de la documentation et de l'assistance technique est également meilleure que celle des systèmes open source. » p.31 « Les systèmes propriétaires fournissent une documentation, un outillage [...] et une assistance technique de meilleure qualité que ceux des outils open source » p.31 « documentation la moins bonne du comparatif » Tout d'abord, sachez que ce n'est pas en répétant les choses qu'on démontre quoi que ce soit. Ensuite, ces affirmations sont complètement gratuites et viennent souligner le dénigrement systématique des solutions Open Source dans votre article. La documentation de PostgreSQL est réalisée par des bénévoles, comme l'ensemble du projet, evidement. Elle ne saurait évidement rivaliser avec les 700mo de documentation que l'on trouve sur le CD de la documentation d'Oracle 8i, évidement. Reste que l'essentiel y est! Rien n'est caché... Dois-je vous parler des parties "non documentées" d'Oracle et de DB2?... Enfin, avec PostgreSQL et MySQL, vous disposez de la meilleure documentation qui soit: vous avez le code source!!! Vous n'avez jamais mentionné cela dans votre article, je trouve cela tout à fait regrettable. En tant que "journaliste" vous me direz que cela n'est pas important, je le conçois. Mais pour avoir été développeur sur Oracle, je vous garantis que c'est capital comme différence de savoir comment les choses sont faites "en vrai" dans le moteur de données. e) p.29 : « Oracle 10gSE One et PostgreSQL 7.3 sont les serveurs les plus complexes, mais aussi les plus ouverts » En quoi PostgreSQL est-il complexe? Encore une affirmation gratuite! Pour être DBA Oracle moi-même, je peux affirmer sans hésiter que l'administration d'une base Oracle *est* complexe. Cela s'apprends chez Oracle University. Ça se compose de 5 stages d'une semaine. Soit 5 semaines de formation pour être un *apprenti* DBA. Parceque par la suite, ce capital de formation doit s'enrichir de l'expérience, souvent acquise au travers de liste de diffusions (je vous recommande celle du CRU : oracle@cru.fr )... Alors que PostgreSQL ne nécessite pas ou presque pas d'administration! Discuttez avec des DBA PostgreSQL, notament avec ceux comme moi qui ont une expérience avec d'autres SGBDR. Vous verez ce qu'il vous diront. PostgreSQL est véritablement facile à utiliser. Merci au demeurant de reconnaitre les qualités d'ouverture de PostgreSQL. f) p.30 : « PostgreSQL 7.3.6 - Red Hat AS 3 » Vous n'avez manifestement pas testé PostgreSQL dans sa version stable et débugguée que la communauté vous avait conseillée. C'est un coup bas. La version stable depuis des mois de PostgreSQL est la 7.4.5, qui comprend notament de grosses améliorations de performances par rapport à une 7.3.x. g) p.30 : « Clever Age a utilisé un jeu de huit requêtes SQL représentatives et une base comprenant trois tables stockant de 1 à 10 millions d'écritures » Quelle rigolade! Clever Age ne doit vraiment *rien* connaître aux PME... Vous pensez sincèrement que cela constitue une base représentative de l'activité d'une PME d'aujourd'hui?.... A mon avis, vous pouvez multiplier le nombre de tables par 20 ou 30 et diminuer la volumétrie par 10. Là ça serait représentatif... h) p.32 : « (PostgreSQL) assistance technique aléatoire » p.34 : « assistance technique annuelle : 4500 euros TTC » Pour sûr si Clever Age a posté sur les mailing-lists d'aide de PostgreSQL, où on vous répond *dans la journée* (vous pouvez utiliser l'IRC aussi pour une réponse *instantanée*), on a du leur dire de commencer par installer la version stable actuelle (soit une 7.4.5 en lieu et place de la vieille 7.3 qui a servi pour lesdits "tests"...). Rien d'aléatoire dans l'assistance gratuite: il y a toujours qqun pour répondre à votre problème, je vous le certifie. Et d'où sortez-vous ce chiffre de 4500 euros ttc??? C'est le tarif de Clever Age?... -*- Pour conclure, votre article est à la limite du supportable. Vous mettez de gros encadrés "Périmètre du test" et "Méthodologie" pour vous couvrir, pour avoir un semblant de sérieux et de professionalisme. Reste qu'affirmer avec véhémence de telles contre-vérités n'est pas pour vous servir. Tant au plan professionel, puisque cela discrédite votre "journal", que personnel, puisque vous signez un article qui démontre une rare incompétence. Vous auriez pu vous appuyer bien plus largement sur la communauté, nous aurions pu vous conseiller et vous donner tous les pointeurs nécessaires pour réaliser un comparatif de qualité, qui aurait vraiment pu permettre à un responsable informatique de PME d'y voir plus clair... Nous aurions été tout aussi déçus si PostgreSQL n'était pas arrivé en tête, comme il le devrait, mais au moins, nous n'aurions pas le sentiment d'avoir été floués par un article aux méthodes douteuses. Cela nous aurait au contraire motivés pour nous atteler encore plus fort à la tâche, pour faire en sorte que PostgreSQL sorte enfin 1er de ce genre de test, comme il le mérite. Au lieu de cela vous êtes passés complètement à côté. C'est regrettable. Vous ne parlez par exemple des SGBD libres que sur un plan purement financier (p.28: « en cassant le prix de leurs outils, les éditeurs de SGBDR propriétaires sapent le principal avantage des outils open source: leur faible coût d'acquisition » ).... ... et la liberté dans tout ça??? : - la liberté d'utiliser un programme - la liberté d'étudier comment ce programme fonctionne et éventuellement de le modifier comme on le veut - la liberté d'en redistribuer des copies - la liberté d'améliorer le programme et de diffuser ces améliorations? Ne sont-ce pas là des avantages *largement* supérieurs à un coût d'acquisition?