Cher journal, je viens de (re-)trouver SQL::Translator pour effectuer des conversions entre PostgreSQL et MySQL [1] que je vais de ce pas essayer.
Mon objectif est de pouvoir générer des MCD (Modèle Conceptuel de Données) à partir des commandes de création de tables.
J'ai bien essayé DBDesigner4 pour générer automatiquement le MPD (Modèle Physique de Données) avec l'option Menu Database / Reverse Engineering mais cela ne fonctionne qu'avec des bases MySQL (pas PostgreSQL ou alors je n'ai pas trouvé...). D'ailleurs, DBDesigner4 est-il encore maintenu ? Je n'ai pas réussi à trouver le CVS qui permettrait de disposer d'une version récente (voire plus jolie sous Gnome, les boutons étant plutôt mal adaptés au texte qui dépasse)
Je préfèrerais pouvoir utiliser Dia, pour pouvoir plus facilement changer l'apparence du diagramme et les champs affichés : j'ai vu AutoDia [2] qui permet en ligne de commande de générer les diagrammes (bizarre personne n'a intégré cela à l'interface graphique ? je n'ai pas vu de greffon d'importation ou alors j'ai mal cherché : ça réaliserait quasi-directement la fonction de "reverse engineering" !?).
J'avais fait une recherche des différents outils de conception (UML / Merise / génération de code PHP) [3]
J'ai trouvé assez peu de tutoriaux les mettant en oeuvre, ce pourquoi je commence ce journal privé pour essayer de les utiliser de bout en bout : au final, ce serait pas mal d'obtenir la génération semi-automatique du code php permettant la gestion de création / mise à jour / affichage de données d'une base (si possible conforme XHTML 1.0 / CSS2).
Si vos recherches vous ont permis de trouver quelques compléments, je suis preneur bien sûr.
[1] http://sqlfairy.sourceforge.net/(...) SQL::Translator
[2] http://droogs.org/autodia/(...) création automatique de diagrammes UML / DB
[3] http://wiki.eagle-usb.org/wakka.php?wiki=ModelizationTools(...) liste d'outils de modélisation / génération de code php
Journal Conversions MySql / PostgreSQL et MCD/MPD
26
fév.
2005
# Eclipse
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
[^] # Re: Eclipse
Posté par BAud (site web personnel) . Évalué à 2.
J'ai cru voir qu'il pouvait tourner en GTK, je suppose donc sans Java ? (en espérant que ça réduise les besoins mémoire...)
Si en plus, il y a les plugins UML, PHP, SQL c'est clair qu'eclipse aurait l'avantage de tout intégrer dans un même environnement, ce qui est souvent bien pratique pour ne pas être dépaysé ;-)
[^] # Re: Eclipse
Posté par Sebastien (site web personnel) . Évalué à 3.
Oulah, non, malheureux! En fait, l'interface graphique d'Eclipse est faite avec la bibliothèque SWT qui elle même repose sur des bibliothèques natives, telles que Motif mais donc aussi GTK. Eclipse peut tourner avec SWT/GTK, mais cela reste un IDE en Java quand même.
À mon avis, 256Mo, c'est sans doute vraiment trop juste pour Eclipse. 512Mo est pratiquable, 1Go commence à être confortable.
seb.
[^] # Re: Eclipse
Posté par BAud (site web personnel) . Évalué à 3.
bah je testerai quand j'aurai un vrai PC (m'enfin franchement - sans vouloir lancer de troll - c'est n'importe quoi la conf' d'un serveur de développement maintenant :-) ça sent la débauche de ressources quelque part - sans vouloir revenir au mode texte pour autant, même si j'ai de très bons souvenir de l'IDE de Borland C++, enfin Turbo C++).
[HS]
Là dans mes 256 Mo tout pourris, j'ai quand même un serveur apache + php + MySQL + PostgreSQL qui fonctionnent (en même temps que mon desktop Gnome + Evolution + Firefox et 25 onglets ouverts + xchat + gedit + gnome-terminal + gkrellm pour surveiller la débauche de ressources ! Quand je pense que rien que la net_applet bouffe 5 Mo en mémoire RSS et 25 Mo en virtual !!).
[/HS]
[^] # Re: Eclipse
Posté par Yannick (site web personnel) . Évalué à 0.
[^] # Re: Eclipse
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
Evidemment, pour des gros projets java, 1go, c'est mieux voire indispensable, mais perso, je l'utilise pas mal pour du PHP et pour son plugin CVS et c'est nickel.
En trois mots, ca se tente, au moins pour l'utilisation que tu veux en faire.
# Sur DBDesigner
Posté par norbs . Évalué à 4.
Apparement les développeurs ont été embauchés par mysql, et ne travaillent plus sur le projet depuis plus d'1 an. Vraiment dommage ! Et encore plus dommage que le soft soit écrit avec kylix, ce qui est vraiment un frein à la reprise du programme par quelqu'un d'autre.
Autrement j'ai repéré récement http://sourceforge.net/projects/mogwai/(...) qui est plutôt pas mal même si pas encore assez "poli".
> au final, ce serait pas mal d'obtenir la génération semi-automatique
> du code php permettant la gestion de création / mise à jour /
> affichage de données d'une base (si possible conforme XHTML 1.0 /
> CSS2).
DBdesigner le fait via un plugin intégré (SimpleWebFront)
[^] # Re: Sur DBDesigner
Posté par BAud (site web personnel) . Évalué à 3.
C'est vraiment dommage pour DBDesigner4, un collègue l'utilise aussi sous windows et c'est tout de même bien fait (ne manque que PostgreSQL ;-) ). Espérons que les auteurs originaux (ou d'autres) feront un fork pour le passer en QT ou GTK afin de lui donner une nouvelle vie.
ça risque d'obliger à refaire toutes les fenêtres s'il n'y a pas d'outil de migration vers QT ou GTK, mais sinon tous les appels à Kylix doivent être remplaçables... un projet un peu bourrain au démarrage mais intéressant sur le long terme ;-)
# finalement, j'ai eu du mal à installer SQL::Translator
Posté par BAud (site web personnel) . Évalué à 2.
Il y a beaucoup de dépendances que je n'ai pas encore réussi à installer : le perl Makefile.PL # répond encore :
WARNING: SIGN is not a known parameter.
Checking if your kit is complete...
Looks good
Warning: prerequisite Class::Base 0 not found.
Warning: prerequisite Test::Differences 0 not found.
Warning: prerequisite Text::RecordParser 0.02 not found.
'SIGN' is not a known MakeMaker parameter name.
Writing Makefile for SQL::Translator
J'en ai installé une palanquée parmi :
'Class::Base' , 'File::Basename' , 'File::Spec' , 'GD' , 'GraphViz' , 'IO::Dir' , 'IO::File' , 'IO::Scalar' , 'Parse::RecDescent' , 'Pod::Usage' , 'Spreadsheet::ParseExcel' , 'Template' , 'Test::More' , 'Test::Exception' , 'Test::Differences' , 'Text::ParseWords' , 'Text::RecordParser' , 'XML::Writer' , 'XML::XPath' , 'YAML'
mais visiblement
ça m'a permis de (re-)découvir cpan au passage, mais c'était pas trop l'objectif... je crois que je vais attendre qu'il y ait un package disponible (si quelqu'un réussit à l'installer proprement ou rencontre moins de problèmes que moi...).
# pour l'instant autodoc ça le fait
Posté par BAud (site web personnel) . Évalué à 2.
L'install est "standard", j'ai pris la version 1.24 d'Octobre 2004 (ya pas de package :-( oui, je suis sous Cooker...) :
./configure
make
make install # sous root
Ensuite postgresql_autodoc -d [nom_de_la_base] génère automatiquement :
HTML, Dot, Dia et DocBook XML pour toutes les tables de la base PostgreSQL.
(bon il faut qu'elle soit opérationnelle et accessible, bref j'ai aussi dû corriger un petit problème qui empêchait le service postgresql de démarrer : un rm /var/lib/pgsql/data/postmaster.pid a fait l'affaire... ainsi que le changement d'emplacement de PGDATA)
Il serait intéressant qu'autodoc puisse se contenter du fichier sql pour éviter d'avoir une base opérationnel (ça doit être faisable...).
A l'ouverture dans Dia
- toutes les tables sont dans le coin supérieur gauche : il faut les répartir sur la feuille
- les clés étrangères sont traduites sous forme de contraintes (dans Dia c'est le formalisme UML qui est retenu)
Bon, je n'ai pas encore trouvé comment remplacer les flèches droites par des flèches brisées pour réorganiser un peu plus facilement la mise en forme... j'espère que c'est possible ? (par exemple en sélectionnant tous les objets de type contrainte et en appliquant un "changement de style")
Plus d'explications sur le formalisme UML dans Dia pour les diagrammes de base de données sont disponibles ici : http://tedia2sql.tigris.org/usingtedia2sql.html(...) (et hop' un outil de plus pour générer automatiquement du SQL à partir du diagramme...)
J'ai placé les résultats obtenus ici : http://wiki.eagle-usb.org/wakka.php?wiki=HowToDia(...)
Dommage, le SVG est très mal généré : ça prendrait beaucoup moins de place que le png (moins de 5 ko en compressé / ~60 ko en non compressé contre plus de 300 ko).
En tout cas un très bon point : dans Dia, chaque table reste éditable (ajout de champs...) ça peut donc effectivement servir d'outil permettant de gérer un MCD / MPD et générer le SQL kivabien ensuite... si vous avez des résultats aussi positifs je suis preneur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.