Grosse(s) table(s) (nouveaux éléments)

[Cartman34]

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.