[Conception] Votre technique de conception de BDD en cas d'héritage

[Argorate]

Bonjour,

suite à une discutions avec Sephi sur le sujet, j'aimerais étendre les points de vues sur un plus grand nombre de personnes.

Lorsque vous avez un héritage, on prendra ici l'exemple de : bâtiment -> QG/Tourelle, comment stocker vous les informations en BDD?

Il existe trois méthodes:

-Décomposition ascendante :

Une seul table qui regroupe tous les type de bâtiment avec toutes les champs (dont certains non utilisé par certains type)

EXEMPLE:
BATIMENT(id_batiment, pv, radar_qg, puissance_tourelle)


-Décomposition descendante :

Une table par type avec uniquement les colonne qui leurs sont propres

EXEMPLE:
QG(id_qg, pv, radar_qg)
TOURELLE(id_tourelle, pv, puissance_tourelle)


-Décomposition par distinction :

Celle qui ressemble le plus à la programmation mais qui demande de jointer

EXEMPLE:
BATIMENT(id, pv)
QG(id_qg, radar_qg)
TOURELLE(id_tourelle, puissance_tourelle)

Donc quel méthode utilisez-vous généralement (bien que ça dépend des cas évidemment)? Pourquoi?

[Sephi-Chan]

J'utilise généralement la décomposition ascendante, plus souvent appelée STI pour Single Table Inheritance.
Elle a l'avantage d'être la plus simple et la plus performante. Je n'ai pas encore rencontré de défaut.

[Slavick]

Bonjour.

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.

Par contre, si je remarque qu'il n'y a que très peu d'informations complémentaires, comme dans ton exemple avec 1 champ spécifique. Je ferai la première décomposition (ascendante).

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à.

[Sephi-Chan]

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 ! ^^

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.

[Argorate]

Le problème de l'ascendante : où est la limite?

Parce que si on va par là, pourquoi ne pas étendre le truc aux autres tables comme la table joueur?

A la place on pourrait avoir une table MAP(qui contient tous les éléments de la map [joueurs, bâtiments, en passant par les véhicules...]) mais là on perd du sens a force...

[Sephi-Chan]

Et bien, la limite est celle de ton héritage côté langage.

class Building < ActiveRecord::Base

end



class QG < Building

end



class Tower < Building

end

[Hideaki]

Voici le bilan d'un article indiquant les avantages et inconvénient de chaque méthode, la technologie est jpa mais la réflexion reste la même.

Suivant le bilan de l'article et donc du cas d'utilisation j'opte pour l'une ou l'autre solution.
En général, je préfère éviter la première solution : Une table pour tout, exemple dans le cas d'ajout d'un ou plusieurs nouveaux bâtiments, la table va ... à contrario s'il y a que 2 objets proches avec uniquement une colonne et que l'on est certain que cela ne va pas changer pourquoi pas.

[Argorate]

Il n'y a aucune limite, si on met un champs type qui permet de switcher coté langage sur les bonnes classes...

EDIT : j'avais pas vu t'as rep Hideaki.

[Sephi-Chan]

Voici le bilan d'un article indiquant les avantages et inconvénient de chaque méthode, la technologie est jpa mais la réflexion reste la même.

Suivant le bilan de l'article et donc du cas d'utilisation j'opte pour l'une ou l'autre solution.
En général, je préfère éviter la première solution : Une table pour tout, exemple dans le cas d'ajout d'un ou plusieurs nouveaux bâtiments, la table va ... à contrario s'il y a que 2 objets proches avec uniquement une colonne et que l'on est certain que cela ne va pas changer pourquoi pas.

Ce tableau montre bien que la technique STI est la plus efficace. Ses défauts sont seulement d'avoir plein de colonnes NULL… Et alors ?
À côté de ça, les autres techniques ont des défauts majeurs concernant les performances. Pour quels bénéfices ? Eviter de stocker des valeurs NULL ?

Il n'y a aucune limite, si on met un champs type qui permet de switcher coté langage sur les bonne classe...

Tu as globalement une table par classe mère avec STI. Ensuite tu te sers de ta tête : tu te doutes bien qu'on ne va pas stocker les utilisateurs et les bâtiments dans une même table.

Ok, les joueurs et les bâtiments ont tous les 2 des coordonnées sur la map, mais c'est un rapprochement mineur : inutile de partager si peu de comportements similaires. C'est d'ailleurs là qu'un langage comme Ruby tire son épingle du jeu grâce aux modules : sans hériter, on peut quand même avec des comportements communs en incluant un module — appelons-le Mappable — qui contiendra le code commun).

[Hideaki]

@Sephi-chan : Cela dépend grandement du type de donnée que tu y stocks et de leur nombre et les requêtes à la main, comme les analyses sont tout de même plus chiante à faire.

Ok, les joueurs et les bâtiments ont tous les 2 des coordonnées sur la map, mais c'est un rapprochement mineur : inutile de partager si peu de comportements similaires. C'est d'ailleurs là qu'un langage comme Ruby tire son épingle du jeu grâce aux modules : sans hériter, on peut quand même avec des comportements communs en incluant un module — appelons-le Mappable — qui contiendra le code commun).

En php, il n'y a pas d'interface comme l'ensemble des langages objets ou d'annotation (sens java du terme) ?