Relations de compositions entre table

Bonjour,

je débute dans la programmation avec Symfony avec des bases en PHP et SQL.

Je ne connais pas bien Doctrine que j'utilise actuellement d'après plusieurs tutoriaux que j'ai pu lire, ils semblent en majorité le recommander.

Ma question est plutôt simple mais je n'arrive pas à y trouver une réponse.

Après avoir vu que l'héritage entre table était faisable dans la description en Yaml, je voulais savoir si une relation de composition/aggrégation façon UML était faisable et si oui, comment le faire.

Autre petite question, est-ce normal qu'un ENUM en SQL soit transformé en VARCHAR(X) ou en String en Yaml ? (Mon Yaml a été généré à partir de la base que j'ai codée à la main en SQL.)

Merci d'avance

Noobboy

P.S : Si besoin de plus de renseigments, n'hésitez pas.

Oups, je pense que cette question est posée dans la mauvaise section.

Je pense qu'il serait plus à sa place dans la section "ORM" ?

Bonjour, et bienvenue sur Symfony :)

Concernant ta question sur les compositions/aggrégation, Doctrine gère 3 types d'héritage différent, dont l'un qui est l'aggrégation. N'étant pas expert en UML je ne sais pas trop si tu vas trouver ton bonheur, mais il y a un exemple assez parlant ici :
http://www.symfony-project.org/more-...rm-Inheritance

Concernant les enum, la réponse est non, ce n'est pas normal ^^.
Cela est dû au fait que la commande permettant de faire SQL => yml existe pour faciliter la vie, mais nécessite d'être utilisée avec soin (vérification du yaml généré obligatoire). La bonne pratique consiste autant que faire se peut à écrire d'abord le fichier yml qui va ensuite piloter tous les modèles Doctrine (doctrine:build --all ou dérivés)

Pour ce qui est de l'aggrégation, j'étais effectivement tombé là dessus en cherchant si l'héritage existait en YAML / Symfony. Je vais re-regarder ça pour voir si ça peut correspondre.

Je ne suis pas convaincu pour l'instant de la pertinence quant à la composition. Mais c'est un élément de réponse.

Citation:

---

La bonne pratique consiste autant que faire se peut à écrire d'abord le fichier yml qui va ensuite piloter tous les modèles Doctrine (doctrine:build --all ou dérivés)

---

Tu parles ici du fichier schema.yml ou ai-je raté une étape ?

Oui le fichier schema.yml

Dans un projet Symfony "classique", il faut :

1 - écrire le fichier schema.yml
2 - utiliser la tâche doctrine:build --model pour créer des modèles (classes PHP) correspondant à ce schema
3 - utiliser doctrine:build --sql pour générer le SQL correspondant à ces classes (les CREATE TABLE, etc)
4 - utiliser doctrine:insert-sql pour exécuter ce SQL

