phpPgAdmin est un projet vieux de plus de 5 ans (sous ce nom), est traduit dans 28 langues différentes et continue ainsi son évolution pour servir au mieux possible la « base de données libre la plus avancée au monde ». Le projet phpPgAdmin (ppa) poursuit sa prise en charge des différentes versions de PostgreSQL depuis la bien ancienne 7.0 à la toute dernière 8.3. Mais pas seulement. Les nouvelles fonctionnalités de 8.3, tel que les types ENUM et le type UUID, la "Recherche plein texte" (Full Text Search, durant le GSoC 2007 de ppa) et les paramétrages de coûts des procédures ont été intégrées. Les autres versions de PostgreSQL elles aussi ont vu apparaître le support de fonctionnalités jusqu'alors absentes de ppa et que je vous laisse découvrir dans les notes de version du projet.
Côté ergonomie, ppa a fait un petit pas (historique des requêtes utilisateur, quelques multi-actions, mise en page, etc) et continuera encore sur ce chemin. En parlant du futur, l'équipe de ppa supportant l'initiative goPHP5 la version à venir ne supportera officiellement plus php4. Cependant, le but étant d'avoir un projet fonctionnel sur un très large panel de configuration, ce support devrait débuter avec php 5.0, cette dernière étant toujours incluse dans certaines distributions qui la maintiennent toujours officiellement.
À propos des versions supportées de PostgreSQL, l'équipe s'apprête à abandonner les plus vieilles d'entre elles pour leur laisser enfin le repos qu'elles méritent, soit les 7.0, 7.1 et 7.2. Cette branche 4.2 sera donc toujours maintenue pour son support de php4 et de ces ancêtres (le plus jeune étant l'arrière arrière arrière arrière grand-parent !) de PgSQL, mais ne devrait plus connaître aucune évolution.
À propos du développement enfin : beaucoup de fonctionnalités, de nouvelles idées de conception et de « TODO » sont restés longtemps en attente de cette publication et vont pouvoir maintenant être discutées et mises en œuvre. Effectivement, l'équipe de développement a décidé de respecter l'adage sourceforgien et de publier plus souvent ses travaux, tentant ainsi d'attirer un peu plus d'activité, de développeurs et d'étoffer toujours plus ppa.
Aller plus loin
- Annonce de la publication (1 clic)
- Téléchargement (4 clics)
- phppgadmin (12 clics)
- Captures d'écrans simples (9 clics)
# La tendance PostgreSQL
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Personnellement, j'utilise toujours MySQL car mes serveurs sont configurés avec ça et que ça tourne (et que je ne m'intéresse pas vraiment aux bases de données d'un point de vue technique).
Ma question est donc théorique est donc : quels sont les avantages de Postgre qui induisent cette "migration" progressive ?
D'un point de vue pratique: qu'aurais-je à gagner à migrer les serveurs d'hébergement que j'administre de MySQL à Postgre ? Ou d'avoir un Postgre qui tourne en parallèle avec MySQL ? Et quels seraient les désavantages des deux solutions ?
Merci d'avance pour vos retours, c'est une question qui me taraude depuis quelques temps.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: La tendance PostgreSQL
Posté par Julien Fontanet (site web personnel) . Évalué à 7.
+ meilleur performance sur de gros projets ;
+ plus de fiabilité sur la cohérence des données ;
+ plus de conformité à SQL que MySQL.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
J'utilise PostgreSQL depuis 2001 donc mes raisons ne sont pas forcément celles des gens qui font le pas maintenant.
Ce que j'ai apprécié et que j'apprécie toujours c'est :
- la qualité du moteur, les fonctionnalités, la qualité des outils (client psql, EXPLAIN ANALYZE très détaillé, log_min_duration_statement en ms et pas en s)
- la cohérence de l'ensemble : les fonctionnalités présentes marchent, pas de limitation bizarre suivant des paramètres bizarres (types de champs, taille de la base, moteur choisi...), tout est cohérent
- la qualité des échanges avec la communauté (réactivité, niveau des échanges, implication des acteurs, retours d'expérience) et l'accessibilité des développeurs
- compatibilité entre les versions : pas de modification posant des problèmes de compatibilité entre versions mineures, éviter au maximum les nouveaux mots clés réservés (toujours embêtant de se retrouver avec un nom de champ qui est maintenant un mot clé réservé - c'est du vécu avec certains autres SGBDR)
- les performances et la scalabilité
- la qualité et la clarté de la documentation, bien séparée par version (pratique quand on fait de l'archéologie chez des clients)
- le fait que ce soit un vrai projet communautaire
- la transparence et l'absence de discours marketing qui a tendance à biaiser les choses. Là, c'est clair et net, y compris les aspects négatifs et on ne parle pas des fonctionnalités présentes dans des versions alpha/beta/gamma comme étant des acquis
- les trucs en plus : les types avancés et leurs index associés, PostGIS
- les progrès faits version après version que ce soit en terme de performances, de scalabilité, d'usabilité ou de fonctionnalités
J'ai probablement oublié des choses mais c'est ce qui me vient à l'esprit là maintenant.
Certains points sont purement absolus et pas relatifs à d'autres bases de données, notamment ce qui concerne la communauté, n'étant pas impliqué dans les communautés des autres bases de données du marché.
Certains points ont également leur revers comme l'absence de marketing, ça se sent au niveau de la notoriété.
--
Guillaume
[^] # Re: La tendance PostgreSQL
Posté par ioguix . Évalué à 9.
Ça assure, par exemple, la strict conformance des données au type défini dans la table (la base ne tronquera pas un entier trop grand ou n'interprètera pas une date inexistante pour les faires entrer dans la table).
Si tu veux un point de vue concernant le développement, la grosse différence entre PostgreSQL et MySQL pour moi, c'est qu'ils ne jouent pas sur le même terrain.
Certains dev veulent des entrepôts stupide où stocker leurs données, gérant tout le système de contraintes et d'intégrité dans leur code.
D'autre préfèrent reléguer ça à la base de données et alléger d'autant leur code coté appli, ne pas avoir à les maintenir à plusieurs endroits si plusieurs applis utilisent la base, accélerer leur code, ...
A propos des "migrations", c'est aussi certainement dû aux projets qui veulent élargir leurs base utilisateur en proposant plus d'une base en backend. Le choix est un bon principe dans le libre, et il tend à s'améliorer dans le domaine des bases.
Mais ce que j'aime vraiment par dessus tout dans PostgreSQL, c'est sa grande qualité générale et sa formidable communauté !
PostgreSQL est un fier représentant du monde du logiciel Libre dans toute sa splendeur :)
[^] # Re: La tendance PostgreSQL
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mais pour moi qui ne fait que le mettre sur un serveur pour installer des applis Web (supportant principalement Mysql ou les Postgres ET Mysql, rarement Postgres uniquement), j'ai l'impression que je ne gagnerais pas grand chose à pigrer à postgres si ce n'est des ennuis.
Par contre, le jour où je développe, promis, je repense à Postgres.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 1.
Donc beaucoup d'appli web qui peuvent aussi marcher avec PostgreSQL, utile PostgreSQL à la MySQL.
[^] # Re: La tendance PostgreSQL
Posté par frost242 (site web personnel) . Évalué à 5.
En revanche, tout Oracle, ça demande de l'investissement, mais la documentation est vraiment bien faite et surtout disponible en français.
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 4.
La doc PostgreSQL est aussi en français (sauf peut-être quelques pages man).
[^] # Re: La tendance PostgreSQL
Posté par frost242 (site web personnel) . Évalué à 1.
[^] # Re: La tendance PostgreSQL
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 1.
"En revanche, tout comme Oracle, ça demande de l'investissement, mais la documentation est vraiment bien faite et surtout disponible en français."
?
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 7.
Tu gagnes en passant à un produit mieux fini (excellents types, pas de surprise, etc).
Mais ne faire que du MySQL avec PostgreSQL c'est donner du foie gras aux cochons :-) . M'enfin, ça ne fait pas de mal.
PostgreSQL bien utilisé est une autre approche du SGBD que MySQL. On n'a pas qu'un système qui stocke des tables, qu'un SGBD qui fait Excel pour caricaturer. Bref je rejoins complètement ioguix. Mais bien maîtriser un SGBD comme PostgreSQL demande un certain investissement en temps. Mais au final on y gagne.
[^] # Re: La tendance PostgreSQL
Posté par Galou (site web personnel) . Évalué à 5.
Si les tables B et C hérite de A. Alors je retrouverai mes lignes de B et C dans des requêtes sur A. Je peux bien évidemment mettre des champs supplémentaires dans B et C.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
La seule utilisation réelle de l'héritage que j'ai vu, c'est pour le partitionnement de données.
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 2.
Mais il y a trop de problèmes techniques pour en faire quelque chose de souple et répondant à des vrais besoins.
Depuis très très longtemps PostgreSQL supporte d'héritage. Mais faire un SGBD orienté objet n'est plus la priorité de PostgreSQL.
En fait Postgres a été renommé PostgreSQL pour montrer le changement d'objectif. Ne plus être un projet principalement de recherche, mais être un SGBD utile et de qualité.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
Sur la partie historique, je t'invite à lire : http://www.postgresql.org/about/history qui te donnera un éclairage différent (et un peu plus proche de la réalité).
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 2.
Pour "contre-vérités", t'es un peu dure. OK, je me suis trompé pour PostgreSQL, c'est Postgres95.
> http://www.postgresql.org/about/history
Postgres, developed between 1986-1994, was a project meant to break new ground in database concepts such as exploration of "object relational" technologies.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
C'est une conséquence du boulot des gens, c'est tout.
[^] # Re: La tendance PostgreSQL
Posté par IsNotGood . Évalué à 2.
On peut le voir comme ça. Mais il y a aussi eu une volonté, la direction du projet a changé (postgres, postgres95, postgresql). On peut retrouver ça dans les vieilles doc.
Mais le plus important est ce qui est fait (le "boulot des gens" comme tu dis). Par contre, le projet PostgreSQL n'a pas changé (dans les grandes lignes). Bref, ça commence à être de la chamaillerie d'historien.
postgres + postgre95 : 10 ans
PostgreSQL : 11 ans
PostgreSQL est largement assez vieux pour que j'évite à l'avenir de faire référence à Postgres et Postgres95.
M'enfin, j'ai débuté avec Postgres (4.2 avec laguage PostQuel). C'était fournit par Red Hat 4.0.
[^] # Vision macroscopique
Posté par Kerro . Évalué à 1.
Et PostgreSQL est conçu par des pationnés (amateurs ou pro) très avertis dont le but est d'avoir un produit qui leur convienne.
Depuis de nombreuses années, PostgreSQL est largement "au dessus" de MySQL (je l'ai utilisé il y a 6 ans et j'ai constaté que c'était très bien, probablement depuis longtemps).
Je ne connais pas les arguments en faveur de MySQL, à part le fait qu'il soit par défaut chez la plupart des hébergeurs.
[^] # Re: Vision macroscopique
Posté par BAud (site web personnel) . Évalué à 6.
Pour ceux qui font du libre, postgres est dispo depuis toujours chez TuxFamily http://faq.tuxfamily.org/DbPgSQL/Fr (c'est aussi un peu le vrai SGBD utilisé pour VHFFS).
[^] # Re: Vision macroscopique
Posté par IsNotGood . Évalué à 3.
[^] # Re: Vision macroscopique
Posté par ioguix . Évalué à 2.
Cependant, Free utilise pour le moment la version 4.1 de ppa.
[^] # Re: Vision macroscopique
Posté par IsNotGood . Évalué à 2.
PL/pgSQL est un language "digne de confiance". Normalement tout le monde y a accès. Je n'ai pas vérifié spécifiquement pour free.fr, mais ce dernier doit probablement le supporter.
En passant, PL/pgSQL permet beaucoup de chose.
Tu confirmes que free.fr ne supporte pas PL/pgSQL ?
[^] # Re: Vision macroscopique
Posté par ioguix . Évalué à 1.
[^] # Re: Vision macroscopique
Posté par IsNotGood . Évalué à 2.
Autant pour moi. J'étais persuadé que le "CREATE LANGUAGE" était fait par défaut (et donc il n'était pas nécessaire de le faire) . J'ai vérifié, ce n'est pas le cas.
Notons qu'il est fait par défaut pour SQL (fonction SQL).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.