Page 1 sur 1
Organisation de tables
Posté : 08 oct. 2006, 19:03
par fiatt
Bonjour tout le monde.
Je me permet de vous exposer mon soucis actuel.
Je tente la réalisation d'un script pour un jeu 100% PHP.
A cette fin j'essaye d'organiser mes tables pour la distribution des ressources du joueur.
Un joueur acquiert des machines et ces machines produisent de la ressource.
Chaque machine ne produit qu'un seul type de ressource (5 types différents) mais le joueur peut posséder plusieurs machines.
J'ai donc au moins 2 tables: "joueurs" et "machines"
Si je créé une table "ressources", elle n'aura que 5 enregistrements car il n'existe que 5 types de ressources => inutile
Comment et où positionner les stocks?
Si je créé une table "stock" contenant les stocks selon le type de ressource je ne vois pas comment y mettre une clé primaire.
J'y ai passé tout l'après-midi et je ne suis pas plus avancé...
Merci de votre aide.
Posté : 08 oct. 2006, 19:41
par Cyrano
Crée une relation entre ces deux tables :
Code : Tout sélectionner
+-----------------+ +-----------------+ +-------------------+
| Joueurs | | Ressources | | Machines |
+------------+----+ +---------+-------+ +--------------+----+
| jou_id | PK |-----| jou_id | PK FK |-----| mac_id | PK |
| jou_nom | | | mac_id | PK FK | | mac_type_res | |
| jou_prenom | | | res_qte | | +--------------+----+
| jou_etc... | | +---------+-------+
+------------+----+
De cette manière, les tables joueurs et macine sont indépendantes, tu peux même ajouter ou retirer des machines ou des joueurs sans que l'autre en soit affectée. Mais entre les deux, tu peux avoir le stock accumulé pour chaque joueur individuellement.
Est-ce que tu arrives à visualiser mieux le fonctionnement ?
Posté : 08 oct. 2006, 20:03
par fiatt
Oui merci beaucoup.
La première table ok.
Dans la troisième (Machines) je peux y mettre les champs décrivant les capacités de production des différentes machines.
Dans ce cas, la seconde table me sert aux calculs de stock. J'y rentre les champs de capacité de stock, le nombre de machine possédées selon le type, la date de dernier calcul etc.
Je pensais qu'il était nécessaire de mettre une clé primaire différente pour chaque table mais je vois que tu reprends pour la table n°2 les clés des 2 autres tables?
Posté : 08 oct. 2006, 20:16
par Cyrano
La table intermédiaire est une relation : elle relie directement un joueur précis avec une machine précise. Si le joueur A possède une machine x et une machine y, ça fera deux lignes dans la table intermédiaire : il te restera à ajouter outre les clés primaire correspondantes des deux autres tables la quantité stockée correspondante. Si le stock doit changer, tu fais une mise à jour sur cette ralation et tu ne fais d'insertion que si un joueur acquiert une nouvelle machine.
Il te reste donc à voir comment tu dois gérer les informations propres à la machine. Sa capacité de production par exemple : Si c'est une donnée propre à la machine et indépendante du joueur, ça reste dans la table machines, mais si ça dépend du joueur, alors cette donnée se retrouvera dans la table intermédiaire.
Posté : 09 oct. 2006, 13:36
par fiatt
Merci Cyrano, c'est maintenant plus clair dans ma tête.
Par contre je n'ai jamais utilisé les clés étrangères alors on va essayer de se documenter.
Cette organisation me plais bien mais je ne vois pas quelle Clé primaire je pourrais mettre dans la seconde table.
Les infos de cette table seront fonctions des 2 FK mais est-il nécessaire d'indexer par une clé primaire?
Posté : 09 oct. 2006, 16:09
par fiatt
Bon alors les clés étrangères je ne maitrise pas du tout...
Il doit bien y avoir un moyen de lier 2 tables sans passer par des FK et des tables innoDB?
Cela doit être réalisable avec des SELECT JOIN mais du coup je reviens à la case départ... comment faire apparaitre que le joueur 1 possède telle ou telle machine? (je ne vois que la solution de la table unique...)
Posté : 09 oct. 2006, 16:41
par pascaltje
tu peux créer les champs "tels quels" sans forcément précisément à la base de données qu'il y a des clés étrangères.
de toutes façons, dans tes requêtes, tu feras la jointure sur ces champs correspondant à ces clés étrangères.
A+
Pascal
Posté : 09 oct. 2006, 16:52
par fiatt
Alors en ne mettant les champs sans précison de plus je fais "à la main" les avantages des FK? c-a-d, si j'ai bien compris, à chaque changement de donnée dans une table "mere" je ne dois pas oublier de faire ce même changement dans la table "de relations"?
Posté : 09 oct. 2006, 16:55
par pascaltje
ha mais on ne change pas les FK!
Posté : 09 oct. 2006, 16:56
par fiatt
désolé Pascal mais je ne crois pas tout comprendre...
Posté : 09 oct. 2006, 19:04
par Cyrano
Qu'est-ce qu'une clé primaire et qu'est une clé étrangère ?
Dans une table quelconque, il n'est jamais obligatoire mais le plus souvent très vivement recommandé d'avoir une clé primaire : c'est quoi ? une colonne dans la table qui aura une valeur unique : cette valeur servira de point de repère lorsqu'on manipulera les données d'une ligne pour ne pas bousiller les autres lignes. On utilisera souvent un champ de type entier non signé et auto-incrémenté : mais attention, en principe il ne faut jamais considérer la clé primaire comme une donnée faisant partie des autres informations de la table : on ne l'utilise que comme point de repère, on ne la modifie pas et il n'y a aucun calcul qui est fait en dehors des clauses de tri d'une requête.
La clé étrangère quant à elle, c'est quoi ?
C'est une colonne dans une table dont la valeur ne sera pas forcément unique. Elle fait référence à la clé primaire d'une autre table : elle devra donc impérativement être du même type à l'exception de l'auto-incrémentation. Lorsque tu insères une donnée dans une table A, la clé primiare de cette table A va être définie, automatiquement si c'est un auto-incrément. Maintenant, tu fais une insertion dans une table B qui correspond à une des lignes de la table A : tu devras avoir dans la colonne qui est la clé étrangère dans la table B la valeur de la clé primaire de la table A sur laquelle se référencent tes données.
Est-ce que c'est pas trop compliqué comme explication ?
Posté : 09 oct. 2006, 19:46
par fiatt
C'est parfait Cyrano, je pense avoir compris la subtilité.
J'ai enfin pu définir correctement mes tables.
Merci encore!