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

[QuentinC]

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

Oui, à moins que je trouve une meilleure solution.
A chaque chargement de page, il faut que je mette à jour les ressources, que je vérifie s'il y a des évènements à traiter ou des armées qui rentrent ou attaquent...
Chaque table est mise à jour en deux requêtes au plus : suppression sous forme de delete from table where id in(...) et mise à jour / insertion des nouvelles lignes sous la forme replace into (même syntaxe qu'un insert multiple).
Un évènement terminé est supprimé, et si un évènement n'est pas terminé, son pourcentage d'avancement est mis à jour. Je suis conscient que le pourcentage d'avancement et la date de fin font quelque part un peu doublon, mais étant donné qu'on peut changer la vitesse d'avancement et donc la date de fin dans certains cas, je ne vois pas comment faire autrement que de stocker les deux.
Si tu as mieux à proposer, je suis preneur.

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.

Oui, indexées qui de plus est, enfin sauf dans un cas : la sélection des armées.... parce que je ne sais pas comment indexer efficacement (je ne vois pas quoi/comment indexer pour un listing des armées dans un rayon proches en coordonnées)
Question bête : est-ce que le cache SQL et l'indexation fonctionne de manière performante aussi quand on fait select * from where colonne in(...) ?

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.

Ah... je ne me suis pas encore penché sur de la mise en cache. Ca se fait plutôt à la fin du développement ça normalement, non ? Dans ce as j'ai encore le temps d'y penser.
Mais quand tu parles de mise en cache, à quoi tu penses exactement ? Cache SQL, cache dans un fichier, cache APC ? Autre chose ?

[Anthor]

Effectivement, pourcentage inutile, c'est le genre de chose que tu calcule avec le début et la fin au moment voulu.

[QuentinC]

Effectivement, pourcentage inutile, c'est le genre de chose que tu calcule avec le début et la fin au moment voulu.

Si la vitesse est constante tout au long du parcours, en effet je suis d'accord. Mais si tu avais la possibilité de changer la vitesse de ta flotte en cours de voyage, ce ne serait pas trivial à calculer.
La date d'arrivée est modifié à chaque fois que tu réajustes la vitesse, mais pas le pourcentage d'avancement !

[Anthor]

Effectivement, pourcentage inutile, c'est le genre de chose que tu calcule avec le début et la fin au moment voulu.

Si la vitesse est constante tout au long du parcours, en effet je suis d'accord. Mais si tu avais la possibilité de changer la vitesse de ta flotte en cours de voyage, ce ne serait pas trivial à calculer.
La date d'arrivée est modifié à chaque fois que tu réajustes la vitesse, mais pas le pourcentage d'avancement !

Comment calcules tu ton pourcentage d'avancement ?

[QuentinC]

Comment calcules tu ton pourcentage d'avancement ?

Je vais prendre un exemple.
Disons qu'une flotte décolle au temps t=0, à une vitesse de 100%, et arrive à destination au temps t=20 si sa vitesse est constante durant la totalité du voyage.
J'affiche la page au temps t=12. Le pourcentage d'avancement est logiquement calculé 100 * 12 / 20 = 60%, tout va bien.
Je change la vitesse de la flotte à 40% au lieu de 100%
L'atterrissage aura lieu à t= (12 + (20 -12) / 0.4) = 32 et non plus à t=20.
Si on est un peu naïf, on calculera l'avancement faux en faisant 100 * 12 / 32 = 37.5%. Or la flotte n'a en réalité pas reculé, elle est toujours à 60% du trajet.
Si je réaffiche la page à t=22, le pourcentage d'avancement sera de 60 + (100 -60) * (22 -12) / (32 -12) = 80% (et non pas 68.75%)
Je décide me mettre ma flotte en pause. Dans l'espace ça n'a aucun intérêt, mais chez moi ça peut se justifier. Le pourcentage d'avancement reste à 80%, mais n'avance plus si je réactualise tant que je ne l'ai pas redémarrée.

Je n'ai pas envie d'enregistrer un historique des changements de vitesse. Premièrement c'est lent, et deuxièmement je suis à peu près sûr que ça ne sert à rien.
Donc je tiens le pourcentage d'avancement à jour...

[Anthor]

Je n'ai pas envie d'enregistrer un historique des changements de vitesse. Premièrement c'est lent, et deuxièmement je suis à peu près sûr que ça ne sert à rien.
Donc je tiens le pourcentage d'avancement à jour...

Ça se tient ^^ Et ce n'est pas ça qui va changer tes performances

[QuentinC]

Ça se tient
Et ce n'est pas ça qui va changer tes performances

En réalité si. Avec un tel historique, je ne suis pas obligé de mettre à jour les évènements à chaque affichage de page. Donc finalement c'était une bonne idée quand même.
Ca se résume à troquer de la fréquence de mise à jour par de l'occupation disque. Vu que les sauvegardes sont ultra-lentes par rapport à la simple lecture, j'y gagne énormément en fait. Je commence à comprendre pourquoi persone ne propose cette fonction : c'est trop compliqué.

J'en ai accessoirement profité pour ne pas mettre à jour les villes qui n'ont pas subi d'évènement, car s'il n'y a pas eu d'évènement, alors il n'y a que les ressources qui sont censés être à jour et elles peuvent être calculées linéairement.
Total, j'ai maintenant entre 5 et 8 requêtes obligatoires par page minimum, ça monte à 10-15 seulement s'il y a des évènements à traiter.

J'ai une nouvelle question de SQL : est-ce que ça vous paraît une bonne idée pour une table contenant 10 colonnes d'avoir 3 index en plus de la clé primaire , ou bien est-ce un mauvais réflexe de vouloir indexer chaque colonne régulièrement utilisée dans la clause where ?

[Anthor]

De l'occupation disque, faut pas charrier, tu as un champs data, te suffit de rajouter dans ce tableau, la liste des vitesses, quelques nombres vont pas remplir à ce point ^^

[QuentinC]

De l'occupation disque, faut pas charrier, tu as un champs data, te suffit de rajouter dans ce tableau, la liste des vitesses, quelques nombres vont pas remplir à ce point

Effectivement. C'était pour dire que c'était négligeable par rapport à une sauvegarde plus fréquente.

Quelqu'un pour répondre à ma dernière question sur les index ?

[Anthor]

Quelqu'un pour répondre à ma dernière question sur les index ?

Je pense que la réponse dépendra de celui qui te répondra, ensuite, tout dépend des fréquences d'appels, et de pleins d'autres paramètres.
3 index personnellement, ça ne me choque pas plus que ça.