Forum Programmation.php generateur de schema SQL

Posté par  .
Étiquettes : aucune
0
3
août
2004
Bonjour,

Ca n'a rien a voir avec php, mais je me suis dis que je pourrais trouver des spécialistes SQL ici.

En fait, Je suis entrain de faire une petite base de données (le fichier .sql avec les requetes de création de tables et tout ca...).

Seulement, j'en ai un peu marre de faire les schémas relationnel a chaque fois que je refais la base.

Je cherche donc un petit script (perl par exemple, pas un truc lourd), pour me générer un schéma relationnel (un .png par exemple) à partir du fichier .sql.

du genre:

$] design_generator.pl ./my_db.sql -o my_db.png

Ca existe ca ???

  • # DBDesigner

    Posté par  (site web personnel) . Évalué à 2.

    C'est pas exactement ce que tu cherches, mais çà peut toujours t'aider :

    http://www.fabforce.net/dbdesigner4/(...)

    • [^] # Re: DBDesigner

      Posté par  . Évalué à 1.

      merci bien.
      Il gère même SQLite (c'est ce que je voulais, et j'avais peur qu'il ne le gère pas).
      bien sympa ce petit truc.

      Parcontre, si quelqu'un connait un truc plus léger, je suis preneur quand meme.
      j'ai pas du tout besoin d'editer le schéma, juste "visualiser".

      Bon, ben si ca existe pas. un petit coup de perl-gd devrait me permettre de faire quelque chose....

    • [^] # Re: DBDesigner

      Posté par  . Évalué à 1.

      J'ai essayé ce truc, c'est vraiment inutilisable. ça rame complètement. L'affichage est merdique, ça flashe de partout, y a vraiment un gros soucis. (sur mdk 10)
      En plus de certains bugs/fonctionnalités avec les clés étrangères qui ne me plaisent pas du tout.

      • [^] # Re: DBDesigner

        Posté par  . Évalué à 1.

        J'ai une mdk10 aussi, sur une machine pas franchement extraordinaire (P3 750MHz, 360Mo), et ça marche plutôt bien (un peu lent, rafraîchissement saccadé, mais bon).

        La gestion des clés étrangères est certes un peu déroutante quand on a l'habitude de dessiner soi-même son MCD à la main, mais on s'y fait (et on peut toujours renommer ces clés-là).

        En outre, le code SQL pondu est tout ce qu'il y a de plus propre, jusqu'ici.

  • # Hé hé !

    Posté par  . Évalué à 2.

    J'avais un truc qui faisait un fichier xml utilisable sous Kivio (ou Dia) à partir d'une base de données. Je ne me souviens plus du tout de l'endroit où je l'avais récupéré. Si tu n'es pas trop pressé, je peux regarder en début de semaine prochaine au boulot si je peux retrouver les sources de ce truc.
    Sinon, si tu es trop pressé, il faut aller fouiller dans les tables systèmes pour voir comment tout ça est construit.
    J'avais "bricolé" un truc également qui me récupérait toutes les relations entre tables sous forme d'arbre (non équilibré), enfin, un tableau associatif php, quoi !
    J'avais abandonné car je m'étais retrouvé à cours de temps, et incapable de l'utliser cet arbre....Enfin, je voulais l'utililser pour un générateur de requêtes automatiques, comme base pour construire automatiquement la clause where (ou from, c'est selon), avec les jointures qui vont bien, mais je ne savais pas par quel bout prendre ce problème, c'est tombé à l'eau.
    Si tu es intéressé par ces scripts, envoie-moi un mail à david point bouriaud chez ac moins rouen point fr, et je verrais ça lundi prochain.
    Ce ne sont que des bases (la première n'est même pas de moi), mais si ça peut t'être utile....

  • # graphviz

    Posté par  (site web personnel) . Évalué à 1.

    en fait, le plus simple est de paser par graphviz. Un parser genere un graphe .dot, et ensuite graphviz s'enquiquine à l'afficher joliement.
    Ce qui est embetant, c'est mysql ne gérant pas les clefs étrangères, il faut utiliser une astuce de nomencalture (du genre id_matableetrangere) pour que le parser s'y retrouve.

    et voila, ya un truc qui existe :
    http://sqlfairy.sourceforge.net/(...)

    et voici un screenshot qui va bien :
    http://sqlfairy.sourceforge.net/images/graphviz.png(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.