[revevolutionair] [orga DEV] BDD, surtout pour Mik

["Dominique Dehareng" <webmaster@xxxxxxxxxxxxxxxxxxxx>]

Bonsoir la tribu,

Ce mail concerne la BDD, et ce que je propose pour certaines tables. Bon c'est assez long comme mail, désolée. Sam, il y a quelques questions aussi pour toi.
Dans la mesure du possible, j'ai essayé de mettre des noms anglais.

J'ai cru comprendre que Symfony travaillait beaucoup sur base des id. Est-ce que je me trompe?
Si non, je proposerais alors qu'on mette des id en clé primaire autoincrémentale dans toutes les tables (id: primary key, autoincrement). Cela pose-t-il un problème?

Voilà quelques tables, qui ressemblent d'ailleurs très fort à ce qu'elles sont déjà dans l'actuelle BDD.

Avatar
------
id
avatar_name
avatar_age
avatar_race
account_id
avatar_world
politic_regime
player_filiation_type
player_filiation_hypot
player_filiation_cert
level_aggressivity
level_fraud
level_commerce
level_efficiency
last_connexion
avatar_life    ?? question: faut-il vraiment cette caractéristique puisque l'avatar est un D'jun, donc un esprit, en principe immortel??

les champs obligatoires (non nuls) sont avatar_name, avatar_race, avatar_age, account_id (clé étrangère), les autres peuvent être nuls
==============================================================================

Town
----
id
name        
WorldSlotId       (entier     doit être défini par choix sur la carte au moment de créer la ville)
size (calculée sur base des coord et du slot correspondant) entier  (une fois que la case d'établissement de la ville est choisie, sa taille et toutes les autres caractéristiques sont calculées)
defense_bonusmalus
food_bonusmalus
iron_bonus
wood_bonus
cyniam_bonus
avatar_id                                    entier
building_productionWood                        entier
building_stockWood                            entier
building_productionIron                        entier
building_stockIron                            ......
building_productionCyniam
building_stockCyniam
building_productionFood
building_stockFood
building_wizardryTrainingAttack
building_wizardryTrainingDefense
building_armyTrainingHand2hand
building_armyTrainingDistancefighting
building_armyTrainingDefense
building_troopCamp
slotId_building_troopCamp
building_productionMotorizedUnit
building_wizardSchool
building_manaHarvesting
building_science
building_wall
building_turret                               
building_ambassy                            entier
building_guild

Tous les champs obligatoires
name, coordinates_slotId, size, defense_bonusmalus, food_bonusmalus, iron_bonus, wood_bonus, cyniam_bonus, avatar_id sont déterminés au moment de la création
les autres sont mis par défaut aux valeurs de départ (soit par la création de la ville, soit directement dans la table ?)
======================================================================================================

WorldSlot
---------
id
coordinates
terrain
vegetation
climate
state (occupé, occupable, ou pas occupable) => 3 états possibles
whatIsOn (si occupé, dire ce qui l'occupe > liste possible [ville, armée, quête ...]), utile pour l'affichage
world_id (au départ il n'y a qu'un seul monde mais ça peut évoluer)
tile
NB: pas besoin de définir de taille ou des boni (defense, eat ..) car ça sera associé au village en fonction des caractéristiques de ces slots => redondance ?

Tous les champs sont obligatoires. On pourrait les définir par défaut dans la table et ils seraient changés au moment de la création du monde?
================================================================================================================

Guild
------
id
name
creationDate
endingDate
promoter_name

Tous les champs sont obligatoires, promoter_name = clé étrangère (avatar). Je laisserais tomber member_name puisqu'il y a une table member-guilde
==================================================================================

Table index_marche
 il faudrait rajouter l'id du marché auquel l'index est associé


Dans la table BdC, il y a town_name NOT NULL. Pourquoi faut-il associer une ville à 1 BdC? Ne serait-ce pas plutôt l'id du marché si la transaction concerne un marché et non la bourse?
De toute façon, un BdC concerne soit la bourse (=> offre_id) soit un marché => market_id devrait s'y trouver aussi.

Table emplacement_marche_joueur (ou guilde) => Market_player (_guild) (site en anglais): je suppose qu'il n'y a qu'un proprio mais qu'il peut y avoir plusieurs locataires => je mettrais un table de relations avatar(ou guilde)-marché (voir plus bas)
------------------------------------------------------------
market_id
worldslot_id
name
place_price
location_price
market_type (liste à dresser)
percent_tax
owner_type (avatar ou guilde)
owner_id
rent_duration


Table Market_avatar ou Market_guild: liste des relations avatar-marchés (ou guildes-marchés), avatars qui louent un emplacement sur un marché
-----------------------------------
avatar_id   ou guild_id
market_id

Je ne comprends pas l'utilité de la table index_avatar,  les données se trouvent dans la table avatar
?? => utilité??


Voilà, que chacun donne son avis sur ces propositions bien incomplètes.

A +

Domi