Chacun peut avoir des conclusions différentes. Voici celles de l'auteur du TP.

La stratégie 1 ("une table par hiérarchie") pose moins de problèmes que les 2 autres stratégies. Elle est plus simple à mettre en oeuvre. Cependant, si les articles ont des propriétés trop différentes, on a alors de nombreuses colonnes null dans la base.

La stratégie 2 ("une table par classe concrète") qui semble la plus naturelle (chaque classe concrète, Stylo, Ramette, Lot, correspond à une table), est en fait celle qui pose le plus de problème dès que l'application comporte des associations ou des requêtes polymorphes.

La stratégie 3 ("une table par classe") est la plus souple mais elle peut occasionner des performances mauvaises à cause des nombreuses jointures qu'elle nécessite.

Une solution mixte serait par exemple d'avoir une table pour tous les articles "unitaires" et une table pour les lots qui sont bien différents. Mais elle comportera souvent les mêmes problèmes que la stratégie 2.

Pour la suite des TPs, on choisira la stratégie 1 qui est d'ailleurs la solution la plus fréquemment adoptée par les développeurs. On verra aussi qu'elle est facile à mettre en oeuvre avec des outils de mapping comme Hibernate ou JPA.

Remarque qui n'a rien à voir avec le mapping objet-relationnel sur le modèle objet donné au début de ce TP : dans une application réelle, avec des milliers d'articles de types différents, il est vraisemblable que tous les articles seraient réunis dans une seule table et les propriétés particulières de chaque article seraient conservées sous une forme non structurée dans une ou plusieurs colonnes (les mêmes pour tous les types d'article). Dans cet exercice, on a associé une table à chaque type d'article pour montrer, avec peu de lignes de code et un énoncé simple à comprendre, les problèmes qui peuvent se poser pour effectuer le mapping relationnel-objet.