Discussion :

[ZIED]

Bonjour
Je fais un peu de développement en utilisant PG. Je me pose plusieurs questions sur le futur
Postgresql est-il encore compétitif?
A-t-il un avenir?
La communauté est-elle encore active?

[kedare]

Oui,
Oui,
Oui.

De rien

[jnore]

Bonjour
Je fais un peu de développement en utilisant PG. Je me pose plusieurs questions sur le futur
Postgresql est-il encore compétitif?
A-t-il un avenir?
La communauté est-elle encore active?

Bien sûr que oui même s'il y a toujours débat entre le libre et certains hyper standards comme sqlserver ou encore oracle.

Pour avoir les avis des uns et des autres, regarde ceci:
http://www.developpez.net/forums/d14...ql-postgresql/

[VASAPANCH]

à propos de postgreSQL :

Pour une utilisation sous Win un peu complexe (utilisation API C, création de fonctions C via des dll, etc...), je déconseille postgreSQL car de nombreux problèmes apparaissent et la compatibilité entre les versions laisse à désirer. Ceci peut lourdement handicaper un projet dont les différentes deadline approche. De plus, il n'y a que les forums et mailing lists en guise de support et lorsqu'on est sur Win et qu'on en vient à résoudre des problèmes complexes c'est le néant. Un exemple : beaucoup d'utilisateur avancés sur plateforme Win ont rencontré le problème de linkage dll avec postgreSQL. Du coup la totalité a abandonné... J'ai finalement trouvé comment résoudre ces différents problèmes (PG_Module_Magic, Current_Memory_Context, porblème du flag DLL_BUILDING, etc...) sur un site tchèque (et j'ai du mettre la main dans le code) ! Les différentes mailing lists restant muettes à ce sujet... De même pour résoudre les problèmes liés à l'utilisation sur plateforme Windows (comme le paramètrage du serveur, la définition des espaces swap, etc.. etC...) il est difficile de trouver réponse auprès de la communauté. Enfin les docs laissent VRAIMENT à désirer et la gestion fine de certaines fonctionnalités est vraiment inhabituelle sans qu'aucun avertissement ne soit donné (par exemple la gestion de NULL -à essayer (il y a quelques topics à ce sujet) : des mélanges select where in/not in avec des éléments NULL- , la gestion des arrondis, des bounding box, etc.... sous postgis est parfois surprenante.

Par contre pour une utilisation sous Linux, une utilisation plus classique ou encore pour celui qui souhaite vraiment se plonger dans postgreSQL, pas de soucis, ça gaze vraiment bien et même en très haute volumétrie.

Finalement, un des grands avantages de certaines autres applis réside dans le support. Par contre, si vous avez les moyens (niveau temps, personnel, etc...) d'enrichir votre entreprise d'une expertise postgreSQL je suis convaincu que cela paye et paiera encore longtemps sur le long terme !

Qui aime bien châti bien (parcequ'il veut aussi un peu que ça bouge sur ces points) et vous comprendrez donc que j'aime bien postgreSQL.

[matta]

On pourrait retourner la question

PostgreSQL a TOUT pour remplacer oracle et les autres
pour preuve les éditions propriétaires font du pseudo open source

les entreprises ayant choisi postgres : METEO FRANCE, RATP, TDF ...

A+

[kedare]

On pourrait retourner la question

PostgreSQL a TOUT pour remplacer oracle et les autres
pour preuve les éditions propriétaires font du pseudo open source

les entreprises ayant choisi postgres : METEO FRANCE, RATP, TDF ...

A+

J'aimerais bien des sources pour la RATP (D'ailleurs pourquoi la sncf reste sur mysql bouhl !?)

EDIT: c'est bon, j'ai trouvé avec google pour la RATP

[scheu]

Regarde ce débat Postgresql vs MySQL : http://www.developpez.net/forums/d14...ql-postgresql/
Personnellement niveau professionnel je suis assez confiant en l'avenir de postgreql
Tu as pleins de nouvelles fonctionnalités équivalentes aux sgbdr du marché (pools de connexion, langage pg/plsql, base répliquée avec le log shipping, partitionnement, sauvegardes à chaud, tablespaces, optimiseur et statistiques, dblinks, ...) Et postgresql gère très bien les grandes volumétries

[papy_tergnier]

PostgreSQL a TOUT pour remplacer oracle et les autres

PostGreSQL a peut être tout et encore je ne suis pas sur à 100% mais n'ayant pas traité toutes les qualités et défauts je ne voudrais pas parler dans le vent.
Mais cela n'a rien à voir avec la pérennité d'une société : ça se saurait sinon. Ce n'est pas parce que PG que la communauté est important, qu'il a de l'avenir, ...

Je trouve les questions de ZIED très pertinentes mais les poser dans un forum PG entrainera beaucoup de réponses subjectives (pas toutes).

++

PS : malgré mes critiques, je suis bien évidemment un grand fan de PG

[ZIED]

Je sens qu'il y a une reconnaissance de la fiabilité et des fonctionnalités de PG qui sont proches des SGBD Commerciaux. Par contre, je ressens que la communauté n'est pas suffisamment active.
De plus, je trouve que les outils et les utilitaires FREEWARE ne sont pas nombreux.
Il n'y a pas d'outil de réplication très pratique (Interface Graphique, Paramétrage simplifié...).
La migration de la BDD d'un serveur PG vers un autre serveur BG ne se fait pas les yeux fermées. Il y a toujours des pbs.
A part la doc officielle, il manque bcp de tuto et d'exemples sur les fonctionnalités spécifiques....
En terme d'hébergement, notamment gratuit, l'offre n'est pas très abondante.

J'espère que je me trompe sur certains aspects et qu'il y a des choses que j'ai pas vues. Que quelqu'un me le dise.

[VASAPANCH]

PostgreSQL est excellent !! Je le répéte.

De là à dire il ne faut rien changer... et ne rien remettre en question.
C'est le meilleur moyen pour que beaucoup lâche l'affaire.

La doc est bien rédigée et large (pas complète à mon sens : les exemples sont fournis pour Linux dans TOUT les cas, rarement pour Win)... mais il pourrait y avoir plus de tutos... pourquoi pas un forum postgreSQL officiel en plus des mailing lists... Evidemment c'est plus trop dans l'idéal du "libre" (subversion, rapport de bug, mailing list) mais bon... parfois on peut faire quelques concessions pour vulgariser le produit ou en faire sa promotion.
Pourquoi pas des docs spéciales Windows (là je vais me faire flinguer mais bon c'est pareil : vulgarisation) ou thématiques.

"Evidemment, l'écriture de dll en C est pénible, mais c'est dû à Windows, pas à PostgreSQL... " (me dis-tu flo)

Et bien clairement pas... l'écriture de dll sous Windows ne posent pas de problème depuis le temps que j'en développe. Les problèmes que j'ai rencontré dans ce cas particulier sont clairement dû au fait que PG a été développé pour Linux... quand on commence à trifouiller dans les header et source on s'en rend compte... quand on fini par trouver les solutions il apparait clairement qu'il s'agit de poser de la "glue" ou de remplacer le code PG qui parait bien peu générique. (si je suis remonté c'est que j'en ai tellement bavé pour réussir et enfin me rendre compte que passé à la version suivante il me fallait de nouveau me replonger dans les sources... pour enfin réussir de nouveau QUE CA ME GONFLE D'ENTENDRE DES SPECIALISTES ME DIRE C'EST PAS PG C'EST WIN ! Ben dans ce cas mettez le dans la doc : "ne pas chercher à développer des procédures performantes en C sous Win parceque win c'est pas bien !" Franchement ça m'aurait évité d'en baver. D'ailleurs si cela venait de Win pourquoi ne rencontre-t-on pas les mêmes problèmes avec d'autres outils ?)

"Si j'avais à développer des procédures stockées sous Windows, j'éviterai le C, j'utiliserai plutôt pl/psql ou perl..." Bien bien.... mais je ne te cache pas que le fait d'utiliser les dll a certains avantages. De plus, les comparatifs de perf pour les procédures stockées laisse entendre que C est recommandé dans beacoup de cas pour augmenter les perfs. De plus, de plus, quand on est plutôt au point en C/C++ on se dit que ce serait bien pratique d'utiliser ses connaissances... Et enfin, plutôt que de dire c'est pas possible pourquoi ne pas se dire : "on y réfléchit, on y bosse, on va voir ce qu'on peut faire"

Bref, ton message flo m'a un peu agacé concernant les remarques sur les dlls en C. Evidement, il est plus facile de dire c'est Win plutôt que de chercher à s'adapter ou à diffuser les infos de ceux qui ont trouvé des sols adaptés voire les mettre dans la doc.

Bon j'avais pas compris ce qu'il fallait dire. Maintenant je crois que j'ai pigé :

PostgreSQL c'est LE meilleur SGBD. Mieux, y'a rien à redire. Encore mieux, si y a un soucis c'est ton OS. Enfin, si la doc et les mailings lists te suffisent pas ben c'est que t'as rien compris au libre

Comment me faire douter de mon envie de promouvoir ce produit autour de moi. BJ

[PmG57]

Bonjour,

Je ne suis pas un habitué des forums de discussion, mais recherchant un peu d'info du PostGresSql pour une question relative à la base sous Free je suis tombé par hasard sur cette discussion et j'ai décidé de m'inscrire pour vous faire partagé mon avis.

Tout d'abord, je ne suis pas un expert informatique et ce n'est pas mon métier, il me reste tout de même encore qq (bonnes?) bases de par ma formation initiale.

J'ai découvert Linux en 1999, au départ je voulais un vrai système multi-utilisateurs pour partager l'accès entre mes enfants. Depuis cette date, je n'utilise plus que Linux à la maison (au passage mon dernier PC portable dispose d'une licence Windows Vista que je n'utilise pas!) pour ses nombreux avantages en particulier la possibilité d'avoir "plusieurs bureaux disponibles" et je regrette tous les jours de ne pas disposer de cette fonctionnalité au bureau.

L'offre , dans le domaine du libre en particulier, est tellement abondante qu'il est parfois difficile de faire le bon choix, le premier investissement à faire est donc de passer un peu de temps pour définir ses besoins, ses critères de choix et faire le choix.

En ce qui concerne le choix du SGBQ, j'étais un utilisateur important d'Access qui pour moi est (toujours) un excellent produit en mono-utilisateur et je n'ai pas trouvé l'équivalent sous Linux. Cela existe peut-être aujourd'hui, les interfaces graphiques ont bien évoluées, mais il me semble que ce n'est pas encore aussi souple qu'Access (un petit avantage pour Windows sur ce point uniquement).

J'ai donc comparé (il y a 5 ans environ) et rapidement dû faire le choix entre MySql et PostGreSql. Mon choix s'est très vite porté sur PostrGreSql car j'ai trouvé des fonctionnalités bien supérieures à Access et à MySql (désolé je n'ai pas gardé le comparatif).

Ensuite il faut un peu de temps d'apprentissage, mais là je vois pas différence entre les produits une fois que l'on connaît la notion de SGBD. j'ai passé plus de temps à apprendre les bases de SQL , ce qu'Access m'avait évité de faire.

J'utilise donc PostGreSql depuis plus de 5 ans pour des bases personnelles (dont certaines font qq millions d'enregistrements) et cela fonctionne très bien. En 5 ans, les interfaces graphiques ont bien évolué (PgAdmin par exemple et l'accés via Ooo qui commence à bien ressemblé à Access).

Il y a qq jours j'ai décidé de regarder por faire mon 1er site web, et conseillé par mon fils, je me suis tourné rapidement vers Free (ce n'est pas de la pub car ce n'est plus mon FAI depuis 2 ans suite à différent commercial, mais techniquement il reste manifestement à la pointe) et j'ai fait un 1er exemple avec MySql, en local dans un 1er temps. Mon code était en PHP avec DBX (indépendance versus le choix de la base), puis je suis rapidement repassé à PostGreSql (pour potentiellement gardé ses avanatges), cela sans pb suite DBX.
En partant mon exemple sur Free, il ne fonctionnait pas, probablement car DBX n'est pas disponible, je n'ai pas creusé cette question, car j'ai de suite regardé l'accès via PostGreSql sous PHP et j'ai de suite vu que tout était disponible (http://php.easynet.be/manual/fr/ref.pgsql.php) très facilement.

J'espère que ces lignes vous ont apporté en éclairage complémentaire et je vous souhaite de passer une bonne journée.

A tout hasard il me reste mes deux questions :
1) Possibilité d'utiliser DBX ou ... sous Free pour que le code (PHP a priori) soit indépendant de la base choisie ?
2) Sous Free, ma base se trouve sous le "schéma" public. Je peux créer d'autres "schémas" mais je ne peux / sais pas accéder aux tables ainsi créées.
Que représente cette notion de schéma ?
Comment y accéder ?

