[BDD] Une ou deux tables de "même forme"

[Ter Rowan]

Coucou, j'ai une petite quesiton de modélisation:

j'ai deux notions proches mais pas équivalentes dans le traitement et je souhaitais savoir ce que vous en pensiez :

notion1 : "carte"

table :
id / id lieu père / x / y / z / classe / type

id : définit et représente une case de la carte

id lieu père : id d'une "région" (somme de cases, pas de règle mathématiques pour définir une frontière, la région est l'ensemble des cases dont l'id lieu père est l'id de la région)

x : position horizontale, absolue, sur la carte
y : position verticale, absolue, sur la carte
z : altitude max du sol (exemple mer = 0, mont blanc 4800 et des brouettes, prairie chez moi 130, prairie chez argorate 300, etc...)

classe : l'id qui me permettra lors du chargement de générer la classe (ex 1=>plaine, 2=>forêt, etc...)

type : une information compémentaire pour le constructeur de la classe
(grosso modo : $case = new $classe($type))

la carte ne bouge pas, les terraformations(changement de classe et de type) seront très rares. Toute autre donnée concernant la carte sera dans une table relation de type n,n (donc pas dans cette table)

notion2 : "lieu"

j'appelle lieu tout ce qui est "spécifique" (exemple la maison de machin, ou une pièce de la maison, ou un "bosquet notable" ou un village...etc)

table de type :
id / id lieu père / x / y / z / classe / type

id : définit et représente le lieu

id lieu père : où est situé le lieu ? donc cet id peut être l'id d'un autre lieu (l'id du village pour une maison, l'id d'une maison pour une pièce, etc...)
mais aussi l'id d'une case de la carte (la notion 1, exemple le village est sur la plaine truc muche, la grotte notable est sur le mont blanc....)

x : position horizontale, relative, basé sur le lieu père (pour permettre un affichage du détail du père
y : position verticale, relative, basé sur le lieu père (pour permettre un affichage du détail du père
z : altitude / étage

classe : l'id qui me permettra lors du chargement de générer la classe (ex 1=>village, 2=>maison, etc...)

type : une information compémentaire pour le constructeur de la classe
(grosso modo : $case = new $classe($type))

Exemple :
"maison" id = 30; id pere = 28 (l'id du village de rowan), x= 1 (à gauche de l'écran), y=1 (en haut de l'écran), z=0 (ben oui la maison est au sol...)
"la pièce principale de la maison" id = 31; id pere = 30, x = 1, y =1, z = 0 (rez de chaussé)
"la cave" id = 32; id pere = 30; x =1; y=1; z=-1 (sous sol)

les lieux varient bcp plus souvent (on peut construire une maison, rajouter une piece, brûler un village, etc...). Et je ne sais pas si d'autres infos seront utiles.

DU COUP.... une ou deux tables ?

une table :
+ même structure donc même code,
+ id commun entre les deux notions facilitant la relation "père fils" (id père)

deux tables :
+ permet de faire du transactionnel sur les lieux et pas sur la carte (mais est ce vraiment utile pour ce besoin de faire du transactionnel, pas sûr)
+ évolution plus facile (quoique, je pourrais créer une table "détail" pour les lieux spécifiquement par exemple)

alors avant de me lancer dedans, qu'en pensez vous ?

[Shudrum]

J'avais déjà penché sur un problème similaire, mais j'ai fini par faire deux tables.

La raison était la suivante :
_ La carte ne bouge pas.
_ Les bâtiments eux, se construisent / détruisent.

De plus, j'avais un autre fait :
_ La carte est lourde, chaque case est forcement présente
_ Les bâtiments eux, sont moins nombreux.

En liant ces deux faits, j'ai fini par trancher suite à une légère optimisation côté Sql : le choix du moteur de chaque table : la carte étant donc lecture seule, le moteur MyIsam était le plus indiqué. Les bâtiments, eux, étant fréquemment modifiés, j'ai penché pour le moteur InnoDb. (Je ne dis pas que c'est le top, mais vu mes connaissances, c'était le mieux).

Finalement ca a très bien marché, et en voyant ce choix avec du recul, ca m'a ouvert les portes a beaucoup plus de modifications / ajout au gameplay (que je n'ai jamais fait au final ^^)

En espérant t'avoir été utile, et ne pas être parti à l'ouest

[Ter Rowan]

merci pour ta réponse

mais, si je le fais en deux tables... comment gérer la relation père fils de lieu qui peut être un lieu ou une case de la carte ?

rajouter une colonne source ?

[Sephi-Chan]

Tu fais du polymorphisme avec 2 colonnes : location_type et location_id.


Sephi-Chan

[keke]

Hum...

Sur ta table 1, tu as un id_lieu_pere qui représente une région ... c'est bien ça ?

Sur ta table 2, tu as un id_lieu_pere qui représente le lieu où se trouve ton lieu.

J'avoue que, sans connaitre ton jeu, j'ai l'impression que tu mélange 2 notions.
J'aurais eu tendance à décomposer mes tables autrement ... ce qui va peut-être permettre d'ouvrir un sujet de discussion.

Tu as des lieux :
table_lieu : id_lieu, nom du lieu, classe, type, id_position
Tu as des cases qui peuvent être sur une carte générale, ou le détail d'une ville :
table_case : id_lieu, x, y, z, type_case id_region
et des régions :
table_region : id_region, nom_region, pluviométrie_region, temperature_region
Pour passer d'un lieu à un autre, on peut utiliser des portails :
table_portail : id_portail, description, id_position_entrée, id_position_sortie
qui font référence à des positions sur les cartes :
table_position : id_position, id_lieu, x, y, z

Hum ... à la question

DU COUP.... une ou deux tables ?

j'aurais tendance à dire ... pourquoi pas 5 tables ? (ou plus ^^)

Kéké
PS : en tous les cas, si ton choix est entre 1 et 2 ... je préfère 2 ^^.

[Ter Rowan]

Hum...

J'avoue que, sans connaitre ton jeu, j'ai l'impression que tu mélange 2 notions.

oui, je mélange deux notions, mais volontairement et non je n'ai pas les notions que tu interprêtes (enfin ce que je comprends de ton interprétation ^^)


j'appelle case de la carte le "plateau de jeu" standard, imaginons la carte ign à une échelle définie qui ne bougera pas, découpée en case de x km.

j'appelle "lieu" des "éléments" qu'on trouvera en direct sur une case de la carte, soit à l'intérieur d'un autre "lieu" (le concept de pièces dans une maison)

la question ne porte pas sur le modèle complet mais bien sur la gestion du lien père fils

car oui il y aura d'autres tables mais entre une question à 5 ou 6 tables et une question à 1 ou 2 tables j'ai préféré centrer à ma problématique de lien père-fils.

après les notions que tu proposes peuvent être intéressantes ou pas, selon le jeu imaginé mais elles risquent plus de dériver sur des notions de GP que sur des notions de développement, j'ai donc souhaité éviter ces débats (mais c'est vrai que l'on pourrait imaginer un sujet "comment gérer l'espace")

mais pour info :
oui région = autre table avec notion de météo
non portail = pas de portail, c'est pas mon jeu, tu veux te déplacer, tu marches (ou autres)


en tout cas merci pour vos participations, il faut que je creuse un peu mais je vais probablement finir sur deux tables