Discussion :

[Gregoriz]

Bonsoir (ou bonne nuit :p) à tous,

Ayant beaucoup développé avec symfony 1.4, j'ai décidé d'utiliser le 2.0 pour un nouveau projet.

Je suis quelque peu dérouté concernant la génération du modèle. J'ai pour habitude d'effectuer une analyse à l'aide de la méthode MERISE afin de déterminer la structure de ma future base de données. En sf1.4, il était alors aisé de générer les classes relatives au modèle conçu.

J'ai cependant l'impression qu'avec le 2.0, la logique est plus orientée objet et qu'à partir de cette logique objet serait créer notre base de données relationnelle. Je me suis alors dis "pourquoi pas ?".

Seulement, dans mon modèle qui était un MCD classique (traduit ensuite en MLD), on voit apparaître la présence d'un héritage exclusif au niveau de table client. Cela permet de distinguer les contacts professionnels et particuliers tout en mettant en leurs données communes dans la table "utilisateur" (nom,prénom,login et tout le bazar).

Ne voulant pas foncer tête baissée dans les développements pour ensuite me heurter à un mur, j'ai décidé d'effectuer des recherches sur l'héritage au niveau des entités dans Doctrine 2.

Il semblerait que l'héritage que je souhaite mettre en place soit considéré de manière relativement intuitive (une classe "utilisateur" dont les classes "professionnel" et "particulier" héritent). Cependant, lorsque je lis la documentation de Doctrine relativement à l'héritage, il semblerait que cela génère une seule et unique table :

For Single-Table-Inheritance to work in scenarios where you are using either a legacy database schema or a self-written database schema you have to make sure that all columns that are not in the root entity but in any of the different sub-entities has to allows null values. Columns that have NOT NULL constraints have to be on the root entity of the single-table inheritance hierarchy.

Or, cela semble être totalement immonde d'un point de vu modélisation relationnelle dans la mesure où, en base, on se retrouve avec une tonne de champs à NULL.

Au risque de paraître has been, il me semblait que la modélisation d'héritage en MERISE avait pour but d'éviter ce genre de phénomène qui avait tendance à polluer les bases...

Toujours en lisant la documentation, j'ai vu que ce que je cherchais à faire semblait possible, seulement la conséquence de cette implémentation résultait en des performances moins bonnes qu'escomptées.

Introducing a new type to the hierarchy, at any level, simply involves interjecting a new table into the schema. Subtypes of that type will automatically join with that new type at runtime. Similarly, modifying any entity type in the hierarchy by adding, modifying or removing fields affects only the immediate table mapped to that type. This mapping strategy provides the greatest flexibility at design time, since changes to any type are always limited to that type’s dedicated table.

This strategy inherently requires multiple JOIN operations to perform just about any query which can have a negative impact on performance, especially with large tables and/or large hierarchies. When partial objects are allowed, either globally or on the specific query, then querying for any type will not cause the tables of subtypes to be OUTER JOINed which can increase performance but the resulting partial objects will not fully load themselves on access of any subtype fields, so accessing fields of subtypes after such a query is not safe.

There is a general performance consideration with Class Table Inheritance: If the target-entity of a many-to-one or one-to-one association is a CTI entity, it is preferable for performance reasons that it be a leaf entity in the inheritance hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create proxy instances of this entity and will ALWAYS load the entity eagerly.

Se pose à moi (et donc à vous aussi maintenant :p) la question de savoir quelle bonne conduite à suivre ? Dois-je forcer, au travers d'une modélisation objet moins intuitive que l'héritage de classe, mon héritage d'entités (entités issues du MLD j'entends)?
Ou dois-je plutôt ignorer tout ce que j'ai pu apprendre en analyse relationnelle et travailler sur l'analyse d'un modèle purement objet qui semble au final, générer des bases de données pas jolies jolies mais en accroître les performances ? Les différences en matière de performance sont-elles vraiment significatives ? SI oui à partir de quelle volume de données la différence devient-elle vraiment significative ?

J'espère avoir été assez clair dans mes explications. Je suis preneur de tout remarques et conseils concernant la possibilité d'avoir un modèle qui soit propre en tous points, c'est à dire aussi bien sur le respect des normes dans la modélisation de ma BD (éviter les redondances/multiples champs à NULL etc) que dans sa traduction pour son exploitation dans sf2 (ou vice versa).

je vous remercie d'avance

Gregoriz

PS: les sources de mes citations viennent de la documentation officielle de Doctrine :
https://doctrine-orm.readthedocs.org...ht=inheritance

[TogoleseBundle]

Bonsoir, j'ai le même problème, ou presque. En fait je me demande si je peux passer d'une modélisation avec MERISE et développer une application avec Symfony 3?
J'ai l'impression qu'il serait mieux d'utiliser UML...
J'ai opté pour MERISE en raison des contraintes... Pfffffffffff on nous oblige à l'utiliser!

Le problème est simple: Puis-je utiliser MERISE pour ma modélisation mais développer avec Symfony 3 ?