Discussion :

[105rn2]

Bonsoir à tous,
Je me permets de solliciter un conseil de « conception »
Je suppose que le sujet a déjà été traité, mais je n’ai pas trouvé, et m’en excuse par avance (de même que pour les inexactitudes de vocabulaire)
Je voudrais créer un lien entre plusieurs entités de même "nature" (occurrences d’une même class) i

Exemple :
L’entité A est en relation avec l’entité B car ayant la même couleur
L’entité A est en relation avec l’entité C car ayant le même format
L’entité C est en relation avec l’entité F car ayant le même sujet
…

Quand j’affiche le détail de l’entité F, je voudrais pouvoir également afficher qu’elle est en relation avec les entités A, B et C

J’envisage 2 approches

1) Une relation manyTo many avec attribut : Entité1 - Entité2 – Objet de la relation
o A-B-Couleur
o A-C-format
o C-F-sujet
Mais j’ai un peu peur de ne pas savoir retrouver facilement A et B depuis F (recherche sans fin si non limitée à un niveau de profondeur)

2) Une relation « multi-entité » de taille prédéfinie avec une entité de référence
• Entité1-Entité2- Objet de la relation2- Entité3- Objet de la relation3
Exemple : A-B-couleur-C-format-F-sujet
Mais je ne vois pas trop comment définir ça dans Doctrine

J’espère avoir été clair, sinon n’hésitez pas ..
Par avance, merci de vos conseils sur la direction à prendre
Bertrand

[Tsilefy]

Tu peux créer une entité qui s'auto-référence: http://doctrine-orm.readthedocs.org/...lf-referencing

Mais ton explication n'est pas claire. Peux-tu parler nous expliquer ton domaine? Dis-nous ce qu'est ton entité: un produit? Une équipe? une image?

Je ne comprends pas non plus coment F peut avoir une relation avec A, B et c dans ton exemple? Est-ce que F est lié à B parce que F est lié à C, qui est lié à A, qui est lié à B?

[105rn2]

Bonsoir Tsilefy,
Merci pour la réponse, je vais creuser le self-referencing
F est en effet en relation avec B, car en relation avec C qui est en relation avec A

Pour être plus clair, prenons une collection de timbres
je voudrais lister les "faux-amis" et variantes d'un timbre pour attirer l'attention sur le fait qu'il y a risque d'erreur
le timbre A ressemble au timbre B mais n'a pas la même couleur
le timbre A a été également imprimé dans un autre format, et il porte alors la référence B
le timbre F est en réalité une variété du timbre C (gravure différente)
le timbre G est de même couleur que le timbre A, mais avec une autre faciale
..
le pb est qu'à la saisie de G, on sait que G est une variante de A, mais plus forcément qu'on a déjà saisi que A ressemble à B
et si G est lié à A qui est lié à B, alors G est lié à B

On doit pouvoir faire une analogie avec d'autres domaines : j'affiche telle pièce auto, mais pensez à regarder ses variantes, copies ..

je ne sais pas si je suis plus clair
merci encore
Bertrand

[gototog]

Ce qui est clair c'est que ca n'a rien a voir avec symfony2. Je dis ca pour toi, les personnes sur le forum symfony2 ont peut être moins de compétences que celles trainant sur le forum de conception

Pour moi si ton problème est une simple fonctionnalité annexe, je solverai plus ca par un algorithme de recherche que par une modélisation particulière de tes classes métier.

Si parcontre le coeur de ton site c'est de faire ce genre de traitement, alors je partirai sur de la modelisation NoSQL en graphe, comme Neo4J

[Tsilefy]

Est-ce que tes "variantes" peuvent être assimilées à une taxonomie? (catégorie, classe, type) ou est-ce qu'elles sont aléatoires et peuvent connecter arbitrairement deux objets?

Est-ce qu'un objet peut appartenir à 2 variantes? ex: B est comme A mais a une couleur différente et a une valeur faciale différente?

