phpPgAdmin 4.2

Posté par . Modéré par Benoît Sibaud.
Tags :
0
9
avr.
2008
Base de données
phpPgAdmin est un projet proposant d'administrer un ou plusieurs de vos serveurs PostgreSQL à travers un navigateur. Le dimanche 6 avril dernier est sorti la version 4.2 de ce dernier. Cette toute dernière mouture apporte la prise en charge de PostgreSQL 8.3, pas mal de nouvelles fonctionnalités - fonctionnelles ou ergonomiques - et son lot de corrections d'anomalies.

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.
  • # La tendance PostgreSQL

    Posté par (page perso) . Évalué à  2 .

    Je constate une tendance de plus en plus importantes pour les applis web de passer de MySQL vers Postgre. phpPgAdmin me semble d'ailleurs bien plus classieux que phpmyadmin.

    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.
    • [^] # Re: La tendance PostgreSQL

      Posté par (page perso) . Évalué à  7 .

      De ce que j'ai entendu dire :
      + 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 (page perso) . Évalué à  10 .

      Salut,

      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 . Évalué à  9 .

      Je pense que ce qui peut bien plaire aux utilisateurs de MySQL dans PostgreSQL, c'est aussi le principe de la moindre surprise, appliqué à tous les niveaux du projet.

      Ç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 (page perso) . Évalué à  2 .

        Je lis tous les commentaires et l'impression que j'en ai c'est que Postgres est super pour programmer.

        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.
        • [^] # Re: La tendance PostgreSQL

          Posté par . Évalué à  1 .

          Le problème étant aussi que beaucoup d'applis web "doivent" utiliser MySQL car MySQL est plus largement disponible.
          Donc beaucoup d'appli web qui peuvent aussi marcher avec PostgreSQL, utile PostgreSQL à la MySQL.
        • [^] # Re: La tendance PostgreSQL

          Posté par (page perso) . Évalué à  5 .

          Je viens du monde de l'exploitation et j'ai utilisé et admiré Oracle. J'ai vraiment retrouvé mes petits avec PostgreSQL, notamment en terme de sécurité des données - au sens DBA - et je fais vraiment confiance à PostgreSQL, beaucoup moins à MySQL, et sans vouloir lancer le troll obligatoire sur la perte de données avec MySQL.

          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 . Évalué à  4 .

            > En revanche, tout Oracle, ça demande de l'investissement, mais la documentation est vraiment bien faite et surtout disponible en français.

            La doc PostgreSQL est aussi en français (sauf peut-être quelques pages man).
    • [^] # Re: La tendance PostgreSQL

      Posté par . Évalué à  7 .

      Utiliser PostgreSQL comme tu utilises MySQL peut se faire et très facilement.
      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 (page perso) . Évalué à  5 .

      PostgreSQL gère l'héritage de table. Cette fonctionnalité est très intéressante pour des applications objets.

      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 (page perso) . Évalué à  4 .

        Mouais. Il y a assez de limites pour que ce soit moyennement une bonne idée.

        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 . Évalué à  2 .

          L'idée d'une base de données orienté objet est bonne.
          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 (page perso) . Évalué à  3 .

            Il y a beaucoup de raccourcis et de contre-vérités dans ce que tu dis.

            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 . Évalué à  2 .

              > Il y a beaucoup de raccourcis et de contre-vérités dans ce que tu dis.

              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 (page perso) . Évalué à  3 .

                Ce que je voulais dire, c'est que ta phrase expliquant les changements de nom par "Ne plus être un projet principalement de recherche, mais être un SGBD utile et de qualité." n'a pas grand chose à voir avec la réalité.
                C'est une conséquence du boulot des gens, c'est tout.
                • [^] # Re: La tendance PostgreSQL

                  Posté par . Évalué à  2 .

                  > C'est une conséquence du boulot des gens, c'est tout.

                  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 . Évalué à  1 .

      De manière très grossière (très très même), on peut résumer en disans que MySQL est conçu par une entreprise commerciale compétente dont le but est de faciliter la vie du plus grand nombre.
      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 (page perso) . Évalué à  6 .

        à part le fait qu'il soit par défaut chez la plupart des hébergeurs
        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 . Évalué à  3 .

          PostgreSQL est aussi disponible sur free.fr.
          • [^] # Re: Vision macroscopique

            Posté par . Évalué à  2 .

            La version de chez free et bien entendu un peu limitée, mais autorise déjà à avoir une pratique plus propre du SQL, bénéficier du moteur MVCC de PgSQL, créer ses types (mais pas de ENUM car PgSQL 8.1) & domaines, découvrir les séquences (pour les habitué du autoincrement MySQL), créer des fonctions (seulement en SQL malheureusement :S), ...

            Cependant, Free utilise pour le moment la version 4.1 de ppa.
            • [^] # Re: Vision macroscopique

              Posté par . Évalué à  2 .

              > créer des fonctions (seulement en SQL malheureusement

              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 . Évalué à  1 .

                Je confirme oui :
                Erreur SQL :

                ERROR: must be superuser to create procedural language

                Dans l'instruction :
                CREATE LANGUAGE plpgsql;
                • [^] # Re: Vision macroscopique

                  Posté par . Évalué à  2 .

                  > CREATE LANGUAGE plpgsql;

                  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 à ceux qui les ont postés. Nous n'en sommes pas responsables.