PmG57

[jnore]

2) Sous Free, ma base se trouve sous le "schéma" public. Je peux créer d'autres "schémas" mais je ne peux / sais pas accéder aux tables ainsi créées.
Que représente cette notion de schéma ?
Comment y accéder ?

PmG57

Pour accéder à un shéma autre que public, il faut l'appeler avant le choix de la table, par ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
SELECT champ 
FROM autre_schema.TABLE

[Empty_body]

Salut,

J'utilise PostgreSQL au niveau professionnel depuis bientôt 2,5 ans, c'est un produit à la fois stable et fiable qui correctement configuré donne pleinement satisfaction. Les serveurs que nous utilisons tournent soit sous windows2003 (32 ou 64bits) serveur soit sous centos (32 ou 64bits) ou encore sous solaris.

PostgreSQL commence seulement à être documenté correctement mais je pense que ça se justifie par de grosses évolutions sur les dernières générations (la documentation aurait été assez caduque). La communauté, que ce soit sur ce forum ou sur celui de PostgreSQL est très réactive et toujours de bon conseil. (Il suffit de voir l'apparition de certains tuto, comme celui de Scheu, merci à lui, sur le Warm standby à peine 1 mois après ma question à ce sujet, sujet par ailleurs résolu sur le forum).
Il est par contre à regretter de ne pas trouver de tuto claires sur des produits comme sloany entre autre.

En conclusion, je dirais que PostgreSQL est un produit qui devient mature (stabilité et maniabilité), qui souffre malheureusement d'un léger manque de documentation mais propose en compensation une communauté très active. Petit hic, des modules comme slowny ne sont toujours pas clairement documenté (en solo, c'est la tuile à mettre en place).

