JeuWeb - Crée ton jeu par navigateur
Grosse(s) table(s) (nouveaux éléments) - Version imprimable

+- 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)

Pages : 1 2 3 4


RE: Grosse(s) table(s) - manip - 13-09-2008

Bon je vais me renseiger sur la vue mysql ....

Sinon si j'ai compris la meilleur solution reste a mettre les informations du terrain et le taux dans la même table et mette les ressources dans une autre table car les ressources seront plus fréquement mise à jour que le reste. Ainsi j'aurais une table plus petite a update, et si l'update des ressources merde, jaurais quand même les informations sur le terrain car elles seront dans une table.

Pareil, avec les informations sur le joueur dans une table (psuedo, mot de pass, ip) et son profil de joueur (xp, lvl, hp etc) dans une autre table qui sera mise à jour plus souvent.

Sinon question timestamp perso j'ai essayer de stocker avec INT et datetime, mais je prefere quand faire avec int et récuperer le nombre avec date ainsi je peux tirer séparant les informations que je veux comme je veux (la date complète ou juste l'heure).


RE: Grosse(s) table(s) - manip - 14-09-2008

Hummm

Je viens de voir la base de donnée d'un clône d'ogame... Il y a une vingtaine de tables dont certaines ont plus de 50 champs.... Me voilà rassurer.


Par contre la façon de stocker les données n'est pas la même.
Sur la copie, il y a une table "planets" ou tous les batiments, défenses et vaisseaux sont stockés dedans (on se retrouve avec une table énorme). Chacun à un champ qui vaut 0 quand on s'inscrit, exemple : b_hangar not null 0.

Or moi pour mon jeu je stocke mes soldats dans une table appart comme ceci (ça avait été conseillé dans je sais plus quel sujet) :
id
soldat nom
id joueur
id terrain
Avantages : si le joueur est inactif je n'ai pas d'enregistrement, sinon je dois avant d'insert, vérifier si le soldat existe deja pour faire un update.

Que pensez-vous de ces deux méthodes ?


RE: Grosse(s) table(s) (nouveaux éléments) - Kassak - 14-09-2008

J'en pense que c'est au programmeur de choisir la solution qui lui convient.

Moi pour un autre projet que je suis en train de faire, j'ai opté pour la solution de tout rentrer en BDD lors de l'inscription du joueur, quitte à avoir des champs valant 0, donc des données inutiles.

Mais en contre partie, plus de vérification pour savoir si j'update ou j'insert (donc moins de requête et moins de conditions à chaque fois.)