Nettoyage de base de donnée

[Roworll]

Je préfère faire une requête de 0.000300 secondes plutôt que 30 de 0.000200 secondes...
De plus, je ne sais pas vous mais je n'ai fais que des jeux avec une production, donc il fallait toujours recharger le compte, les construction et ressources (et donc la planète ou la ruche) à chaque page.

Disons que cela dépend évidemment de ton modèle de données.
Mais autant utiliser la puissance des moteurs relationnels et éviter les tables avec une structure du type
joueur_id
planete_id1
planete_id2
planete_id3
etc
(Ceci dit, je ne connais pas ton modèle, je me base juste sur des exemples de modélisation rencontré IRL)

mais il faut savoir qu'une requete sélection tout les champs d'une table pour une entrée sera aussi longue si cette table contient 5 champs que si elle en contient 30...ça tourne souvent autour de 0.000300 secondes(Testé et approuvé sur pma !) et en sélectionnant la configuration + le compte du joueur + la planète du joueur, ca fait environ un millième de sec., ce qui est très faible.

Plus ton recordset devra renvoyer de champs, plus le traffic sera important. C'est pour cela qu'on essaye d'éviter le SELECT * au maximum, afin d'e ne pas récupérer de données parasites et de gaspiller des ressources.
Ensuite, attention à la charge du serveur.
Les systèmes de verrous internes au moteur de base de données utilisé peut amener des problèmes de performances rapidement et en général, c'est exponentiel.
La ou 10 joueurs connectés simultanément verront s'exécuter leur requête en 0.0003 secondes; 100 joueurs frôleront peut être la seconde.
Faire des test en local, tout seul sur son serveur c'est bien. Faire des tests de charge avec accès concurrentiels, c'est mieux (et ça réserve souvent des surprises).

M'enfin, avec les machines actuel, on s'en fou un peu...

Mmm pas vraiment.
Bossant dans un environnement de production avec plein de bases de données dedans, je peux certifier qu'une base développée avec les pieds est capable de foutre à genoux un serveur performant via des opérations simples.

Pensez donc aux index, aux verrous, aux transactions, etc. La base de données n'est pas un élément à traiter à la légère, que ce soit au niveau de la conception ou de l'utilisation.
Je prends un exemple sous SQL Server 2000.
Une page dans ce SGDB fait 8192 octets. 96 octets sont utilisés pour la gestion ce qui laisse 8060 octets par page pour le stockage.

Supposons que vous fassiez une table avec un enregistrement de 4050 octets.
Et bien chaque enregistrement prendra une page a lui tout seul car le SGDB sera incapable d'en mettre deux dans la même page (4050 * 2 = 8100 ce qui est supérieur aux 8060 disponibles par page)
Du coup environ 50% de l'espace sur la table sera réservé mais inutilisé.

Beaucoup de problèmes de performances sur les applications sont imputés à la base de donnée. C'est vrai. Mais 80% de ces problèmes viennent d'une application mal foutue et/ou d'une analyse biaisée.