[scheu]

les entreprises ayant choisi postgres : METEO FRANCE, RATP, TDF ...

mappy.fr tourne aussi sur Postgresql il me semble

[philwood]

J'aimerais bien des sources pour la RATP (D'ailleurs pourquoi la sncf reste sur mysql bouhl !?)

EDIT: c'est bon, j'ai trouvé avec google pour la RATP

Bonjour, je tombe sur ce post
Je confirme pour la ratp. Nous sommes qq peut "remontés" contre Oracle.
Donc ça avance doucement mais surement ... Tout nouveau projet à la RATP doit étudier en priorité une solution à base de postrges.
Tout ça est tout de même à relativiser ... aucune "grosse" application interne n'a encore migré ...

[rupteur]

J'utilise postgresql sous linux avec avec des bases d'environ 2go. et 15 à 20 millions de lignes sur certaines tables.
Aucun problème de fiabilité ou de lenteur.

En outre l'utilisation du langage SQL standard lors du développement des applications (pas de procédure stockée) permet de garder une "certaine" sécurité s'il fallait passer a un poids-lourd du marché.

la communauté est très active (peut-être trop les nouvelles versions arrivent trop vite pour upgrader les serveurs)

Je regrette juste qu'il n'existe pas un système de réplication intégré.

[scheu]

