+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Conseils pour modelisation bdd. (/showthread.php?tid=2201)
Pages :
1
2
Conseils pour modelisation bdd. - Ogham - 29-12-2007
Bonsoir,
Je commence a réfléchir à la mise en place de la bdd de mon jeu et je dois bien avouer que je ne sais trop par quel bout le prendre.
Voilà ce qui me pose question:
mes joueurs devront gérer leur clan, un groupe d'habitants.
Mais ce clan est composé de deux "castes" (pas trouvé de meilleurs mot)
caste 1 => les habitants lambdas
Ils exercent un métier soit de collecteur soit d'artisan et produisent des ressources qui seront consommées par les membres du clan ou vendu sur le marché des joueurs. Ses ressources sont tout à fait quelconques et n'ont aucune particularité:
Un bout de bois et un bout de bois et on en fait un manche d'outil et point.
Ils peuvent évoluer dans leur métier jusqu'à pouvoir intégrer la caste 2.
les travailleurs de cette caste sont gérés comme des bâtiments de production de manière automatique.
Caste 2 => des "super" collecteurs, des "super" artisans et des aventuriers
Ils récoltent, utilisent des "super" ressources et produisent des items qui seront utilisés par les aventuriers.
le collecteur ne coupe pas un bout de bois mais un sapin- élément feu - charge élémentaire: 50 - qualité 32%- avec lequel un "super" artisan fabriquera un objet qui héritera des qualités du bout de bois + de celles de toutes les autres ressources qu'il combinera dans son craft.
ce qui donnera un objet non standardisé.
les travailleurs de cette caste ont accés à de nouvelles compétences métier que le joueur peut faire évoluer comme bon lui semble et qui auront une influence sur le résultat des action menées.
les collecteurs sont semis automatisés par contre pour le travail des artisans c'est le joueurs qui prend les commande et bidouille les ingrédients pour fabriquer un item.
voilà pour la description sommaire
Donc je me demande comment gérer ses deux castes qui n'interagissent pas du tout de la même façon avec leur environnement qui change lui aussi.
pensez vous que je puisse les gérer en parallèle ?
avec d'un côté:
une table caste1 englobant les habitants lambdas
attachée à des tables:
metiers_castes1
competences_metiers-caste 1
ressources_ caste1
etc
et de l'autre
la table caste2 englobant les super habitants
attachée à des tables
metiers_caste2
ressources_speciales
items_speciaux
competances _metiers
etc
C'est un peu brouillon excusez moi mais ça reflète bien l'état d'esprit du moment.
Je n'arrive pas à visualiser les implications d'une telle structure sur le reste de la base enfin bref comme dit au début je ne sais pas par quel bout le prendre.
merci pour vos conseils.
RE: Conseils pour modelisation bdd. - Mysterarts - 29-12-2007
Salut,
bah écoute, je connais pas la totalité de ton système de table, mais je pense que ta solution va devoir être utilisé, au vu des différences entre les deux castes qui sont très importante (Il ne suffira que de supprimer une entrée dans la première et en créé une dans la seconde en cas de changement de caste...).
La question c'est aussi de voir ce que tu va en faire... Par exemple, peut être as tu pas mal de script qui veulent connaître la totalité des deux castes, dans ce cas la, la solution de 2 systèmes de table pourra s'averrer pénible, on peut alors imaginer une seul table pour les deux castes, avec une champ "caste" qui contient soit 1 soit 2, et des champs inutiles quand on est en caste 1...
Faut voir quoi
Mysterarts
RE: Conseils pour modelisation bdd. - Ogham - 04-01-2008
Bonjour,
pardon de n'avoir pas répondu plus tôt j'ai finalement tout repris depuis le début et j'essaie de modéliser ça par petits bouts.
Merci pour ta réponse Mysterarts je me garde ça sous le coude pour le moment où je reprendrais cette partie.
Donc si vous voulez bien j'aimerais vous demander conseils au fur et à mesure que j'avance.
C'est la première fois que je m'essaie créer un modèle de bdd si complexe donc soyez indulgents s'il y a des bêtises.
Donc voici un début:ma table joueurs et bâtiments
capture d'écran ici
quelques explications sur la structure
Les joueurs possèdent des bâtiments (entrepots, places de marché etc)
les habitants des joueurs également, il peuvent avoir une maison ou un atelier qui leur est propre et n'est pas celui du voisin.
donc ma première question est :
Trouvez vous cette structure bancale ?
Le choix des types de champ vous paraissent t'ils cohérents ?
mince ça fait deux questions ça ...
Et une troisième:
j'ai envisagé de diviser la tables joueurs en deux
une table profil contenant les infos de connection avatar signatures etc
et une table cités_joueurs contenant les infos relatives à la cité des joueurs.
Pensez vous que cela en vaille la peine ?
voilà je vous remercie pour vos conseils.
bonne journée
RE: Conseils pour modelisation bdd. - Plume - 04-01-2008
Bonjour ! :]
Tu pourrais fournir un dictionnaire ? Il s'agit en gros d'un listing des attributs avec leurs définitions.
Merci.
Lex.
RE: Conseils pour modelisation bdd. - Ogham - 04-01-2008
bonsoir,
les attributs ce sont les clefs étrangères c'est bien çà ?
donc ici
table habitants_joueurs :
attribut id_joueurs correspond à l'id_joueur enregistré dans la table joueurs.
table batiments_habitants :
id_joueur = id_joueur de table_joueurs
id_batiment= id_batiment de table batiment
id_habitant = id_habitant de table habitants_joueurs
table batiments_joueurs:
id_batiment=id_batiment de table batiment
id_joueur=id_joueur de table_joueurs
si j'ai mal compris désolé...
hum du coup j'ai l'impression qu'il y a un problème il faudrait que j'ajoute un champ identifiant unique dans les tables batiments_joueurs et batiments_habitants non ?
Edit:
j'ai donc modifié le modèle il semble que j'ai égaré des clés primaires en route dans le premier :/
nouvelle image ici
Et donc les clefs étrangères sont celles énoncées plus haut.
Est ce correcte maintenant ?
RE: Conseils pour modelisation bdd. - Plume - 05-01-2008
Bonsoir :]
Alors d'abord les attributs ne sont pas les clés étrangères, ce sont tous tes champs { si j'puis dire :] }
Ensuite, il ne fallait pas ajouter les clés primaires dans les tables de liaisons. Une clé primaire peut être un ensemble de clés, donc pour ( id_batiment, id_joueur, id_habitant ). En bref, ton modèle était plus mieux avant modification
Lex.
RE: Conseils pour modelisation bdd. - Ogham - 05-01-2008
Bonjour
Arf, j'avoue que je ne comprend pas pourquoi les clefs primaires sont inutiles.
imaginons deux enregistrement dans la table batiments_joueurs:
id_batiment => 1 (un entrepot dans la table batiments)
id_joueur => 12 (gustave dans la table joueurs)
état (état du batiments 40% il faudrait le réparer un peu là il y a une fuite dans le toit)
et
id_batiment => 1 (un second entrepot)
id_joueur => 12 (toujours gustave)
état => 100% un entrepot flambant neuf donc)
il faut bien un identifiant unique pour savoir quel bâtiment le joueur va devoir réparer ou lequel va s'écrouler s'il ne fait rien non ?
RE: Conseils pour modelisation bdd. - Plume - 05-01-2008
Ah ! J'avais pas compris ça comme ça :]
Dans ce cas, laisse les clés primaires, par contre, les attributs id_batiment, id_joueur, id_habitant n'ont pas à être en clés primaires mais juste en attribut NOT NULL dans les tables de liaisons :].
Je pense qu'il y a un problème de représentation de la possession des bâtiments. J'penserais plutôt à un TE ternaire entre Joueurs, Batiments et Habitants ;]
RE: Conseils pour modelisation bdd. - Ogham - 05-01-2008
bonsoir,
Citation :Dans ce cas, laisse les clés primaires, par contre, les attributs id_batiment, id_joueur, id_habitant n'ont pas à être en clés primaires mais juste en attribut NOT NULL dans les tables de liaisons :].
oui en effet je ne voulais pas au départ en faire des clés primaire mais elles se sont crées automatiquement quand j'ai fais les relations entre les tables, je ne maitrise pas bien le logiciel c'est tout neuf pour moi tout comme la conception de bdd relationnelle mais ça je suppose que ça ce voit comme le nez au milieu de la figure
En fait je pensais les mettre en attribut NOT NULL et en index puisque les principales recherches se feront sur ces champs a priori.
Citation :J'penserais plutôt à un TE ternaire entre Joueurs, Batiments et Habitants ;]je vais surement passer pour une bille mais c'est ce que j'ai essayé de faire mais je me suis perdu en route apparemment.
Et là je ne vois pas trop comment faire.
mais mon modèle est il vraiment mauvais ?
Je n'ai pas l'impression que ça puisse engendrer des problèmes est ce que je me trompe ?
Car il a un avantage pour moi c'est qu'il me semble logique et je le comprend facilement, c'est déjà ça quand on n'a pas la pratique et l'expérience.
en tout cas merci pour ton aide
[/quote]
RE: Conseils pour modelisation bdd. - Plume - 06-01-2008
Faut savoir, nous sommes relationnels ou nous ne le sommes pas
Quelque chose qui peut aider, c'est d'écrire les relations à la main.
Par exemple :
id_joueur --> (
pseudo ,
mot_de_passe ,
email ,
date_inscription ,
derniere_connection ,
avatar ,
signature ,
nom_cite ,
localisation_y ,
localisation_x ,
budget ,
population
)
id_habitant --> (
id_joueur ,
nom_habitant ,
sexe_habitant ,
age_habitant ,
id_conjoint ,
id_metier ,
localisation_x ,
localisation_y
)
id_batiment --> (
id_habitant ,
nom_batiment ,
type_batiment ,
description_batiment
)
J'aimerais que tu m'expliques pourquoi il y a id_metier et type_metier.
J'aimerais que tu m'expliques l'utilité de localiser un joueur, et la différence avec la localisation d'un habitant. Selon moi, la localisation dans la table joueurs est de trop, sauf si ça s'explique.
J'aimerais que tu m'expliques la différence entre un bâtiment d'un joueur & un bâtiment d'un habitant.
Je pense que ta table fait preuve d'incohérence. Cela dépend maintenant des explications que tu peux nous donner. Qui aurait pu partiellement être complétée avec le dictionnaire que je demandais au début
Je continuerais mon exemple si tu en as besoin & après tes explications.
Lex.