05-10-2011, 12:26 PM
(05-10-2011, 12:16 PM)Slavick a écrit : J'ai rarement eu l'occasion de faire de l'héritage, mais si je devais en faire, j'utiliserai la dernière décomposition (par distinction). Car chaque bâtiment a ses propres caractéristiques.
Avec les autres modèles aussi, chaque bâtiment a ses propres caractéristiques. C'est juste que ce n'est pas exclusif.
Autre avantage de la première solution : on peut avoir des types composés sans rien changer (un bâtiment qui est à la fois un Radar et un QG). Mais après c'est le modèle Objet qui devient plus difficile à suivre ! ^^
(05-10-2011, 12:16 PM)Slavick a écrit : Sinon une idée, mais je ne sais pas si cela serait efficace. Il serait possible de faire une seule table pour tous les bâtiments, mais avec un champ type (QG ou Tourelle) et un champ supplémentaire générique qui contiendrait le(s) champ(s) spécifique(s) en JSON par exemple.
Exemple :
BATIMENT(id,pv,type,extra)
Un QG : 1, 100, 1, "{radar_qg:4}"
Une tourelle : 2, 50, 2, "{puissance:200,portee:4}"
Il est évident que maintenant, faire une requête sélective sur les caractéristiques spécifiques d'un bâtiment ne serait pas efficace du tout ; il faudra donc utiliser une autre décomposition. Mais si ces caractéristiques ne servent pas de critère de sélection et qu'elles ne sont que très rarement modifiées, je pense que j'utiliserai une décomposition comme celle-là.
Je ne vois pas trop l'intérêt. Ou alors on pourrait adopter cet usage dans moult autre cas : mettre dans ce hash sérialisé tous les attributs qu'on n'utilise pas dans les clauses de la requêtes.