Articles précédents : Logiciel
- [2] Des nouvelles de Moodle : MoodleMoot et v1.9
- [1] Plomino, construire des applications métiers sous Plone
- [34] AbiWord 2.6.0
- [50] Freenet 0.7-rc1 est disponible
- [115] OpenOffice.org 2.4
- [20] Configurez votre pare-feu Netfilter avec Nuface 2.0
- [62] Inkscape 0.46 est disponible
- [24] freedom 2.10 : conversion de fichiers
- [54] Nouvelle version de Bazaar, le DVCS de Canonical
- [7] Correction grammaticale dans OpenOffice.org
Liens connexes
- Annonce de la publication (84 hits)
- Téléchargement (48 hits)
- phppgadmin (144 hits)
- Captures d'écrans simples (574 hits)
Dépêche modérée par
Dépêche éditée par
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 ».
![[en]](../../../images/en.png)
Annonce de la publication (84 hits)-
Téléchargement (48 hits)
-
phppgadmin (144 hits)
-
Captures d'écrans simples (574 hits)
> Lire la dépêche (25 commentaires, moyenne: 3,5).
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
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.
[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Julien Fontanet (Jabber id, page perso, ) le 09/04/2008 à 11:42. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Guillaume Smet (page perso, ) le 09/04/2008 à 11:46. (lien). É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[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par ioguix (Jabber id, ) le 09/04/2008 à 12:29. (lien). É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 :)--
ioguix[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par ploum (page perso, ) le 09/04/2008 à 13:54. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
-
[^]Re: La tendance PostgreSQL
Posté par frost242 (page perso, ) le 09/04/2008 à 15:49. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par IsNotGood () le 10/04/2008 à 07:38. (lien). É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).[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par frost242 (page perso, ) le 10/04/2008 à 09:24. (lien). Évalué à 1.C'est ce que j'ai voulu dire :)
[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Lawrence P. Waterhouse (page perso, ) le 11/04/2008 à 16:33. (lien). Évalué à 1.Peut-être voulais-tu écrire :
"En revanche, tout comme Oracle, ça demande de l'investissement, mais la documentation est vraiment bien faite et surtout disponible en français."
?[ Répondre ]
-
-
-
-
-
-
[^]Re: La tendance PostgreSQL
Posté par IsNotGood () le 09/04/2008 à 13:31. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Ducerf Gaël (page perso, ) le 09/04/2008 à 13:51. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Guillaume Smet (page perso, ) le 09/04/2008 à 15:51. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par IsNotGood () le 10/04/2008 à 05:08. (lien). É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é.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Guillaume Smet (page perso, ) le 10/04/2008 à 09:37. (lien). É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é).[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par IsNotGood () le 10/04/2008 à 10:15. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par Guillaume Smet (page perso, ) le 10/04/2008 à 14:44. (lien). É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.[ Répondre ]
-
[^]Re: La tendance PostgreSQL
Posté par IsNotGood () le 11/04/2008 à 05:29. (lien). É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.[ Répondre ]
-
-
-
-
-
-
-
[^]Vision macroscopique
Posté par Kerro () le 09/04/2008 à 14:24. (lien). É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.[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par baud123 (Jabber id, page perso, ) le 09/04/2008 à 14:58. (lien). É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).[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par IsNotGood () le 10/04/2008 à 05:09. (lien). Évalué à 3.PostgreSQL est aussi disponible sur free.fr.
[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par ioguix (Jabber id, ) le 10/04/2008 à 10:33. (lien). É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.--
ioguix[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par IsNotGood () le 10/04/2008 à 10:52. (lien). É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 ?[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par ioguix (Jabber id, ) le 10/04/2008 à 13:46. (lien). Évalué à 1.Je confirme oui :
Erreur SQL :
ERROR: must be superuser to create procedural language
Dans l'instruction :
CREATE LANGUAGE plpgsql;--
ioguix[ Répondre ]
-
[^]Re: Vision macroscopique
Posté par IsNotGood () le 11/04/2008 à 04:56. (lien). É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).[ Répondre ]
-
-
-
-
-
-
Cette page a été générée par Templeet en 0.1081s (dont 0.0118 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.