05-10-2011, 04:13 PM
(Modification du message : 05-10-2011, 04:17 PM par Sephi-Chan.)
(05-10-2011, 04:06 PM)Hideaki a écrit : 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 ?
(05-10-2011, 04:07 PM)Argorate a écrit : 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).