conception de la BDD : jeu avec map

[Argorate]

Bonjour,

Voilà, j'ai envi d'avoir d'autre avis sur la question suivante:

Selon vous, si votre jeu comporte un plateau/map, ainsi que des personnage, objet, véhicule, bâtiment, pnj...

Faut t-il créer une seul table "carte" avec l'id et un "type" qui permet d'identifier s'il s'agit d'un perso, objet, véhicule...
EX: carte(id_element, type, ...)

OU alors

On crée une table par type (on supprime donc le champs du même nom)?
EX: carte_perso, carte_objet, carte_batiment...

OU autre solution?

La solution 1 ne rend elle pas les requêtes beaucoup plus longue s'il y a beaucoup d'élément dans la table (sur la map)?

Voila, merci de me dire ce que vous en pensez.

[NicoMSEvent]

tout dépend de ce que tu peux afficher sur une case.
Un seul élément? (soit batiment, soit vehicule, soit perso?)
Une combinaison de plusieurs éléments? (un véhicule + 2 perso?)

Dans le premier cas, tu peux avoir une case avec ces données : X,Y,type_élément,id_élement
Dans le deuxieme cas, une table pour l'ensemble des cases :X,Y + une table pour les objets : id_case(ou X,Y si la table des cases n'a pas d'identifiant), type_element,id_élément
, ce qui te permettrait d'avoir plusieurs objects par case.

le "cout" d'une requete est fortement lié a la structure de tes tables (index) et la manière dont tu as écrit ta requete. J'ai une requete écrite d'une certaine manière me mettait 30 sec, et écrite d'une autre manière me prend actuellement 0,2sec

Donc, teste un peu toutes les solutions, c'est comme ça que tu apprendra le mieux

Si tu as un exemple concret, je peux t'aider a l'optimiser

[Argorate]

Personnellement je suis dans le second cas.

Je ne pense pas que tester toutes les solutions soit très intelligent, il faut réfléchir a la meilleur solution avant de l'implémenter, sinon le temps de tout tester est vraiment trop long.

Pour ce qui est des requêtes, je prend comme pré-requis qu'elles sont bien écrite (oui mes requêtes sont géniales :p)
Donc je parle uniquement du fait que si on a (chiffre au pif) 50 000 objets, 5 000 perso, 20 000 bâtiments, 10 000 véhicules, si tous ces éléments sont séparer dans des tables qui leurs sont propres c'est différents de si on les regroupes toute en une même tables. Alors oui bien entendu les index ça aide (en général) a accélérer, mais la question était justement plus implicite: es-ce qu'on y gagne malgré tout a tout mettre en une table lorsqu'on a beaucoup d'entrer?

[NicoMSEvent]

le fait de tester toutes les solutions est didactique, ça permet de voir que parfois des solutions assez "folles" fonctionnent mieux que d'autres (parfois faire des jointures ou mettre des conditions "inverses" donnent de meilleurs résultats que l'ordre logique et naturel :p )

par exemple (je donne les chiffres de mon projet), j'ai une map de 1.000.000 de cases, j'affiche des personnages (pj,pnj,monstres,boss) venant de 4 tables différentes, avec comme équipement des armes et des armures (2 tables différentes), j'ai assez bien de croisements dans mes jointures, et changeant juste l'ordre des jointures (genre a.date_start>=sysdate AND a.date_end<=sysdate à la place a sysdate BETWEEN a.date_start AND a.date_end), j'ai déjà une belle différence en temps d'exécution avec MySQL 5.1

tout mettre dans une table, y a du pour et du contre. ça dépends si tu as 10 tables avec 5 lignes dans chacune ou une table avec 5^10 lignes... je préfère la premiere solution avec de bonnes jointures

[QuentinC]

Je pense que tu devrais tout mettre dans une table unique
id, position x, position y, type, +données supplémentaires

si le champ type est de type enum et que dans cette enum tu mets des noms de classe, tu pourras facilement faire du polymorphisme. Ca t'autorise à récupérer tout ce qui se trouve sur une case en une seule requête simpple plutôt que des jointures ou des unions. Je vois bien un truc de ce genre :

Code :

create table Map (
id int unsigned auto_increment,
x int, y int,
type enum('Perso', 'Batiment', 'Objet', 'PNJ'),
# ...
primary key(id));

Code :

function getAllObjectsIn ($x, $y) {
global $db;
$re = $db->query(sprintf('select * from Map where x=%d and y=%d', $x, $y));
$tab = array();
while (($l = $re->fetch(PDO::FETCH_ASSOC)) {
$className = $l['type'];
$object = new $className($tab);
$tab[] = $object;
}
return $tab;
}

Je me demande même si on ne peut pas encore faire plus simple avec PDO. Il faudrait fouiller la doc, je ne sais pas si il n'existerait pas un PDO::FETCH_CLASS polymorphique.

[Argorate]

NicoMSEvent : j'ai plutot beaucoup de ligne dans mes tables, c'est pour ça que je suis pas sur du bien fondé de séparer et de "perdre du temps" en jointant.
Ce post visé justement des personnes ayant ce cas dans leur jeu, pour savoir quel methode ils ont adopté et pourquoi.

Donc par exemple, toi tu as séparer tout en plusieurs tables d'aprés ce que tu as écrit. Tu ne penses pas qu'il y aurais un gain si tu n'avais pas de jointure et juste une condition WHERE sur le "type" de l'élément sur la map?

QuentinC : je préfére ne pas parler du traitement de données qui se fait deriere. Donc toi tu n'en ferais qu'une au niveau des tables? Comme quoi on a deux points de vu différent, mais ça reste difficile de dire la meillieur des deux.

Pour l'instant coder comme c'est dans mon jeu, j'ai plusieurs tables, et j'ai vraiment pas envis de passer a une seule pour me rendre compte ensuite que j'y perd en fin de compte...

[Allwise]

Y a ce débat récent qui peut t'aider :
http://www.jeuweb.org/board/denormaliser...-6045.html

[NicoMSEvent]

j'utilise plusieurs table, pour éviter la redondance, une classe qui se spécialise
(ex: objets
-> armures
-> armes
-> divers )
me donne une table générique, et trois tables de spécialisation (histoire de ne pas avoir trois tables avec un champ nom, description, propriétaire, ...)

Je ne dis pas que j'ai la meilleure des solution, juste que ça me convient pour les problèmes que j'ai rencontré

[niahoo]

Hello,

perso ma table carte ne contient que des objets géo (type de sol, rivieres, etc..)
et ensuite ma carte personnages à un champ x et un champ Y, ma table des bâtiments aussi etc..

[Argorate]

niahoo: c'est comme ça aussi pour moi.
Je pense pas que ce soit si mauvais, donc je pense rester comme ça

Allwise : moi en l'occurence c'est plutot du 0..1 -> *
Chaque élément n'est pas forcé d'etre sur la carte, et la carte peut avoir plus d'un élément, mais j'ai un vague souvenir de la converse^^