En fait, si tout tes champs de la table ne demanderont aucune insertion, modification, effacement par les joueurs alors d'accord, tu peut tout mettre dans une et unique table.
Mais il existe des lois, qui existe depuis le fondement du SGBDR et qui sont utilisée depuis , qui tipule: Un Système de table doit être le plus petit possible. Il faut diviser les tables au maximum jusqu'à ce qu'elles ne soient plus possible de les diviser.
La perfection en terme de performance en SGBDR est donc dans la multiplicité des tables.
Bien entendu, on est pas obliger d'arriver a cet extrême
Je vais conseillé, au contraire de ce que j'ai lu, de diviser tes tables. Tu a 3 en têtes, et bien fait en 3. Ca me semble très bien. Mettre 88 champs dans une table comme j'ai lu plus haut est une ennorme erreur si la table est fortement sollicité dans le jeu
Si il est vrais, et je suis totalement d'accord, que le nombre de champ n'influence pas sur le SELECT, il faut savoir que lorsque tu fait autre chose, un UPDATE, un DELETE ou un INSERT, ta table se lock et il faut que le traitement de la demande soit terminer pour qu'une autre demande soit autoriser.
Donc si tu a 20 joueurs en même temps sur ton jeu, que le premier fait une modification dans ta table, celle qui contient aussi la map de ton jeu, les 19 autres doivent attendre que l'UPDATE soit finie pour faire leurs SELECT pour afficher soit la carte (lors de déplacement par exemple) soit pour afficher les caractéristiques du terrain.
Ce qui risque d'être une grande perte de performance pour ton jeu.
A toi de voir.
@+
Mais il existe des lois, qui existe depuis le fondement du SGBDR et qui sont utilisée depuis , qui tipule: Un Système de table doit être le plus petit possible. Il faut diviser les tables au maximum jusqu'à ce qu'elles ne soient plus possible de les diviser.
La perfection en terme de performance en SGBDR est donc dans la multiplicité des tables.
Bien entendu, on est pas obliger d'arriver a cet extrême
Je vais conseillé, au contraire de ce que j'ai lu, de diviser tes tables. Tu a 3 en têtes, et bien fait en 3. Ca me semble très bien. Mettre 88 champs dans une table comme j'ai lu plus haut est une ennorme erreur si la table est fortement sollicité dans le jeu
Si il est vrais, et je suis totalement d'accord, que le nombre de champ n'influence pas sur le SELECT, il faut savoir que lorsque tu fait autre chose, un UPDATE, un DELETE ou un INSERT, ta table se lock et il faut que le traitement de la demande soit terminer pour qu'une autre demande soit autoriser.
Donc si tu a 20 joueurs en même temps sur ton jeu, que le premier fait une modification dans ta table, celle qui contient aussi la map de ton jeu, les 19 autres doivent attendre que l'UPDATE soit finie pour faire leurs SELECT pour afficher soit la carte (lors de déplacement par exemple) soit pour afficher les caractéristiques du terrain.
Ce qui risque d'être une grande perte de performance pour ton jeu.
A toi de voir.
@+