12-07-2007, 11:33 AM
Juste un petit soucis de design de base de données apparemment.
D'après ce que j'ai compris :
un joueur peut avoir plusieurs villages.
un village est composé de plusieurs batiments.
un village abrite plusieurs unités
un village possède plusieurs stocks de ressources
La structure que tu utilises Zigzog n'est pas assez souple et ne permet pas de gèrer une infinité de villages pour un joueur.
Je vais beaucoup paraphraser Mysterarts en essayant d'aller un peu plus loin dans les explications.
On commence par la table joueurs
Table Joueurs
joueur_id....joueur_nom
1............Zigzog
2............Mysterarts
3............Autrejoueur
Jusqu'ici, rien de bien compliqué.
Maintenant, il faut ajouter la notion de village.
Comme un joueur peut en avoir plusieurs,il est recommandé de faire une table spécialement pour les villages.
De plus, un village n'appartenant qu'à un seul joueur, inutile de faire une table de liaison à ce niveau.
Comme il y a peu de chance que de nouvelles ressources voient le jour et que tous les villages ont les même ressources, je les inclue dans la table village
Table Village
village_id....joueur_id....nb_or....nb_bois....nb_fer....nb_pierre....village_nom
1.............1............2000.....1000.......250.......2300.........ZigzogTown
2.............1............5000.....100........1000......300..........ZigzogCity
3.............2............2300.....2000.......1500......4000.........MysterartsCapital
On voit ici que Zigzog possède deux villages (ZigzogTown et ZigzogCity) et Mysterarts un seul (MysterartsCapital). On voit également en ligne la quantité de ressources dont ils disposent
Jusqu'ici, pas de gros changements avec ce que propose Mysterarts.
Vient ensuite le problème des batiments.
Je suppose que tous les villages ne possèdent pas dès le départ tous les bâtiments.
Pour éviter de polluer la base de donées avec des informations inutiles, on va commencer par faire une table qui référence tous les bâtiments puis une table de liaison qui indiquera quel village possède quel bâtiment (et à quel niveau)
En découpant ta base de données de cette manière, tu gagneras en souplesse mais aussi en place. Dans ta méthode initiale, tu dis avoir 40 champs pour stocker les batiments et les unités. comme un village à sa création ne possèdera pas tous les bâtiments et unités disponibles, cela fera un beau gachis d'espace dans la base de données.
Mais revenons à la structure de la table :
Table Batiments
batiment_id....batiment_nom
1..............Ecurie
2..............Grenier
3..............Caserne
Ensuite, il faut faire la table qui va contenir les informations associées à un bâtiment donné pour un village donné.
Table village_batiments
village_id....batiment_id....niveau
1.............1..............2
1.............2..............4
3.............1..............1
3.............3..............5
On voit grâce à cette table que
- le village 1 (ZigzogTown, qui appartient à Zigzog, cf table Village) possède une écurie niveau 2 et un grenier niveau 4.
- MysterartsCapital (village 3) possède un grenier niveau 1 et une caserne niveau 5
On peut éventuellement inclure dans le design de cette table le joueur_id. Ca peut être utile si jamais tu as besoin de savoir rapidement combien un joueur donné possède casernes/écuries/etc à travers tous ses villages.
Cette structure souple te permet de
- possèder plusieurs villages pour un joueur
- rajouter des types de bâtiments sans avoir à changer ta base de données
- connaître le type de bâtiment et leur niveau pour chacun des villages de ta base de données.
- économiser de la place dans la base de données car seuls les informations pertinentes y sont enregistrées.
Il est conseillé d'utiliser cette même structure pour les unités également (une table unités qui liste les types d'unités existant et une table village_unités qui fait le lien).
Cette modélisation permet encore une fois une grande souplesse dans l'évolution de ton projet. Rajouter une nouvelle unité ou un type de bâtiment se fera le plus simplement du monde.
Après, il faut connaître un minimum le SQL pour faire des jointures correctes entre les tables et ainsi récupérer ce qui t'intéresse
D'après ce que j'ai compris :
un joueur peut avoir plusieurs villages.
un village est composé de plusieurs batiments.
un village abrite plusieurs unités
un village possède plusieurs stocks de ressources
La structure que tu utilises Zigzog n'est pas assez souple et ne permet pas de gèrer une infinité de villages pour un joueur.
Je vais beaucoup paraphraser Mysterarts en essayant d'aller un peu plus loin dans les explications.
On commence par la table joueurs
Table Joueurs
joueur_id....joueur_nom
1............Zigzog
2............Mysterarts
3............Autrejoueur
Jusqu'ici, rien de bien compliqué.
Maintenant, il faut ajouter la notion de village.
Comme un joueur peut en avoir plusieurs,il est recommandé de faire une table spécialement pour les villages.
De plus, un village n'appartenant qu'à un seul joueur, inutile de faire une table de liaison à ce niveau.
Comme il y a peu de chance que de nouvelles ressources voient le jour et que tous les villages ont les même ressources, je les inclue dans la table village
Table Village
village_id....joueur_id....nb_or....nb_bois....nb_fer....nb_pierre....village_nom
1.............1............2000.....1000.......250.......2300.........ZigzogTown
2.............1............5000.....100........1000......300..........ZigzogCity
3.............2............2300.....2000.......1500......4000.........MysterartsCapital
On voit ici que Zigzog possède deux villages (ZigzogTown et ZigzogCity) et Mysterarts un seul (MysterartsCapital). On voit également en ligne la quantité de ressources dont ils disposent
Jusqu'ici, pas de gros changements avec ce que propose Mysterarts.
Vient ensuite le problème des batiments.
Je suppose que tous les villages ne possèdent pas dès le départ tous les bâtiments.
Pour éviter de polluer la base de donées avec des informations inutiles, on va commencer par faire une table qui référence tous les bâtiments puis une table de liaison qui indiquera quel village possède quel bâtiment (et à quel niveau)
En découpant ta base de données de cette manière, tu gagneras en souplesse mais aussi en place. Dans ta méthode initiale, tu dis avoir 40 champs pour stocker les batiments et les unités. comme un village à sa création ne possèdera pas tous les bâtiments et unités disponibles, cela fera un beau gachis d'espace dans la base de données.
Mais revenons à la structure de la table :
Table Batiments
batiment_id....batiment_nom
1..............Ecurie
2..............Grenier
3..............Caserne
Ensuite, il faut faire la table qui va contenir les informations associées à un bâtiment donné pour un village donné.
Table village_batiments
village_id....batiment_id....niveau
1.............1..............2
1.............2..............4
3.............1..............1
3.............3..............5
On voit grâce à cette table que
- le village 1 (ZigzogTown, qui appartient à Zigzog, cf table Village) possède une écurie niveau 2 et un grenier niveau 4.
- MysterartsCapital (village 3) possède un grenier niveau 1 et une caserne niveau 5
On peut éventuellement inclure dans le design de cette table le joueur_id. Ca peut être utile si jamais tu as besoin de savoir rapidement combien un joueur donné possède casernes/écuries/etc à travers tous ses villages.
Cette structure souple te permet de
- possèder plusieurs villages pour un joueur
- rajouter des types de bâtiments sans avoir à changer ta base de données
- connaître le type de bâtiment et leur niveau pour chacun des villages de ta base de données.
- économiser de la place dans la base de données car seuls les informations pertinentes y sont enregistrées.
Il est conseillé d'utiliser cette même structure pour les unités également (une table unités qui liste les types d'unités existant et une table village_unités qui fait le lien).
Cette modélisation permet encore une fois une grande souplesse dans l'évolution de ton projet. Rajouter une nouvelle unité ou un type de bâtiment se fera le plus simplement du monde.
Après, il faut connaître un minimum le SQL pour faire des jointures correctes entre les tables et ainsi récupérer ce qui t'intéresse
Quand on te dit qu'un projet est terminé à 90%, prépare toi pour les 90% suivant
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC