J'ai essayé MeriseAcide, et je trouve que pour faire un modèle de données "propre", il a des inconvénients (ou des fonctionnalités que je n'ai pas trouvées :
- les clés étrangères ne sont pas nommées nommées identiquement ie (une clé étrangère matable.monchamp est appelée fkmonchamp et nom pas monchamp, ce qui est moins intuitif)
- le SQL généré inclus un "ON DELETE CASCADE" systématiquement, ce qui n'est pas forcément ce que l'on recherche (s'il faut retoucher le SQL au niveau "modèle", l'outil perd pas mal de son intérêt)
- L'outil ne propose pas de créer des indexes (on peut le faire en ajoutant le code nécessaire)
Ces problèmes peuvent être contourné en "codant" directement ce qui est nécessaire, néanmoins du coup les diagrammes générés ne sont pas corrects.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: MeriseAcide - limitations
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal MySQL-workbench : conception de bases de données relationnelles pour tous les SGBDR SQL ?. Évalué à 2.
- les clés étrangères ne sont pas nommées nommées identiquement ie (une clé étrangère matable.monchamp est appelée fkmonchamp et nom pas monchamp, ce qui est moins intuitif)
- le SQL généré inclus un "ON DELETE CASCADE" systématiquement, ce qui n'est pas forcément ce que l'on recherche (s'il faut retoucher le SQL au niveau "modèle", l'outil perd pas mal de son intérêt)
- L'outil ne propose pas de créer des indexes (on peut le faire en ajoutant le code nécessaire)
Ces problèmes peuvent être contourné en "codant" directement ce qui est nécessaire, néanmoins du coup les diagrammes générés ne sont pas corrects.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo