[Résolu] Structure des tables pour un Ogame-like

[QuentinC]

Pour ma table des évènements, j'ai finalement un peu changé de technique. Je garde le pattern STI par contre, c'est trop puissant ce truc, merci pour l'idée.
Ce que j'ai changé c'est que je ne stocke plus les évènements impliquant deux joueurs dans la table évènements. Comme j'ai de toute façon besoin d'une table armée pour stocker l'équivalent des flottes d'ogame, j'en profite pour y stocker point de départ et d'arrivée.

Donc ma table évènements ressemble à ça maintenant :

Code :

create table Events (
type enum('ResearchEvent', 'RecruitEvent', 'ConstructionEvent') not null,
id int unsigned auto_increment,
player int unsigned not null,
startDate int unsigned not null,
endDate int unsigned not null,
progress float not null,
data text
primary key(id));

Au passage, on peut se servir du mode de récupération PDO::FETCH_CLASSTYPE pour avoir automatiquement un tableau contenant des instances des bonnes classes, qu'il n'y a plus qu'à traiter.
Ce mode semble assez peu connu/utilisé, mais j'ai pu m'apercevoir qu'il était bien pratique...
Contrainte : il faut qu'il y ait une colonne contenant le nom exact de la classe à instancier, et cette colonne doit impérativement être la première (voilà pourquoi je déclare type avant id dans la structure de la table, comme ça select * me renvoie directement tout dans le bon ordre).
Ce pattern est assurément très intéressant.


Par contre j'ai des nouvelles questions, à propos de SQL et d'algorythmique plus que de structure de table cette fois :
- Puisque maintenant je stocke presque tout en base selon vos conseils avisés, le truc c'est que du coup j'ai un nombre énorme de requêtes par page, entre 10 et 15, la plupart du temps avec des jointures simples. Est-ce que c'est trop ? A partir de combien plus ou moins faut-il considérer que c'est trop ? J'essaie déjà de grouper : un seul replace into par table, un seul delete where in(...) par table. Est-ce que je fais erreur ?
LE probllème c'est que dans certains cas je ne peux guère optimiser : par exemple, pour n'avoir la liste que des bâtiments effectivement constructibles, je dois aussi aller piocher dans la table des technologies du joueur, et ça je ne sais pas le faire en une seule requête, il m'en faut trois (liste des bâtiments, listes des technologies, liste des dépendances). Autre cas un peu crétin, je ne sais pas forcément à l'avance de quelles données j'ai besoin, donc il peut arriver que je fasse (je simplifie) select * from table where id = 2 et juste après select * from table where id = 3.

- Et j'ai une autre question algorythmique : pour mes évènements, je ne sais pas trop comment faire pour être efficace. A chaque chargement, devrais-je : 1/mettre tout le monde à jour, 2/mettre toutes les villes du joueur à jour ou 3/mettre seulement la ville actuellement sélectionnée à jour. La première me semble très mauvaise mais peut-être que c'est mieux pour éviter des bugs de requêtes simultanée, sachant qu'une ville peut aussi être mise à jour par un joueur attaquant.