27-10-2017, 09:47 AM
Salut,
tu peux y mettre du Json
Si et seulement si ce JSON est proprement géré par la BDD, ce qui veut dire compris par la BDD (MySQL 5.7+ par exemple) et correctement indexé ou jamais recherché, et correctement sérialisé/désérialisé lors de la communication avec la BDD (ie: pour PHP+PDO+MySQL, tu vas tevoir te tapper un json_decode côté client + la lourdeur du transfert éventuel entre MySQL et PHP).
Le décimal est une solution risquée, car je ne suis pas certain que les calculs dessus seront exacts (est-ce que "niveau 7.56 + 0.44 = 8.0 pile poil" pour dire que le niveau est fini? pas sûr). Les jointures, OSEF très certainement vu la quantité de données en jeu (cela serait Facebook, je ne dis pas).
Perso, je n'aurai pas du tout posé les mêmes questions que Niahoo. La première question à se poser c'est:
Est-ce que les cursus sont des données, ou de la structure?
Tes cursus sont des données si tu peux/veux en rajouter "à la volée", sans modifier la logique générale du jeu, ou éventuellement si tu en as une bonne dizaine. Dans un tel cas, il doit exister une table "Cursus: INT id, VARCHAR label" listant les cursus (1, "MILITAIRE"; 2, "PILOTAGE"; ...). Tu auras alors une table "joueur_cursur: INT id_joueur, INT id_cursus, INT level, BIT(1) est_en_cours" et éventuellement, une colonne "XP" ou "progression" si nécessaire. Si une et un seul cursus n'est faisable à la fois, un "UNIQUE INDEX id_joueur, est_en_cours" peut se faire, en rendant est_en_cours NULLABLE (ie: 1 = en cours, NULL = pas en cours). L'unicité de l'index assurera qu'un seul cursus par joueur sera à 1.
Sinon, tes cursus sont de la structure si chacun vient avec un lot de règles spéciales, et que l'ajout d'un cursus est (par définition du gameplay et de l'existence de ces règles spéciales) une opération lourde; le nombre de cursus doit également être limité (là, 4, c'est largement assez OK). Si tes cursus sont une structure, alors leur "ajout à la volée" n'est pas nécessaire, et on peut faire des tables plus "lourdes" mais plus simples à manipuler, type:
INT id_joueur, ENUM ("MILITAIRE", "PILOTAGE",...) en_cours, INT lvl_militaire, INT lvl_pilotage, INT lvl_commercial; INT lvl_scientifique
L'ENUM peut être nullable si un joueur peut ne suivre aucun cursus. Une colonne "progression" (FLOAT ou TINYINT) peut être rajoutée si la notion de progression est requise pour le cursus en cours.
Dans tous les cas, le JSON et la sérialisation, heu, non. Ta colonne "0100", une colonne binaire sérialisante comme soulevé à juste titre par Niahoo, n'est pas une bonne solution car elle n'assurera pas l'unicité du cursus suivit (la valeur 0101 sera possible, la seule solution, c'est de bombarder de TRIGGER...). Pour JSON, même problème au niveau de l'unicité du cursus suivit.
Et nota: tous les ne pouvant avoir de valeur négative peuvent être UNSIGNED. Je te laisse placer les autres index comme il faut.
tu peux y mettre du Json
Si et seulement si ce JSON est proprement géré par la BDD, ce qui veut dire compris par la BDD (MySQL 5.7+ par exemple) et correctement indexé ou jamais recherché, et correctement sérialisé/désérialisé lors de la communication avec la BDD (ie: pour PHP+PDO+MySQL, tu vas tevoir te tapper un json_decode côté client + la lourdeur du transfert éventuel entre MySQL et PHP).
Le décimal est une solution risquée, car je ne suis pas certain que les calculs dessus seront exacts (est-ce que "niveau 7.56 + 0.44 = 8.0 pile poil" pour dire que le niveau est fini? pas sûr). Les jointures, OSEF très certainement vu la quantité de données en jeu (cela serait Facebook, je ne dis pas).
Perso, je n'aurai pas du tout posé les mêmes questions que Niahoo. La première question à se poser c'est:
Est-ce que les cursus sont des données, ou de la structure?
Tes cursus sont des données si tu peux/veux en rajouter "à la volée", sans modifier la logique générale du jeu, ou éventuellement si tu en as une bonne dizaine. Dans un tel cas, il doit exister une table "Cursus: INT id, VARCHAR label" listant les cursus (1, "MILITAIRE"; 2, "PILOTAGE"; ...). Tu auras alors une table "joueur_cursur: INT id_joueur, INT id_cursus, INT level, BIT(1) est_en_cours" et éventuellement, une colonne "XP" ou "progression" si nécessaire. Si une et un seul cursus n'est faisable à la fois, un "UNIQUE INDEX id_joueur, est_en_cours" peut se faire, en rendant est_en_cours NULLABLE (ie: 1 = en cours, NULL = pas en cours). L'unicité de l'index assurera qu'un seul cursus par joueur sera à 1.
Sinon, tes cursus sont de la structure si chacun vient avec un lot de règles spéciales, et que l'ajout d'un cursus est (par définition du gameplay et de l'existence de ces règles spéciales) une opération lourde; le nombre de cursus doit également être limité (là, 4, c'est largement assez OK). Si tes cursus sont une structure, alors leur "ajout à la volée" n'est pas nécessaire, et on peut faire des tables plus "lourdes" mais plus simples à manipuler, type:
INT id_joueur, ENUM ("MILITAIRE", "PILOTAGE",...) en_cours, INT lvl_militaire, INT lvl_pilotage, INT lvl_commercial; INT lvl_scientifique
L'ENUM peut être nullable si un joueur peut ne suivre aucun cursus. Une colonne "progression" (FLOAT ou TINYINT) peut être rajoutée si la notion de progression est requise pour le cursus en cours.
Dans tous les cas, le JSON et la sérialisation, heu, non. Ta colonne "0100", une colonne binaire sérialisante comme soulevé à juste titre par Niahoo, n'est pas une bonne solution car elle n'assurera pas l'unicité du cursus suivit (la valeur 0101 sera possible, la seule solution, c'est de bombarder de TRIGGER...). Pour JSON, même problème au niveau de l'unicité du cursus suivit.
Et nota: tous les ne pouvant avoir de valeur négative peuvent être UNSIGNED. Je te laisse placer les autres index comme il faut.