25-06-2017, 02:00 PM
Salut,
int x ; int y me semble être une bonne approche si tu ne gardes que des cartes "tableau" (à cases carrées). Si, à l'avenir, les cartes deviennent exotiques, alors tu auras tout le temps de basculer vers l'extension MySQL Geometry ( https://toile.reinom.com/les-astuces-et-...n_Geometry ) ou l'équivalent sur ton SGBD. N'oublies pas d'indexer les deux colonnes dans une clef UNIQUE ( https://toile.reinom.com/les-astuces-et-...s_colonnes )
Pour les objets, il te suffit de les stocker dans une seconde table "objets", sous la forme (int id AUTO_INCREMENT, id_case; type_objet, description, etc) et d'ajouter une colonne "int id" à ta table de cases et une clef étrangère faisant référence entre id_case de la table objet et id de la table cartes te suffira à faire le liant. C'est une relation 1-N classique. Idem pour la fouille (là, soit tu fais une autre table objet_fouille s'il y a des méta données en plus, soit t'ajoutes juste une colonne TINYINT(1) à la table "objets" indiquant si l'objet est disponible en fouillant ou directement.
Ne sérialise pas avec des virgules. C'est une anti-solution de chiasse ( https://toile.reinom.com/la-serialisatio...gbd-mysql/ ). Dans ton cas, c'est une simple relation 1-N qu'il faut faire. Pour rappel:
• Relation 1-1: 1 entité est rattaché à 1 seule autre, cela se modélise facilement en créant 1 seule table pour les deux entités (ie: 1 compte d'un joueur n'a qu'un seul email, donc l'email est stocké dans la table des comptes)
• Relation 1-N: 1 entité (table A) est rattachée à 0, 1 ou N entités (table B), cela se modélise facilement en donnant un ID à cette entité et en y faisant référence dans les N autres entités (la table B a une colonne "ID_tableA")
• Relation N-N: N entités (table A) sont rattachées à N autres entités (table B) [en gros, la situation est "c'est le bordel"], cela se modélise en donnant un ID à toutes les entités (une colonne ID dans la table A et une autre dans la table B) et en créant une troisième table de relation (table R) qui indique quel ID de A est rattaché à quel ID de B
Tu trouveras plus d'infos sur le net sur les relations 1-1/1-N/N-N en SQL.
int x ; int y me semble être une bonne approche si tu ne gardes que des cartes "tableau" (à cases carrées). Si, à l'avenir, les cartes deviennent exotiques, alors tu auras tout le temps de basculer vers l'extension MySQL Geometry ( https://toile.reinom.com/les-astuces-et-...n_Geometry ) ou l'équivalent sur ton SGBD. N'oublies pas d'indexer les deux colonnes dans une clef UNIQUE ( https://toile.reinom.com/les-astuces-et-...s_colonnes )
Pour les objets, il te suffit de les stocker dans une seconde table "objets", sous la forme (int id AUTO_INCREMENT, id_case; type_objet, description, etc) et d'ajouter une colonne "int id" à ta table de cases et une clef étrangère faisant référence entre id_case de la table objet et id de la table cartes te suffira à faire le liant. C'est une relation 1-N classique. Idem pour la fouille (là, soit tu fais une autre table objet_fouille s'il y a des méta données en plus, soit t'ajoutes juste une colonne TINYINT(1) à la table "objets" indiquant si l'objet est disponible en fouillant ou directement.
Ne sérialise pas avec des virgules. C'est une anti-solution de chiasse ( https://toile.reinom.com/la-serialisatio...gbd-mysql/ ). Dans ton cas, c'est une simple relation 1-N qu'il faut faire. Pour rappel:
• Relation 1-1: 1 entité est rattaché à 1 seule autre, cela se modélise facilement en créant 1 seule table pour les deux entités (ie: 1 compte d'un joueur n'a qu'un seul email, donc l'email est stocké dans la table des comptes)
• Relation 1-N: 1 entité (table A) est rattachée à 0, 1 ou N entités (table B), cela se modélise facilement en donnant un ID à cette entité et en y faisant référence dans les N autres entités (la table B a une colonne "ID_tableA")
• Relation N-N: N entités (table A) sont rattachées à N autres entités (table B) [en gros, la situation est "c'est le bordel"], cela se modélise en donnant un ID à toutes les entités (une colonne ID dans la table A et une autre dans la table B) et en créant une troisième table de relation (table R) qui indique quel ID de A est rattaché à quel ID de B
Tu trouveras plus d'infos sur le net sur les relations 1-1/1-N/N-N en SQL.