phpPgAdmin est une interface web d'administration de PostgreSQL sous licence GPL (à l'image de phpMyAdmin, dédié à MySQL), on en parlait sur DLFP à la mi-février. La version 3.0.0-dev-1 est publiée, fait suite à la 2.4.2, et est le même code que WebDB 0.6.5 (pas de Release Notes, mais la TODO list est bien remplie).
Un nouveau bouquin sur PostgreSQL est publié : « PostgreSQL, A comprehensive guide to building, programming and administering PostgreSQL databases » par Korry Douglas et Susan Douglas. Un sommaire est disponible en ligne, ainsi que le code SQL utilisé comme exemple. Du côté logiciel propriétaire, Aqua Data Studio v2.0 (de AquaFold, Inc.) est sorti. C'est un outil multiplateforme développeur dédié à la gestion de base de données. Il supporte de multiples RDBMS dont MySQL et PostgreSQL, et est développé en Java.
http://www.aquafold.com/
Toujours du côté logiciel propriétaire et sous MS Windows exclusivement, EMS HiTech lance PostgreSQL Manager 1.3 et PostgreSQL DataPump, respectivement outil de gestion et outil d'import/export de données de bases compatibles ADO.
http://www.ems-hitech.com/pgmanager/
http://www.ems-hitech.com/pgsqlutils/
DBOne est un ShareWare d'administration multi-RDBMS sous Windows, gratuit et limité à 60 jours.
http://www.dbone.info/dbone/mainpage.php
Le sommaire du bouquin :
« PostgreSQL, A comprehensive guide to building, programming and administering PostgreSQL databases »
I. GENERAL POSTGRESQL USE.
1. Introduction to PostgreSQL and SQL.
2. Working with Data in PostgreSQL.
3. PostgreSQL SQL Syntax and Use.
4. Performance.
II. PROGRAMMING WITH POSTGRESQL.
5. Introduction to PostgreSQL Programming.
6. Extending PostgreSQL.
7. PL/pgSQL.
8. The PostgreSQL C API-libpq.
9. A Simpler C API - libpgeasy.
10. The PostgreSQL C++ API - libpq++.
11. Embedding SQL Commands in C Programs - ecpg.
12. Using PostgreSQL from an ODBC Client Application.
13. Using PostgreSQL from a Java Client Application.
14. Using PostgreSQL with Perl.
15. Using PostgreSQL with PHP.
16. Using PostgreSQL with Tcl and Tcl/Tk.
17. Using PostgreSQL with Python.
III. POSTGRESQL ADMINISTRATION.
18. Introduction to PostgreSQL Administration.
19. PostgreSQL Administration.
20. Internationalization and Localization.
21. Security.
Aller plus loin
- PostgreSQL - RedHat Edition (17 clics)
- phpPgAdmin (29 clics)
- phpPgAdmin 3.0.0-dev-1 / WebDB 0.6.5 (14 clics)
- DLFP : PostgreSQL : le plein de nouvelles (26 clics)
- Le bouquin (13 clics)
# Re: De nouveaux outils PostgreSQL
Posté par dinomasque . Évalué à 10.
BeOS le faisait il y a 20 ans !
[^] # Re: De nouveaux outils PostgreSQL
Posté par Olivier M. . Évalué à 10.
Elle tape bien :)
# Re: De nouveaux outils PostgreSQL
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
http://www.ems-hitech.com/pgmanager/(...)
http://www.ems-hitech.com/pgsqlutils/(...)
DBOne est un ShareWare d'administration multi-RDBMS sous Windows, gratuit et limité à 60 jours.
http://www.dbone.info/dbone/mainpage.php(...)
Euh... c'est toujours linuxfr.org ici ou je me suis trompé de site ?
Ok, je vais voir là-bas si j'y suis.
[-1]
[^] # Re: De nouveaux outils PostgreSQL
Posté par Xavier Antoviaque (site web personnel) . Évalué à 0.
[^] # Re: De nouveaux outils PostgreSQL
Posté par Jerome Herman . Évalué à 5.
pqAdminII : http://www.pgadmin.org(...) qui est libre et qui de plus a l'avantage de tourner sous Wine.
C'est un outil d'administration tres complet et tres simple a utiliser. Par contre il ne fonctionne que par lien ODBC donc il faut activer le -i dans le postmaster et autoriser la machine (meme si c'est la meme).
Il ne lui manque qu'un mode qui permettrait de coder des fonctions a l'interieur de l'interface.
Kha
# phpPgAdmin
Posté par swix . Évalué à 5.
de mysql a pgsql sur 1 ou 2 serveurs: la partie serveur fonctionne bien, mais alors
coté administration ou "bricolage" via web (creer des tables, modifier des
champs, ajouter/editer des entrées) j'ai abandoné: phpPgAdmin 2.x était inutilisable.
Quant à la version 3, j'ai tenté de la faire fonctionner, mais sans parvenir a depasser
l'ecran de login...
Bref: à ceux qui utilisent pgsql quotidiennement: comment travaillez vous avec ?
Tout en mode de commande via psql ? Ou y'a-t-il de vrais outils utilisables ?
Merci :)
[^] # Re: phpPgAdmin
Posté par Olivier M. . Évalué à 9.
Je travaillais avec psql (quand j'avais la flemme de lancer autre chose), pgaccess (la version dont j'ai donne le lien plus haut) et phppgadmin (je ne sais plus quelle version, celle de debian/unstable de l'epoque), sans avoir de souci majeur avec aucun de ces outils.
Cela dit, je veux bien croire que PG est moins accessible que MY. Ils n'ont de toutes facons pas le meme objectif a la base. MySQL est tres oriente particulier (ou du moins l'a ete) alors que PGSQL vise plutot les "grands" (Oracle, DB2, ...)
[^] # Re: phpPgAdmin
Posté par swix . Évalué à 3.
Genre pour savoir ou sont les grandes différences, etc. : par exemple dans pgsql il
y 36000 types de fields, des tables bizarres, et un tout autre systeme pour gerer les
droits des users. On va demander a google... :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: phpPgAdmin
Posté par xsnipe . Évalué à 2.
[^] # Re: phpPgAdmin
Posté par Pat . Évalué à 2.
Donc, comme beaucoup l'on déjà dit, MySQL est supper rapide, mais c'est facile d'être rapide quand tu fais presque rien.
Cette phrase est de moin en moin vrai cependant avec les versions c'est mieux.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: phpPgAdmin
Posté par ptit_tux . Évalué à 7.
[^] # Re: phpPgAdmin
Posté par xsnipe . Évalué à 2.
Mais bon, suis pas un (gros) expert en BDD, suis juste un petit webmaster débutant...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: phpPgAdmin
Posté par ptit_tux . Évalué à 9.
- "Disables fsync calls for performance improvement, at the risk of data corruption in event of a system crash. Read the detailed documentation before using this!"
[^] # Re: phpPgAdmin
Posté par matiasf . Évalué à 6.
[^] # Re: phpPgAdmin
Posté par Emmanuel BENOIT . Évalué à 2.
En effet, le problème de faire les contrôles au niveau des scripts/programmes d'interfaçage est que, si pour une raison ou pour une autre, le besoin se fait sentir d'accéder directement à la base (pour des questions de maintenance, pour des modifications massives, etc...), des problèmes de cohérence peuvent se poser. Il devient facile de faire une erreur.
Si les contraintes d'intégrités sont placées au sein de la base elle-même, ce genre de problème est évité : en effet, qu'une requête soit faite depuis les scripts d'interfaçage ou depuis l'outil d'accès en ligne de commande (ou tout autre outil d'accès à la base), le résultat sera toujours le même. Une requête invalide (dans le sens où elle menace la cohérence des données stockées) sera refusée.
[^] # Re: phpPgAdmin
Posté par jMax . Évalué à 2.
Allez quoi c'était juste pour rire...
Bon d'accord, -1
[^] # Re: phpPgAdmin
Posté par Gloo . Évalué à 9.
"Franchement, est ce que vous trouvez ce truc utilisable""
Bien plus utlisable que mysql... Pour un tas de systemes logiciels mysql ne peut pas tenir la route sauf en descendant ce qui DEVRAIT etre traité par le SGBD au niveau applicatif. Cette dernière chose ayant pour consequence que l'appli elle meme ne tient plus la route.
"Surtout que PostgreSQL peut s'utiliser comme MySQL. L'inverse étant ... "
... Impossible dans la plupart des cas ou un SGBDR est necessaire.
"MySQL commencent à le rattraper"
Postgresql, ca fait des années qu'il a un tas de fonctionnalités d'avance, alors que mysql promet ces dernières depuis des années.
Un tiens vaut mieux que deux tu l'auras (sans experience par dessus le marché).
Donc bon, rattraper... Il y a encore un sacré nombre d'années à attendre encore pour que mysql arrive où postgresql en est AUJOURD'HUI.
"j'ai vraiment l'impression que c'est une grosse usine à gaz PSQL"
Un SGBDR comme postgresql implementant:
- les foreign keys (avec on delete, on update...)
- les procedures stockées
- les triggers (un peu la meme chose)
- les subqueries (insert [...] select )
- les views
- les "select into"
- les transactions (qui ne resemblent pas à du bricolage)
- ...
est forcement plus lourd qu'un parseur de fichier binaire avec un frontend SQL (je suis un peu mechant là) comme mysql, qui est néanmoins très bien dans le cadre de certaines applications.
Pour les outils, je n'ai encore rien trouvé de mieux que perl, les expressions regulières (pardon amis de la langue française), emacs et la ligne de commande, pour parser/traiter des .sql lorsque des centaines de table sont dans la place.
Ce qui a fait le succès de mysql c'est le (quasimment) zero admin qui a permis au hebergeurs grand public de le proposer. Bref, le succès de mysql est lié au succès du net. Rien d'autre.
[^] # Re: phpPgAdmin
Posté par mermaid . Évalué à -1.
graphiques ....
Quotidiennement, tout en mode de commande.
Ni.
[^] # Re: phpPgAdmin
Posté par swix . Évalué à 3.
[^] # Re: phpPgAdmin
Posté par Larry Cow . Évalué à 0.
Les seuls trucs que j'ai fait via psql, jusqu'ici, c'est plus de l'ordre du contrôle que de la modification. Et puis tu peux toujours lui demander de prendre les tuples dans un fichier.
[^] # Re: phpPgAdmin
Posté par swix . Évalué à 0.
oui bien sur, quand l'appli est programmée et en fonction, mais pendant le dev ? :)
[^] # Re: phpPgAdmin
Posté par Larry Cow . Évalué à 2.
Et une fois que le frontend est opérationnel, je teste avec des textes plus importants. De toutes façons, TEXT est théoriquement fait pour gérer un nombre arbitraire de caractère (préférablement grand, mais bon); donc il y'a assez peu de chance de voir ton appli devastée par le passage d'un TEXT contenant 5 caractères à un TEXT en contenant 3000 (sauf peut-être en termes de perf, mais c'est plutôt le genre de choses qu'on teste justement pas sans rien).
[^] # Re: phpPgAdmin
Posté par Antonio Da Silva (site web personnel) . Évalué à 3.
Jamais aucun problème avec, très utile pour les modifications simples.
Pour les requêtes longues et leur debug rien ne vaut la console.
Mais ça m'a pas mal aidé dans le temps ( plus ça va, moins j'ai besoin d'accéder à la base directement)
nioTo
[^] # Re: phpPgAdmin
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
[^] # Re: phpPgAdmin
Posté par jMax . Évalué à 3.
édition d'un fichier sous OppenOffice.org enregistré au format csv
import depuis pgaccess
(pratique quant on a beaucoup de tuples à saisir avec des champs qui se répètent souvent)
- La mise au point de query :
psql parce qu'il y a l'historique des dernières commandes tapées et que c'est super pratique
- La maintenance générale :
heuu... y'en a ? un pg_dump de temps en temps tout au plus...
enfin quand y'en a je bricole depuis pgaccess ou psql, c'est selon...
[^] # Re: phpPgAdmin
Posté par redguts . Évalué à 1.
# Re: De nouveaux outils PostgreSQL
Posté par zyglotron . Évalué à 3.
http://www.globecom.se/tora(...)
Voilà
Chris
[^] # Re: De nouveaux outils PostgreSQL
Posté par DPhil (site web personnel) . Évalué à 3.
Sinon, pour Oracle, c'est un vrai bijou.
[^] # Re: De nouveaux outils PostgreSQL
Posté par zyglotron . Évalué à 1.
Merci pour la précision.
# Re: De nouveaux outils PostgreSQL
Posté par Rossel Olivier . Évalué à 6.
Personnellement, je fais de la pub pour Druid (http://druid.sourceforge.net(...)). C'est un logiciel en java vraiment efficace pour importer/exporter des modeles de base, faire des requetes, dessiner un schema de la base et generer du code Java ou la conf d'outils de mapping tels que Castor.
Tiens, tant que j'y suis, y a aussi Middlegen (tjs en java) qui est un super generateur de code pour EJB et Hibernate.
# Quid de SAP DB
Posté par Jérôme Baumgarten . Évalué à 1.
Merci d'avance.
Jerome
# Re: De nouveaux outils PostgreSQL
Posté par Frédéric Desmoulins (site web personnel) . Évalué à 6.
Je suis persuadé (et l'experience l'a prouvé) que taper ses sources SQL correspondant a son modele de BD vaut bien mieux. D'abord, parce que l'implementation utilisera des fonctions normalisées et surtout parce que le jour ou il faudra changer de SGBD le portage des BD se fera sans soucis (enfin avec moins de soucis).
MySQL par ex. (pas la derniere version hein :), va accepter mes declaration de cles secondaires, mes contraintes sur des update/delete etc. sans pour autant les prendre en consideration. Le jour ou je change pour passer sous Postgres, je suis heureux d'avoir mon ptit fichier pour genrerer mes tables 'proprement' plutot que d'avoir un fichier tout bizarre généré par phpMyAdmin ou toute mes contraintes ont disparu.
En plus, lorsque le modele conceptuel de BD est realisé, l'implementation prend generalement peu de temps et AMHA l'emploi d'un outil fait plus perdre du temps qu'autre chose pour peu qu'on connaisse la syntax SQL.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.