+- 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 : Modelisation de données (/showthread.php?tid=7888)
Pages :
1
2
RE: Modelisation de données - Ter Rowan - 28-10-2017
perso je ne mettrais pas les cursus en colonne, mais une table joueur / cursus / niveau / en cours (oui/non) ou joueur / cursus / valeur décimale (niveau.progression, j 'aime bien l'idée de niahoo)
et ce pour deux raisons :
1) le jour où tu veux créer un cursus exploitation minière, tu peux sans rien changer, ni au code, ni aux tables
2) le cursus sert probablement à quelque chose... acquisition de compétences, etc... et là tu ne vas pas créer autant de tables / colonnes / programme qu'il y a de cursus
une table id cursus / id compétences / niveau cursus / donne niveau compétences suffira par exemple. bref tout dépend des raisons du cursus et comment il est exploité, mais ce serait bien plus pratique à mon sens d'oublier dans le modèle quels sont les cursus, et de les mettre dans les données (dans les enregistrements)
RE: Modelisation de données - Xenos - 28-10-2017
Citation :exploitation minière, tu peux sans rien changer, ni au code, ni aux tablesBien sûr que si: si chaque type de cursus vient avec un bundle de code d'actions et d'effets spécifiques, il faut que le type de cursus soit un élément structurant de la table, pas une donnée (d'où ma séparation de cas dans ma réponse). Les colonnes ne peuvent avoir un éventuel intérêt que si t'as des dizaines de cursus, tous avec la même règle d'effet mais des valeurs de bonus différents (par exemple).
[...]tu ne vas pas créer autant de tables / colonnes / programme qu'il y a de cursus
J'aime pas, j'ai l'impression d'être pas lu là... Et Air non plus... Il a dit que "le cursus dure 1 an dans le jeu": comment veux-tu stocker le niveau avec des décimales pour la progression? Ca n'a pas de sens...
Après, tu peux de toute façon switcher l'un des modèles en l'autre voire même conserver les deux via les vues (je ne sais pas si c'est vraiment intéressant, mais bon...).
RE: Modelisation de données - Ter Rowan - 28-10-2017
ton impression est mauvaise j'ai lu, mais je ne suis pas forcément d'accord avec toi et les réponses d'air laissent suffisamment de liberté d'interprétation
concernant les cursus j'ai proposé le modèle binaire (j'ai / j'ai pas le niveau) tout comme le modèle progression : si le niveau n'est pas validé rien ne dit dans la réponse d'air que rien n'est appris et ne peut pas être réutilisé : le niveau n'est pas validé, le joueur veut le retenter. A-t-il les mêmes chances de réussite ? ce serait ridicule non ?
concernant la structure des données, je considère que c'est complexifier la chose sans réel avantage. Et puis si demain, le jeu change d'univers, qu'on rentre dans un monde hospitalier, ou un monde aquatique ou un monde je sais pas quoi. On fera quoi, on changera le nom des colonnes, des requetes, du code alors qu'un simple libellé de master data suffirait ?
quelles différences de gameplay justifieraient cela ? quelles différences de gameplay ne pourraient être pilotées en aval par un pattern factory ou équivalent switch case ?
tu dis c'est de la donnée si c'est manipulable à la volée; je dis c'est de la donnée pour pouvoir être évolutif et maintenable simplement
RE: Modelisation de données - Xenos - 28-10-2017
Bon, je laisse Air décider s'il veut un modèle qui correspond à son problème posé avec 4 colonnes pour 4 cursus et 1 colonne pour le cursus en cours (et une dernière pour la date, vu que son gameplay se base dessus) ou s'il préfère d'autres modèles théoriques abstraits ultra-extensibles pour être capable de digérer l'éventuel univers des possibilités envisageables qui pourraient s'esquisser à l'horizon du paysage des hypothèses.
Il me semble que cette approche du "je tente de prévoir tout l'avenir et du coup je pourris mon présent et mon projet", je l'avais mis en article, mais j'avoue qu'aujourd'hui, j'ai la flemme de chercher... désolé, je ne sais pas trop pourquoi, mais tout ça m'a un peu gonflé.
RE: Modelisation de données - Air - 28-10-2017
Hey les gars ça vaut pas le coup de se prendre la tête pour ma question.
Il est difficile de donner un avis lorsqu'on ne connait pas l'ensemble des éléments que j'ai en tête (ou pour lequel je ne me suis même pas posé la question).
Ce qui est sûr c'est que je ne vais pas faire un modèle théorique pour d'autres univers. Déjà si j'arrive à avancer et faire un truc potable pour mon jeu actuel ça serait pas mal.
Je ne pas me projeter au delà :-)
Je vais donc conserver mes 4 colonnes. La colonnes encours sera vide si je suis aucun cursus. 1 si je suis le cursus 1; 2 pour le cursus 2, etc...
On clos le débat :-)
Merci à tous pour vos avis.
RE: Modelisation de données - Xenos - 29-10-2017
Pour info, l'ENUM revient à faire ta dernière colonne: les valeurs sont, en pratique, stockées dans un entier et converties à la volée par MySQL en la chaîne de caractères correspondante ("Compact data storage in situations where a column has a limited set of possible values. The strings you specify as input values are automatically encoded as numbers" https://dev.mysql.com/doc/refman/5.7/en/enum.html ). Ca a l'avantage aussi de ne pas requérir une connaissance magique côté client de "1 = Militaire, 2 = Commercial, etc" et d'être très lisible (on voit "MILITAIRE" comme valeur de colonne au lieu de juste "1").
Autre avantage: cela t'évites de stocker, par mégarde, un nombre qui ne correspond à aucun cursus (alors qu'un type TINYINT UNSIGNED permettra de stocker n'importe quoi entre 0 et 255, y compris des valeurs qui n'ont pas de sens). Cela peut t'éviter, par exemple, de foirer la validation des entrées du serveur PHP. Typiquement, si ta page web de choix de cursus a un <select><option value="1">Militaire</option><option value="2">Commercial... alors avec un stockage INT en BDD, tu te retrouves obligé de valider que le choix est 1, 2, 3 ou 4 (disons qu'il n'y a que 4 cursus, je n'ai plus le nombre en tête) dans ton code PHP, *avant* de l'envoyer à la BDD (sinon, la BDD contiendra des données incohérente, genre le cursus 42).
Avec un ENUM, tu peux laisser la BDD faire cette vérification (pour peu que les paramètres STRICT soient bien établis). Ta page devient <select><option value="MILITAIRE">Militaire</option><option value="COMMERCIAL">Commercial... et ton serveur PHP n'a (éventuellement) même plus besoin de valider l'entrée de l'utilisateur (ou juste leur existence): le code PHP passe la valeur entrée par l'utilisateur direct à la BDD, et si la BDD ne trouve pas cette valeur dans l'ENUM, alors elle lancera toute seule une exception (SIGNAL) que le code PHP catchera (si PDO est utilisé, c'est quasi-natif) et la valeur sera refusée à l'enregistrement. Perso, c'est ce que je fais sur Iamanoc (que j'ai un peu délaissé ces derniers mois :/ ): cela permet de faire moins de code et de le faire de manière plus sûre (on ne peut pas oublier un check ou une valeur de l'ENUM quand c'est la BDD qui fait directement les vérifications).
Note que, pour l'info, si plusieurs cursus pouvaient se faire en parallèle, "SET" aurait fonctionné tout pareil que ENUM (à la différence que SET permet de stocker plusieurs "valeurs" d'un ENUM en même temps, genre "MILITAIRE, COMMERCIAL" au lieu de juste l'un ou juste l'autre, cf https://dev.mysql.com/doc/refman/5.7/en/set.html )
Bonne création de jeu à toi