Je regrette juste qu'il n'existe pas un système de réplication intégré.

Bien sûr que si !!! Depuis la 8.2, il y a l'équivalent du dataguard de Oracle
J'ai même fait récemment un tutoriel là-dessus : http://scheu.developpez.com/tutoriel.../log-shipping/

Postgresql => que du bonheur

[ZIED]

Je regrette juste qu'il n'existe pas un système de réplication intégré.

justement c'est l'un des points critiques qui compliquent un peu la tache.
Y'a-til un projet open source, de la même envergure que pgAdmin par exmple, qui est lancé dans ce sens?

[rupteur]

-> scheu

Merci pour le lien,

j'ai lu le tutoriel et c'est très intéressant. (le tuto. et le log_shipping )

[SQLpro]

En outre l'utilisation du langage SQL standard lors du développement des applications (pas de procédure stockée) permet de garder une "certaine" sécurité s'il fallait passer a un poids-lourd du marché.

Ca c'est une erreur. Si vous voulez être le pus compatible possible il faut impérativement n'utiliser que des procédures stockées.
J'ai montré à de multiples reprises qu'un simple SELECT * FROM MaTabme ORDER BY ... ne donnait pas les mêmes résultats sur les différents SGBDR du marché :
http://sqlpro.developpez.com/cours/s...age=partie1#L3
exemples 9 et 10.
Le seul moyen de créer des applications compatibles est donc de n'utiliser que des procédures stockées, ce qui fait qu'a part la chaine de connexion, rien n'est à modifier dans le code client.
En revanche modifier des PS, c'est simple et facile car il n'y a aucun déploiement.

De plus certains fonctionnalités aujourd'hui importantes, voire essentielles comme la CTE (requête récursives) ou les fonctions de fenêtrage ou encore les groupages OLAP (CUBE, ROLLUP), ne peuvent être réalisé facilement dans une requête si elle n'y sont pas (ce qui est le cas de PostGreSQL). La solution consiste donc à encapsuler dans une procédure stockée toute la logique algébrique et ne présenter au client qu'un objet générique.


A +