Schéma YAML et base de données

Bonjour,

Dans le cadre de mon stage, on m'a demandé d'automatiser au maximum les opérations à effectuer pour générer un projet viable avec symfony et j'en suis arrivé à concevoir une classe qui, d'un schéma généré à partir d'une base de données, 'nettoie' celui-ci pour arriver à un modèle objet. Je conçois que ce n'est pas correct mais on m'a demandé de faire ça. Pour le moment, il fonctionne mais il nécessite de passer derrière pour donner du sens à certains noms de relation.
J'aimerai avoir vos avis sur cette démarche car j'ai besoin de recul sur celle-ci avant de le publier ou d'en parler dans mon rapport de stage ?

PS : je ne le partage pas encore car il n'est pas encore optimisé et que je vais surement lui rajouter des options de configuration.

Cordialement, PeytaWodka

Il arrive que les contraintes du cahier des charges oblige a passer par une base préexistante.

Ma recommandation dans ce cas là est d'importer le shema.yml depuis la base de données existante.
De le modifier pour qu'il corresponde le plus possible au modèle objet avec lequel on souhaite travailler, mais sans pour autant que la structure de la base de données générées ne change.
Générer une nouvelle base à partir de ce modèle et vérifier que la base ainsi généré correspondent bien à la base existante.
Une fois ce nouveau modèle conçu et validé, on peut alors revenir à la base de données d'origine et avec un modèle optimisé, au mieux des contraintes.

Ce travail est bien plus long, plus fastidieux, plus difficile que celui qui consiste à partir de rien pour créer ce que l'on veut. De plus le modèle objet sera construit dans un carcan qui risque de nous pénaliser lors des développements. Mais il arrive qu'il n'y ait pas d'autre possibilités.

Je suis très intéressé par ce que pourrait bien faire un module de "nettoyage" de schéma, ma seul crainte est de renforcer certaines personnes qui partent d'une base de données existante pour générer leur modèle plus par paresse que par soucis d'analyse.

J'ai exactement la même crainte que toi car malgrès que j'ai peu d'expérience je me suis vite rendu compte que de créer un schéma à la main est bien plus puissant que de l'importer car on réfléchit vraiment à quelque chose d'adapter à symfony tout en rajoutant les options propres à Doctrine qui facilite grandement le travail.
J'en suis pas encore là avec mon outil malgrès que je pense pouvoir prendre en compte le behavior Timestampable et peut-être d'autres.

Les behaviors timestamble et slug sont très configurables, il est notamment possible de changer les nom des champs.

Le modèle est très configurable, il est notamment possible d'avoir un nom de table différent du nom de l'objet et un nom de champ différent du nom de la propriété...

Après certaines propriétés ne sont prises en compte que dans le modèle, d'autre impact la base de données.

Il est aussi possible, pour adapter la souplesse, de travailler directement sur les objets du modèle et de jouer avec les getter et les setter pour adapter encore plus l'objet base à ce que l'on en veut sous symfony.

J'ai oublié de préciser que malheureusement mon outil est fortement soumis au convention c'est - à - dire que la base de données doit suivre rigoureusement des conventions dans le nom des tables afin que l'on puisse traiter les relations. C'est un gros point noir que j’essaierai de corriger quand j'aurai le temps.

Tes contraintes ne sont pas définies dans la base ?

Si par contraintes tu entends dire foreignKey, primaryKey et tout ça, oui c'est définit dans la base.
Ce que je voulais dire par convention c'est par exemple :
Une personne à plusieurs activités et une activité à plusieurs personnes. On doit retrouver les tables :
- personne
- activite
- personne_activite

Oui, c'est bien ce que je veux dire.

Et on devrait pouvoir retrouver les relations à partir de ces contraintes. Si non, le projet perd de beaucoup d'intérêt. En effet, si la sémantique des tables doit être réfléchie de manière à pouvoir être intégrée à symfony/doctrine, autant les créer directement depuis le shema.yml...

Mon outil ne travaille pas en relation avec la base de données malheureusement mais je travaille seulement sur le schéma généré par la commande doctrine:build-schema donc je ne peux déduire le type des relations que de leurs noms dans le schéma. Je conçois que c'est un gros handicap et que j'aurai pu recréer un outil de génération à partir de la base de données mais ça me semblai plus facile comme ça.
Au final, c'est assez spécifique à mon environnement de travail et c'est pour ça que je ne le partage pas pour le moment.

Je comprend.

Note que l'outil de base crée aussi des relations à partir des contraintes, il est peut-être envisageable de les exploiter.