(ou sinon la tâche doctrin:build --all fait tout en même temps, là c'était pour le détail)

Lorsque tu as déjà une base de données existante, la tâche doctrine:build-schema permet de faire le cheminement inverse, mais cela est souvent source d'erreur et d'instabilité.
Si tu es obligé de procéder ainsi, le mieux est je pense de bien te renseigner sur les tâches de migration, et de te définir un processus bien précis de synchronisation entre la BDD déjà existante et le nouveau projet symfony.

Il faudrait être plus précis sur ce que tu veux comme schéma.

Pour les enum, doctrine les gères... enfin, quoique. La bonne pratique est de ne pas utiliser de enum dans ton shema.yml, ils apportent plus de problèmes que de solutions.

D'accord.

Non, ce n'est pas imposé.

Le tutoriel que j'ai lu fonctionnait comme ça, voilà pourquoi je me suis retrouvé avec une BBD SQL exportée en yml.

Sinon, voici un diagramme succint de ce que je souhaite réaliser avec les compositions (et avec de l'héritage mais je sais déjà comment organiser ça en Yaml ;) ). Pour pouvoir changer plus facilement dans l'outil d'administration, une table à part avec la liste des statuts. (Modélisé ici façon langage objet)

http://img709.imageshack.us/img709/4...edeclasses.png

Je crains que l'analyse et le schéma qui en découle ne soit erronée.

Quel est la différence entre : porteur, partenaire et personneMobilité ? Si ce n'est certaines propriétés, ces objets semblent sémantiquement correcte. De plus, ton organisation forcera à une réécriture du code si tu souhaites rajouter, à terme, une catégorie.

Tout d'abord, merci de ta réponse. :)

Il est fort possible que l'analyse soit érroné, je ne suis qu'étudiant.
S'il y a effectivement 3 classes dérivants de ma classe-mère Personne qui ont toutes un attribut qui a un nom sensiblement identique, les "statuts" de ces différentes "Personne" auront une intersection vide.
C'est là la différence entre ces trois entités, trois listes énumérées différentes.

S'il est possible de sélectionner les statuts disponibles dans l'ensemble des statuts d'une "Personne" en fonction de ce qu'est la personne (appartenant à un des trois cas ici développé) -selon un attribut de la classe par exemple- lors de l'insertion d'une personne particulière dans la base alors oui, c'est une erreur d'analyse.

C'est aussi dans un soucis de modification, d'ajout et de retrait simplifié d'éléments à ces ensembles de statuts que j'ai encore sub-divisé les statuts en une classe -qui je pense sera une table-.

Sous cet éclairage, sembla est-ce toujours incorrect ?

A partir du moment où, pour ajouter une classe de personne, tu dois redévelopper c'est qu'il y a un problème.

Sauf si tu es absolument certain au niveau de ton analyse qu'il n'y a aucune possibilités de rajout d'une classe et que le rajout d'une classe implique l'ajout de fonctionnalité bien en dehors de la simple gestion de la classe.

Comme dirait l'autre, l'imbécile est affirmatif, le sage doute toujours.
(Je précise que ce n'est pas une attaque de quelconque manière que ce soit mais un principe que j'essaye d'appliquer.)

Je ne suis certain de rien actuellement.

Selon ce qui m'a été dit et d'après le cahier des charges, ce sont les trois types de personnes qui intéressent les usagers de ce que je dois produire. Aucun autre type de personne n'interagit avec mon futur système.

Si j'ai agit de la sorte, c'est parce que je supposais d'après ce que j'ai pu lire que hiérarchiser comme ceci rendrait plus simple l'accès et la modification des "statuts".
Il sont relatifs à chacun de ces types de personne et donc m'ont parus plus pertinents en étant séparés.

Si la distinction et donc le fait que pour ajouter un type de personne, il faille recréer une classe et donc une table te semble très problématique, quel solution existe pour faire que les statuts de chaque type de personne soient proposés uniquement au type de personne approprié ?

Un attribut "Type" dans la classe personne et une liste de statuts avec en quelque sorte l'identifiant du type de personne approprié ?

J'avoue être assez peu habitué au développement en sql / symfony et donc je ne vois pas exactement tous les tenants et les aboutissants d'une action en amont sur la complexité du code php en aval.

C'est juste pour avoir un type de partenaire ?

Tu l'indiques quant dans le cycle de vie ?

J'ai simplifié grandement mon UML pour que ça déforme pas la page et que ça reste un minimum concis.

Le type de partenaire / porteur / personne est renseigné à la création des objets.

Il servira par la suite à trier par catégorie les contrats auquels sont liés les différententes personnes.

Alors peut-être que je veux faire deux trucs en même temps mais j'aimerais qu'on ne puisse attribuer des statuts à un type de personne que si ce statut leur est disponible.

En dehors de toute conception (que je trouve pas si mauvaise que ça AMHA), l'héritage entre Personne et les trois autres classes est "simple" à mettre en place avec Doctrine, il faut juste choisir en l'héritage concret ou l'héritage par agrégation >> http://www.doctrine-project.org/proj...ce/en#concrete (L'héritage simple semble peu intéressant).

Pour la relation de composition avec le statut, dites-moi si je me trompe, ça ressemble à une simple relation 1-N ou au pire un enum.

Oui, pour ce qui est de l'héritage, comme dit plus haut, j'ai trouvé tout ce qui me fallait. ;)

Une relation 1-N, c'est une relation one to many ?

Oui voila. Une personne a un statut et plusieurs personnes peuvent avoir le même statut.

Au niveau schéma, c'est sympa, mais au niveau conceptuel, ce l'est moins.

Si tu as trois type de personnes bien différentes (elle ne peuvent avoir qu'un type et ce type est définitivement défini à la création) il s'agit de trois objets indépendants, le seul point commun étant qu'il sont constitué de liste d'humains. Dans ce cas, est-ce une bonne idée de mélanger tout cela dans une même table ?

Si non, il y a la possibilité que d'autres type apparaissent et/ou qu'une personne change de type et/ou qu'une personne aie la nécessité d'avoir deux types, à terme... Et là aussi le schéma n'est pas bon.

Dans le premier cas, et pour simplifier la gestion des objets, un héritage concret permettait de résoudre la chose, dans le deuxième cas, c'est plutôt une question de réflexion sur le schéma qui devrait être entreprise.

Effectivement, j'ai une fois de plus réfléchit sur ce problème et j'en suis arrivé à la conclusion qu'effectivement, ces trois sous-classes étaient superflues.

J'ai donc supprimé ces trois classes. On retrouve le statut à la fois dans la personne et dans le lien qui relie la personne au contrat.

Ce statut sera sauvegardé au moment de la création du contrat et sera donc fixé à ce moment T mais pourra évoluer dans la personne.

(Au niveau conceptuel, je vois bien comment ça marche mais pour l'implémenter, je suis un peu dans le vague.)

L'idée étant de se souvenir du statut au moment où la personne conclue un accord ou un contrat et de savoir à tout moment quel est son statut actuel (qui peut -bien sûr- évoluer) donc le statut se retrouve en attribut porté par la relation entre la personne et l'accord. Ce qui, je pense, fera une table d'association.

Cette solution est-elle plus correct au niveau conceptuel ? :?

L'avantage de cette structure est qu'elle fait preuve d'une détermination.

Ensuite à voir s'il est nécessaire d'avoir une table d'association, cela dépend de ce que tu veux en faire. Si la donnée ne doit concerner que la création d'un contrat (une personne d'un certain type ne peut faire que les contrats du même type), il ne me semble pas nécessaire de stocker. Si non, il faut étudier pourquoi stocker. Stocker pour stocker peut ne pas présenter d'intérêt. voir compliquer inutilement le modèle et les traitements.

Citation:

---

L'avantage de cette structure est qu'elle fait preuve d'une détermination.

---

Je n'ai pas très bien compris cette phrase. :?

Le donnée "statut" concernera un contrat et une personne.

Elle sera utile à conserver pour pouvoir faire un tri des contrats en fonction du statut de la personne qui fait ce contrat.

La donnée "type de personne" sera conservée mais sous la forme d'un attribut dans le contrat qui nécessite X personne(s) d'un Type et X autre d'un autre par exemple. (Porteur associé / Partenaire associé)

Je veux dire que, par là, tu prends une décision sur l'implémentation, plutôt que d'essayer de tout faire sans rien décider. Et prendre une décision, c'est une bonne chose.

Ok, merci à toi.

Une dernière question : J'ai eu l'occasion de lire plusieurs de tes interventions et tu recommandes fortement de ne pas utiliser d'enum. C'est pour l'idée de base que j'avais eu en faisant mon analyse pour mes statuts.

Pourquoi es-tu si réticent vis-à-vis des enums ?

L'enum présentes de nombreux inconvéniants.

Les données (valeurs) sont stockées en dur dans la base de données, la moindre modification ou ajout d'une valeur implique la modification de la structure de la base de données.

De plus, si tu dois renseigner les valeurs dans la base, tu dois aussi les renseigner en local notamment pour créer une liste de sélection, et où la valider... Donc changer une valeur implique de modifier physiquement ta base ET de modifier ton code.

Une table de paramètres ou un tableau de paramètres retourné par le modèle permettent de facilement traiter la majorité des cas des enum.

D'accord, d'accord.

Merci à toi. :ccool:

Je pense que j'ai ce qu'il me faut pour continuer.