Citation :Un système simple mais rigide
L'autre approche est de stocker dans chaque table une colonne pour chaque ressource et chaque usage. Si j'ajoute une ressource dans le jeu, c'est un peu chiant.
Ainsi, dans ma table beast_types (qui a plusieurs usages), j'aurais des colonnes consumption_resource_type_1_quantity, consumption_resource_type_2_quantity, harvesting_resource_type_1_quantity.
Sans vouloir m'avancer, il semble y avoir un problème d'abstraction ici.
Pourquoi ne pas considérer les ressources comme un type à part entière? (Et donc, pour parler au niveau BDD, comme une table)
Si tu crées chaque fois de nouveaux champs dans chaque entité qui requiert (= est lié) au concept de ressource, évidemment, c'est mauvais pour l'évolutivité et la maintenabilité.
Donc, pourquoi ne pas simplement extraire tes ressources dans une table dédiées? Et chaque entité qui aurait besoin de faire référence à ce concept de ressource serait lié (= foreign key) à une ligne dans cette table... Tout simplement.
Citation :usage : Par exemple, un type de bête a une consommation et une capacité de récolte.
Pour prendre un exemple plus concret, ton type "bête" aurait deux relations 1-1 vers la table "ressources". Ces deux relations seraient représentés par 2 foreign key.
la première: "consommation_ressource_id"
la deuxième: "capacite_recolte_id"
et il en va de même pour la notion de coût, de prime etc... Tout ce qui touche au ressource de près ou de loin devra être en lien avec cette table. De cette manière, si un jour tu veux ajouter un type de ressource, tu n'auras qu'à le faire dans la table "ressource".