Discussion :

[UchiwaItachi]

Bonjour,

J'aimerai avoir votre avis sur le choix de modélisation d'une base de donnée.

Je travaille en ce moment sur un site de vente en ligne. Le site permet l'achat de 4 type de produits.

Parmi ces 4 types de produits, 2 sont en format numérique, c'est à dire téléchargeable en ligne, et les 2 autres sont de types physiques (avec une gestion de stock).

Environnement technique:

• Java/JEE
• JPA / Hibernate
• Spring

1 ère solution:

Modéliser les 4 types de produits par 3 tables : Product <-> ProductAttribute <-> ProductAttributeValue

Une liaison de la table Product avec une table TypeProduct permettra de distinguer le type de produit

Cette modélisation permet d'englober énormément de caractéristiques pour les produits.

1. Les produits ne sont pas simplistes au point d'être représenté par un ensemble de caractéristiques et de valeurs de caractéristiques
2. La récupération des éléments via JPA peut être complexe

2 ème solution:

Modéliser les 4 types de produits dans des tables séparés et les faire hériter par une table Product.

• La relation d'héritage n'est pas naturelle avec les SGBD, on mettra en place des foreign keys pour assurer les relations d'héritages.
• JPA 2 permet de modéliser l'héritage avec une notion de discriminateur, lie une table parent à des tables filles par une colonne discriminateur
• Simplification du schéma : Les tables qui vont permettre l'achat du produit par un client vont référencer une seule table Product via une table de jointure
• Simplification du schéma : Les tables qui vont permettre la gestion des stock vont référencer une seule table Product via une table de jointure

3 ème solution:

Modéliser les 4 type de produits dans des tables séparés, sans héritage avec une table commune Product.

• Pas de notion d'héritage au niveau du SGBD.
• Multiplication des tables : Les tables qui vont permettre l'achat du produit par un client vont référencer directement les tables concernés en passant par 4 tables de jointures.
• Multiplication des tables : Les tables qui vont permettre la gestion des stock vont référencer directement les tables concernés en passant par 4 tables de jointures.

Pouvez-vous me donner vos avis et vos conseils ?

Merci par avance

[SQLpro]

Déjà si vous voulez des performances, passez vous de cette merde d'hibernate. Ou alors n'envisagez surtout pas trop de client ni de produit et surtout le trafic le plus faible possible sur votre site.
A titre d'info, jetez un coup d’œil sur ces métriques : http://ormeter.net/
Notamment performance scorecard...
Vous y verrez que faire un UPDATE avec Hibernate est 24 fois plus lent qu'en natif.
Bref, il vous faudra prendre 24 fois plus de CPU, RAM, disque... Pour compenser cette merde d'Hibernate !

Ensuite la modélisation est une logique et pas un choix ! Votre raisonnement est idiot. Si vous faite de la abse de données relationnelle il faut modéliser au niveau conceptuel et non pas au niveau "table". Modéliser au niveau table conduit systématiquement à des aberrations du modèle et donc des perf lamentable en sus de ne pas permettre à la base de rester intègre...
Votre première solution c'est un pur style NoSQL, donc au revoir les SGBDR et surtout pas de transaction... Bref, pour un site de vente c'est une vaste connerie !
La 3e solution introduit du NULL et une base non intègre, c'est donc aussi anti relationnel.

Modéliser un héritage se gère parfaitement bien et les notations de MCD le permette depuis belle lurette (Merise, ER, Barker... UML). Il faudra juste compléter l'IR avec des déclencheurs pour gérer l'exclusion mutuelle. Certains outils de modélisation comme Power AMC écrivent automatiquement les déclencheurs au moment du passage du MCD au MPD.

A +