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

[QuentinC]

Merci, je vais regarder ça.

[Anthor]

@Anthor > tiens, bizarre, le plus long c'est encore le connect si on ne tient pas compte des describe qui ne servent de toute façon à rien en prod

C'est un fait connu, dès lors qu'on a mis un peu de profiling.
Effectivement, le DESCRIBE n'existe pas en Prod, mais le profiling non plus ^^
En prod, il est caché, pour fonctionner avec l'ORM, la ça permet de voir aussi les temps.

Ça démontre surtout que bosser un objet pour une ligne, et pas forcement plus long que de sélectionner chacun des champs quand on en a besoin, Que de toute manière, faut quand même un bon nombre de requêtes pour rentabiliser une connexion

[Sephi-Chan]

T'inquiète Ter Rowan, je le prends pas mal.

Je te rejoins sur le fait que la structure à adopter dépend du gameplay/utilisation. D'ailleurs, si tu relis mes messages, tu verras que je préconise l'utilisation d'une simple colonne numérique quand on n'a pas besoin d'une gestion fine de chaque ressource.

Et concernant les sources de données, ça n'est pas contre la variété que je milite (mes traductions de texte statiques sont stockées dans des fichiers YAML, alors que j'utilise la base de données pour quasiment toutes les autres données), c'est contre l'utilisation de plusieurs sources pour une même ressource dans l'objectif de faire des économies de bout de chandelles.

Je tenais tout de même à clarifier ça. :p


Sephi-Chan

[QuentinC]

Séphi-Chan, ton pattern STI, c'est spécifique à ruby ? parce que je ne trouve pas grand chose en-dehors de ruby et surtout pas en php, et encore moins en français.
Pourtant, PDO a déjà tout prévu... je sens que ça va être vraiment pratique ce truc.

[Anthor]

Séphi-Chan, ton pattern STI, c'est spécifique à ruby ?

Non, Doctrine le fait ( http://www.doctrine-project.org/document...nheritance )

[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.

[Anthor]

- 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.

Le plus simple serait d'avoir une classe spécifique traitant les événements d'une ville. Ainsi tu peux traiter les événements avant un nouvel événement impliquant la ville, ou alors simplement, lorsque nécessaire, en stockant sur la ligne de la ville, la date du prochain event. Ça devrait te faire économiser quelques requêtes.

Comment peut-tu avoir 15 requêtes ? Même sur ma page bâtiment, j'ai 2 requêtes sans aucune jointure.

[QuentinC]

Comment peut-tu avoir 15 requêtes ? Même sur ma page bâtiment, j'ai 2 requêtes sans aucune jointure.

Argh mais comment fais-tu pour n'en avoir que 2 ?

Voilà en gros résumé mes requêtes :
1. Récup joueur courant
2. Récup empire courant
3. Récup liste des villes de l'empire
4. Récup liste des évènements
5. Récup liste des armées
6. MAJ liste des évènements
7. MAJ liste des armées
8. MAJ liste des villes
9. Récup liste des bâtiments existants
10. Récup liste des technologies de l'empire
11. Récup liste des dépendances

Il suffit qu'il y ait encore 2 ou 3 évènements à traiter et je passe facilement au-dessus de 15.

[Sephi-Chan]

Les requêtes de MAJ sont-elles systématiques ?

Je vois que tu as pas mal de requête type "SELECT * FROM table WHERE column = n" qui sont très performantes et facilement mises en cache par le SGBDR. Donc à ce niveau là, ça n'est pas grave.

Il y a également des choses facile à mettre en cache (la liste des bâtiments existants et leurs dépendances, par exemple), mais ça vient une fois le système en place.

Je pense que dans un jeu, avoir une dizaine de requêtes par page n'est pas un problème. Ensuite, les processus de traitements peuvent souvent être plus gourmands. Tant que ça reste de la sélection selon une colonne indexée, c'est bidon.

N'oublions pas qu'une base est faîte pour être interrogée et comme le disait très justement Anthor récemment : il faut bien rentabiliser la connexion à la base (longue et incompressible (CMB !)).


Sephi-Chan

[Anthor]

Bon que tu montes avec la liste des événements, ce n'est pas grave du tout, au contraire vaux mieux en faire plus à la mise à jour qu'aux sélections car tu en as beaucoup moins.

Comme l'a dit Sephi, les select * c'est bidon, en profilage, ton serveur te dira qu'il peux facilement atteindre 3000/4000 requêtes par secondes.

Comment peut-tu avoir 15 requêtes ? Même sur ma page bâtiment, j'ai 2 requêtes sans aucune jointure.

Argh mais comment fais-tu pour n'en avoir que 2 ?

Voilà en gros résumé mes requêtes :
1. Récup joueur courant
2. Récup empire courant
3. Récup liste des villes de l'empire
4. Récup liste des évènements
5. Récup liste des armées
6. MAJ liste des évènements
7. MAJ liste des armées
8. MAJ liste des villes
9. Récup liste des bâtiments existants
10. Récup liste des technologies de l'empire
11. Récup liste des dépendances

Je n'ai que la 1 et la 2, les autres sont optionnelles. Les 9/10/11 sont inexistantes car stockées dans un adaptateur et les classes dépendantes.
De 4 à 8, uniquement, si 2 renvoi une date passée pour le nextUpdate, ou si demandé par un autre joueur pour lancer un événement, ou par soi-même d'ailleurs.

Après j'utilise un maximum les patterns disponibles, donc je ne vois pas forcement les choses de la même manière, m'enfin c'est vrai que 15 requêtes ne me choque pas du tout. Dès lors qu'on passe sur de l'applicatif, c'est tout à fait normal.