Est-ce que tes relations peuvent être envisagées comme une liste chaînée? Ce qui fait qu'à partir du moment où on a accès à un élément, on peut remonter les autres éléments de la liste.

Il est également possible que tu as un problème de conception et qu'il y a un moyen plus simple de structurer tes classes, et c'est pour ça que je t'ai demandé d'expliquer ton domaine plus précisément. Si tu pars sur une mauvaise conception, aucune solution ne te sauvera.

[105rn2]

Bonsoir et merci pour vos réponses,

Le lien avec symfony (mais qui ne le rend pas spécifique avec Symfony) est que je veux/dois utiliser Doctrine
Cette fonction est vraiment marginale (heureusement) de l'appli

D'après ce que j'ai compris de la taxonomie, les relations entre les entités sont aléatoires
Dans la pratique, A est une variante de B pour une seule et unique raison (couleur OU faciale)
Liste chainée ? dans le sens de l'exemple donné oui, A peut-être lié à B, lui même à C, c'est pourquoi j'envisageais 2 approches :
- une "verticale", relation entre 2 entités : self-referencing avec un attribut en plus (descriptif de la variante : couleur,..)
- une "horizontale" relation entre x entités sous forme de fil ou de chaine

C'est justement pour ne pas me tromper de conception que je demande conseil, et vous remercie de vous y pencher

Je ne sais pas si j'ai réussi à expliquer clairement mon besoin, mais on pourrait aussi rapprocher cela comme un fil aléatoire (sans relation naturelle comme du même auteur, du même sujet,..) entre différents articles d'un blog, sauf qu'il y aurait un attribut supplémentaire expliquant le pourquoi du lien .
Ou sur un site de e.commerce ou des variantes de produits sont proposées (quoique que je ne sais pas comment sont conçues ces listes de produits équivalents/recommandés)

merci encore
Bertrand

[Tsilefy]

Dans le cas des variantes des produits, tu peux avoir plusieurs façons d'organiser les données. Par exemple,
- Tu as un produit principal, et tu crées séparément les options, puis tu les ajoutes ensuite au produit (one to many, ou many to many si tu veux que les options puissent être utilisées par différents produits).

Concrètement: tu as une table "option" avec les champs "name" et "value". Ex: name = color; value = "red". Tu fais ensuite la relation many to many entre le produit et cette table (par les champs product_id et option_id)

Ça te permet d'avoir la liste de tous les produits qui ont une couleur rouge, par exemple. Tu peux même combiner les critères: "tous les produits qui sont rouges ou marrons et qui sont en plastique". Ou bien, à partir d'un produit donné, "afficher tous les produits qui ont les mêmes options que ce produit".

Si tu connais les critères avant de lancer ta requête (tous les produits qui sont rouges ou marrons et qui sont en plastique), c'est facile avec MySQL.

Si tu bases tes critères sur les valeurs issues de ta requête (tous les produits qui ont les mêmes options que ce produit), et que tu t'arrêtes à cette étape, ça ira encore.

Mais si tu bases tes critères sur les valeurs issues de ta requête (tous les produits qui ont les mêmes options que ce produit), et que tu refais la même requête sur toutes les valeurs que tu as trouvé, le temps de traitement va être long, et va être de plus en plus long au fur et à mesure de l'ajour de nouveaux produits.

La solution est peut-être un schéma EAV (ce que fait Magento), mais c'est un schema difficile à maintenir et de toutes façons pas compatible avec Doctrine.

Ou alors il faut complètement dénormaliser et passer à un NoSQL comme suggesté par gotogog

[105rn2]

Bonsoir,
Merci de vos explications et de votre patience,
J'ai ré-étudié quelques exemples concrets, et j'en arrive à la conclusion que si je me fixe une entité de "référence", et que les "variantes" se référent toutes à celle-ci, alors une requête pour trouver celle de référence, puis une pour trouver ses variantes devrait suffire
Je pense donc que cela devrait aller comme cela !
je passe donc cette discussion à "résolu" et vous remercie encore de vos conseils !
Bertrand