Discussion :

[nso93]

Bonjour,

Je suis confronté à un problème de conception dans mon projet. J'aurai besoin d'avis sur la meilleure manière de modéliser certaines relations métiers dans mon projet.

Le projet porte sur une application de "social shopping".

Pour commencer je dispose d'entité métier :
USER (utilisateur)
BRAND (marque)
RETAILER (revendeurs)
PRODUCT (produit)
OFFER (offre commerciale)

Je souhaite implémenter différentes "actions" sociales du type:
VIEW (vue)
FOLLOW (suivre)
LIKE (aime)
SHARE (partage)

etc..

Ces actions sont réalisées par l'utilisateur et peut porter l'ensemble des entités citées.
Par exemple USER FOLLOW BRAND, USER LIKE PRODUCT, USER SHARE OFFER.

Mon problème est que justement une action peut pointer vers différents objets(tables) et je n'arrive pas à trouver la bonne solution.

J'ai penser à plusieurs solutions mais je ne suis pas convaincu par celles-çi :

1- L’HÉRITAGE:

Je pourrai créer un héritage sur mes entités,



Simple, mais je doute des performances.
Ces 5 entités sont les entité principales de l'application et Je me retrouverai à devoir requêter la table SOCIAL_ITEM sur toutes mes requêtes.
Cette table mélangera des objets métiers complétement différents et va vite obtenir une taille phénoménale.
Si j'ai 1000 marques et 100 000 produits par exemple je devrai parcourir à chaque fois 101000 enregistrements juste pour trouver mes 1000 marques..
Je me retrouverai avec un id commun pour ses objets différents (user 1, user 2, marque 3, produit 4... ) pas gênant en soi mais pas très élégant..


2- LA DELEGATION


AVEC UN OU EXCLUSIF SUR LES AGRÉGATIONS.

Un peu moins simple..
Problème : Partant des entités, je peut remonter vers SOCIAL_ITEM grace à l' ID_SOCIAL_ITEM présent dans chaque entité mais inversement je ne peut pas trouver l'entité correspondant au SOCIAL_ITEM.
Je pourrai ajouter dans SOCIAL_ITEM les champs ID et TYPE, pour gérer la relation inverse mais dans ce cas je ne pourrai pas placer de Clé étrangère sur cet ID et donc problème de performance à long terme.
Peut-être sinon mettre des champs ID_USER, ID_BRAND, ID_RETAILER, ... dans la table SOCIAL_ITEM et gérer le ou exclusif par trigger.. mais je ne pense pas que cela soit non plus une bonne pratique..
De plus cela commence à être compliqué si je souhaite récuperer seulement un type de SHARE.. par exemple récupérer seulement les produits partager par l'utilisateur.


3 -UNE SIMPLE ASSOCIATION


TOUJOURS AVEC LE OU EXCLUSIF A GERER

Encore complexe.. de nombreuses tables de jointures à mettre en place.. toujours la gestion du ou exclusif et de la relation inverse.



4 - ECLATER LE MODELE EN MULTIPLE TABLE



plus de ou exclusif, plus de problème d'inverse, simple à utiliser.

problème de nombreuses tables, devient vite exponentielle si je rajoute des actions et entités.
plus de gestion commune des partages. devoir travailler sur X table pour gérer une même action, dupliquer tout les champs de chaque action sur X tables (et donc d'objets)





CONCLUSION :

Je patauge...je ne sais pas si je me complique la vie pour rien ou si je suis totalement à coté de la plaque , je ne sais pas quel modèle est le plus propre et performant..
Je tourne en rond dans ma réflexion..


S'il vous plait aider moi si vous connaissez la solution de ce type de problème ou si vous avez des idées..
Merci d'avance et désolé pour le roman

[Richard_35]

Bonjour Nso93,

Sujet intéressant... et bravo pour sa présentation !

Personnellement, ma préférence penche pour l'héritage. En fait, l'héritage est détourné astucieusement de sa fonction initiale. En effet, il est utilisé comme "distributeur de clés primaires", mais pourquoi pas ?... ça pourra permettre, également, de regrouper des attributs communs. En plus, ce système est évolutif sans trop de casse : l'ajout d'une entité se fait facilement.

Ça donnerait ce MCD :



A noter :

• l'externalisation des actions ;
• 0,n au lieu de 1,n ;
• la contrainte XT.

Simple, mais je doute des performances.

==> les SGBD gèrent très bien les relations entre clés primaires.

Ces 5 entités sont les entité principales de l'application et Je me retrouverai à devoir requêter la table SOCIAL_ITEM sur toutes mes requêtes.

==> oui, mais pas gênant.

Cette table mélangera des objets métiers complétement différents et va vite obtenir une taille phénoménale.
Si j'ai 1000 marques et 100 000 produits par exemple je devrai parcourir à chaque fois 101000 enregistrements juste pour trouver mes 1000 marques..

==> il s'agit, là, de quantifier la volumétrie pour choisir le bon SGBD. Ensuite, celui-ci gérera très bien les relations entre entité. Mais, c'est vrai, il ne faudra pas se trouver en dépassement de capacité...

Je me retrouverai avec un id commun pour ses objets différents (user 1, user 2, marque 3, produit 4... ) pas gênant en soi mais pas très élégant..

==> effectivement, ce n'est pas gênant. Il s'agit d'un identifiant unique sans signification, donc le non respect de la séquentialité ne pose pas de problème.

[Richard_35]

... en incluant les users entre eux :

[Luckyluke34]

Bonjour,

Je pense qu'une étude approfondie du domaine (si possible avec un expert du secteur s'il y en a un) permet de modéliser au plus près des besoins.

Par exemple : est-ce que le verbe très générique SHARE convient vraiment à tous les types d'entités ? On pourrait PROMOTE une BRAND, RECOMMEND un PRODUCT ou bien SPREAD une OFFER... Pareil avec FOLLOW. Le terme le plus spécifique pour un Produit pourrait être TRACK, pour un RETAILER, SUBSCRIBE, pour une offre, ALERT, etc.

Si ça s'avère être le cas, ces associations ont tout lieu de devenir un jour porteuses de leurs propres données spécifiques. On modélisera alors plutôt avec la solution 4. tables multiples pour être précis dans notre représentation des données. Rien ne sert de regrouper des notions qui, au final, ne sont pas si similaires que ça.

D'un autre côté, si on veut être full dynamique/générique, qu'on prévoit d'ajouter des types d'actions et d'entités très régulièrement ou de les rendre paramétrables comme dans un progiciel, de sortir des données consolidées sur toutes les types d'objets possibles d'une action, une des trois premières modélisations sera plus adaptée.

Dans tous les cas, il faut se poser la question des objectifs et surtout se demander comment va évoluer le système sur la durée, à la fois en volume et en structure.