Structures des tables "Joueur" et "Objet"

[Colmea]

Bonjour à tous.

J'aimerais avoir votre avis sur plusieurs point quant à l'organisation de mes tables.

Premier problème:
En fait, il y aura plusieurs sortes d'objets: des armes et armures, et des objets.
Ma question est la suivante:
- Une table pour tous les objets + relation avec une autre table "objet_catégorie" pour définir si c'est un objet ou une arme
OU
-Une table "objet" et une table "arme_armure" ?

Ca parait anodin comme réflexion, mais j'aimerais au maximum éviter d'avoir des surprises du type "joueur3 porte une potion+10PDV et en même temps éviter au maximum d'avoir 10 000 tables pour chaque type d'objets.

Deuxième problème:
Les différents membres des villages pourront développer une série de bâtiments (qui risquent de s'ajouter au fur et à mesure des MàJ).
Comment organiser ces différents bâtiments dans ma table:
-Un champ pour chaque bâtiment dans la table "village" ?
-Une table "bâtiments" en relation avec la table village ?


Voilà, merci d'avance pour vos avis

[christouphe]

Pour ta table objet / catégorie, j'ai séparé les 2

Ensuite, une table batiments, une table village, une table batiment_village(id_bat,id_village)

[Colmea]

Merci pour la réponse rapide
Je comptais faire ça aussi.

En ce qui concerne les infos statiques de chaque bâtiments (description, images, ...), dans un fichier ?

[Sephi-Chan]

Pour le première problème, je te suggère d'utiliser 2 tables : items et equipments.
Pour le second, il faut effectivement créer une relation many-to-many grace à une table de jointure.

Pour le stockage des informations du bâtiment, je te conseille d'utiliser une table comme building_types qui contient tous les bâtiments disponibles dans ton jeu. Avec des colonnes pour tous les attributs utilisées par les bâtiments (ces colonnes seront laissées à NULL si le bâtiment n'utilise pas telle ou telle information).


Sephi-Chan

[Colmea]

Ok merci.
Mais est-ce qu'une "triple" relation "bâtiment_type <-> bâtiment_village <-> village <-> membre" (avec 4 tables donc) est envisageable ?
Ca ne va pas être trop lourd ?

NB: Relation entre membre et village car chaque village peut accueillir plusieurs membres (onetomany)

[Sephi-Chan]

En fait un bâtiment ne peut être que sur un village à la fois, non ?

Tu aurais donc plutôt un modèle à 4 tables comme ceci :

building_types : aucune clé étrangère.
buildings : building_type_id et village_id (et éventuellement player_id, si on dénormalise)
villages : player_id
players : aucune clé étrangère

Et non, ce n'est pas lourd. ^^


Sephi-Chan

[Colmea]

Non en fait le village peut avoir plusieurs membres.
Donc ma clé étrangère est dans ma table membre ($village_id)

Ma table village n'a pas de clé étrangère pour l'instant.

Mais ok, si c'est pas lourd, j'adopte

[Sephi-Chan]

Ok.

Mais du coup j'ai bon pour les bâtiments ?
Normalement, tu auras vite beaucoup plus de tables (et donc d'associations).


Sephi-Chan

[Colmea]

Oui je pense que c'est bon.

Merci à vous

[Colmea]

Seulement dans le cas des bâtiments; Sachant que les membres du village pourront les faire monter de niveaux, et que le coût des bâtiments évoluera en fonction. Je vais devoir recréer une table "cout_batiment_par_niveau" ?

Et si mes coûts sont différents en fonction de chaque bâtiment :heuuu:
Dur dur à gérer tout ça non ?

Edit: Un explode sur le champ cout_batiment qui reprend le cout par niveau, séparé par des # (genre "100#230#335#...") ?