+- 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 : Grosse(s) table(s) (nouveaux éléments) (/showthread.php?tid=3040)
Grosse(s) table(s) (nouveaux éléments) - manip - 11-09-2008
Bonsoir,
Tout d'abord veillez m'excuser si mon sujet n'est pas dans le bon forum a vrai dire je ne savais pas trop ou le mettre ....
Voici mon problème :
j'ai 3 tables :
terrains 10 champs
ressources 12 champs
productions 7 champs
Voilà c'est trois tables sont séparées, mais les ressources et les taux de productions sont sur le terrain, donc en faite je pourrais réunir les trois tables en une seul mais ça ferait une table avec 25 champs (je retire joueur et terrain id de ressources et production).
Ma question est : est ce que ma methode avec les 3 tables est la meilleure ? Ou dois-je réunir mes tables.
J'ai eu un doute car j'ai deux tables pour les joueurs :
joueurs 14 champs (id, login, ip, date etc)
le personnage du joueur 11 champs (grade, lvl, hp, attaque, défense)
Hors je me demandais aussi si je devais réunir ces deux tables, étant donné que sur toutes les pages j'extrais des informations de ces deux tables.
Voilà c'est peut être bête comme question mais sur ce coup j'ai de gros doutes, donc si vous pouviez me rassurer ça serait sympas
. (j'ai surtout pas envie de devoir tout changer plus tard et de modifier pas mal de truc parce que j'avais mal fait =))Merci d'avance
Bonne nuit
RE: Grosse(s) table(s) - phenix - 11-09-2008
Par soucis de lisibilité et de clarté, je pense que 3 tables c'est le mieux.
Pour moi, il ne faut mettre dans une table les informations d'une seul "chose" et ne pas mélanger les joueurs avec les monstres par exemple.
RE: Grosse(s) table(s) - Sephi-Chan - 11-09-2008
Si tu n'as pas besoin de relations particulières entre ces trois modèles, je te conseillerai de conserver ta table unique et ses 25 colonnes. Créer une relation là où il n'y en a pas, c'est un non-sens.
Concernant ton association joueur/personnage, tu as effectivement une relation hasOne, donc utiliser deux tables est cohérent.
Sephi-Chan
RE: Grosse(s) table(s) - manip - 11-09-2008
Sephi-Chan a écrit :Si tu n'as pas besoin de relations particulières entre ces trois modèles, je te conseillerai de conserver ta table unique et ses 25 colonnes. Créer une relation là où il n'y en a pas, c'est un non-sens.
Niveau performance ça change quelque chose ?
RE: Grosse(s) table(s) - Sephi-Chan - 11-09-2008
Aucune idée. S'il y a une différence, elle est minime (et en faveur de la table unique, je dirais). C'est vraiment une affaire de modélisation.
Toutefois, il faudrait vraiment savoir précisément les champs que tu as et le fonctionnement de ton système, afin de déterminer si oui ou non tu as besoin de relation.
Ne te formalise vraiment pas sur le nombre de champs : 25, ce n'est pas énorme. L'optimisation ne doit — à mon avis — pas conditionner tes choix de modélisation, sous peine d'avoir des bases fragiles quand ton système évoluera.
Sephi-Chan
RE: Grosse(s) table(s) - Anthor - 11-09-2008
Je suis d'accord avec Sephi, 25 champs ce n'est pas vraiment gros.
De même pour la modélisation, elle dépend de tes besoins, l'optimisation doit être fait ensuite, à la récupération et à l'affichage
RE: Grosse(s) table(s) - Cartman34 - 11-09-2008
phenix a écrit :Par soucis de lisibilité et de clarté, je pense que 3 tables c'est le mieux.
Pour moi, il ne faut mettre dans une table les informations d'une seul "chose" et ne pas mélanger les joueurs avec les monstres par exemple.
J'aurais plutôt dit l'inverse pour ces raisons, faire 3 tables est moins lisible.
Cependant, je ne suis aps contre l'idée, il faut faire cela de manière réfléchi.
Si tu charges dans tous les cas, toutes les données ensemble, vaut mieux que ce soit dans la meme requete et sans jointure donc sur la même table.
Si certaines données appartenant à tes différentes tables ne sont pas nécessaires à la même fréquence (certaines sont nécessaires tout le temps, d'autres selon un évènement ou d'autre une fois par jour...), alors il te faut les séparer sur 3 tables pour optimiser ton code.
MAIS ! il faut que tu saches que si tu fais un SELECT * ..., qu'il y est 5 champs ou 20, le temps d'exécution de ta requête est sensiblement proche !
J'ai une table avec 88 champs ! Je ne le ressens pas vraiment dans mes temps d'exécution ! c'est toujours environ 300 millionième de seconde pour une entrée !
Et je m'y retrouve très bien dans tous ces champs, même si je pourrais optimiser cela.
Car pour 215 entrées (toutes celles des joueurs d'IGame), il faut 0.0329 sec.
[...]Après vérification, il faut un temps très proche pour 5 champs...
Je peux conclure que cela ne change rien au temps d'exécution.
RE: Grosse(s) table(s) - manip - 11-09-2008
Merci pour vos réponses vous me rassurez.
Pour le fonctionnement c'est simple j'ai besoin des informations du terrain : location, nom, id, type, superfice, emplacements + des ressources : or, metal, pierre, bois, timestamp + les taux de chaques ressources (4 pour 4 ressources) sur chaque page. Pour ce qui est de la mise à jour, il n'y que les ressources qui sont mise à jour tout le temps. Le nom du terrain change ainsi que les taux de productions seulement si le joueur décider de changer lui même. Idem pour la table joueur, les informations sur le joueur ne changent pas (psuedo, mot de passe, email, ip etc (qui sont dans une table)), il y que l'attaque, la défense, l'attaque / défense bonus, le niveau, l'expérience (qui sont dans une autre table) et la date de connexion qui changent.
Or d'après vous c'est mieux de mettre tout dans la même table et c'est aussi ce que je me disais sans trouver vraiment de justification à mes yeux.
RE: Grosse(s) table(s) - Eluox - 11-09-2008
Moi j'opterais pour plusieurs tables.
Niveau temps d'execution, c'est sensiblement égal je pense, c'est donc a toi de choisir si tu trouve plus lisible plusieurs ou une grosse table,
Moi perso, j'aime plusieurs, IGstaff, une seule, question de point de vue
RE: Grosse(s) table(s) - manip - 11-09-2008
bah ça me semble plus clair avec 3 tables....
Mais sinon quand j'update une table, si elle plus petite ou plus grosse ça change quelque chose niveau vitesse ?