Articles : Nouvelle version du Fork de DBDesigner
Posté par Pierre-Yves Dubreucq (page perso, ). Modéré le 24 août 2007.
DBDesigner est un système de conception visuel de base de données, qui intègre la création et la conception de base de données (modèle conceptuel de données ou MCD, définissant les entités-association "à la" Merise) et du reverse engineering (récupération du modèle physique de données à partir d'une base existante).
DB Designer 4 ne fonctionnait à l'époque qu'avec les bases de données MySQL, mais avec DBDesigner Fork il permet de travailler avec FirebirdSQL/InterBase, Microsoft SQL Server, MySQL, Oracle et PostgreSQL.
DBD Fork permet de faire de la modélisation, du requêtage et du script SQL assez facilement.
Depuis le 31 Juillet, une nouvelle version est disponible, nous venons de passer à la 1.4.
![[en]](../images/en.png)
DBDesigner-Fork (4971 hits)-
Annonce de la version 1.4 (563 hits)
> Lire la dépêche (19 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #860905.
Run by 
Cette page a été générée par Templeet en 0.0574s (dont 0.0058 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Toolkit
En voyant le screenshot sur la page Sourceforge, je n'ai pas reconnu le toolkit. Pire, en listant le contenu du CVS, je vois des fichiers .xfm et .pas, qui ne m'évoquaient rien...
La réponse à ce petit mystère est là :
http://dbdesigner-fork.cvs.sourceforge.net/*checkout*/dbdesi(...)
Il s'agit d'un programme Kylix (pour Linux) / Delphi (pour Windows). Ah bah tiens, j'avais complètement oublié que ça existait ça...
Bon, sur ce je m'en vais essayer la version binaire.
PS: et le manuel est ici, qui montre à quel point ce logiciel est prometteur :
http://downloads.sourceforge.net/dbdesigner-fork/DBDesigner4(...)
[^]Re: Toolkit
J'avais essayé de le forker y'a 6 mois pour des besoins personnels...mais ça m'a déjà demandé un effort considérable pour arriver à le compiler (Kylix étant mort et non dispo). Et pour modifier les sources c'était une vraie galère car fortement lié à MySQL (en plus d'être du Delphi/Pascal).
En tout cas c'est une bonne initiative mais à mon avis il faudra à terme changer de langage.
P.S. Bon j'aurais pu aussi mettre mon commentaire sur le message plus bas, j'ai pris le plus simple :)
[^]Re: Toolkit
Donc tu as réussi quand même :-)
Est-ce que c'était avec Lazarus comme compilo ?
[^]Re: Toolkit
Non j'ai cherché pendant des heures avec google et autres sur des sites pas très clairs on va dire, pour choper une vieille version de Kylix. Avec cette version (pas la dernière, enfin façon de parler), J'ai pu compiler et lancer le bousin... (Kylix utilise QT pour le toolkit graphique...une vieille version particulière de QT).
Je pensais pouvoir modifier le code (besoin en MySQL 5 et PostgreSQL) mais c'était trop long pour moi (pourtant je connais(sais) le Delphi). Et puis l'appli bugguait bien quand même (ptre du à la version du compilo aussi, allez savoir !) avec un export foireux, voire des segfault.
Par contre dommage je connaissais pas le fork, cette version marche ptre mieux. En tout cas je pense qu'il y a largement moyen de réécrire ça dans un autre langage (compilé ou interprété).
En tout cas c'est bien dommage qu'il n'existe de pas de bons outils libre pour faire tout ça.
[^]Re: Toolkit
Kylix étant mort et non dispo
C'est la plaie des RAD. Quand ils sont désuets, les logiciels écrits avec sont à réécrire pour un autre RAD (ou version suivante incompatible). Je pense par exemple à la bibliothèque Borland OWL remplacée par Borland VCL (Visual Component Library). Peut-être que la nouvelle version est mieux, mais quid des anciens logiciels ? À l'école, j'avais récolté comme projet de porter un logiciel Windows (écrit pour OWL) pour Linux (avec wxWidgets). Et bien, quelle misère. En 6 mois, le portage était fait à environ... disons entre 60 et 80%. Pourtant je m'étais donné du mal. Le soucis est aussi que le code était mal écrit (fonction avec 28 arguments nommés a, b,c, ..., x, y, z, aa, bb \o/) et que le code mélangeait logique de l'application et partie interface graphique...
[^]Re: Toolkit
oh attention, OWL était à rapprocher des MFC, une approche framework mais pas du tout RAD.
historiquement c'était la fin de Turbo C++, Borland C++ et surtout Turbo Pascal ("for Windows", ah ah les pauvres clients) on pouvait utiliser ces grosses libs mais pas du tout graphiquement. il fallait ajouter son menu à son application avec ses gros doigts boudinés...
tandis que la VCL de Delphi, Borland C++ Builder, Kylix est à rapprocher (à l'utilisation hein) de Visual Basic. on dessine sa boite de dialogue puis on ajoute son code derrière les boutons simplement en cliquant dessus. toute une révolution niveau productivité (même si c'était pour produire du vite jeté)
en résumé OWL et VCL ils avaient rien à voir, même si c'était le même éditeur et peut-être le même langage.
t'as souffert mais t'as pas dû être le seul :p
Windows has no users. It has hostages.
[^]Re: Toolkit
Je connais mal OWL et peu VCL, donc c'est possible que j'ai tout mélangé. Je voulais juste insister sur le fait que dépendre d'un composant propriétaire rend un projet dépend de l'éditeur de ce composant. En quelques sortes, l'éditeur va décider pour vous du moment de la mort de votre projet.
[^]Re: Toolkit
Donc tu passes du temps à changer de toolkit parce qu'une personne a eu la flemme de coder correctement.
La base de la programmation : toujours séparer les fonctionnalités.
Un bibliothèque avec une API ouverte, un GUI par dessus, c'est beaucoup plus simple pour évoluer, mais ça demande plus de temps au debut...