26-05-2009, 02:04 AM
@Argorate: Le problème ici c'est que si je fais le traitement dans le code, je vais me taper des boucles assez conséquentes en raison des spécificités de chaque ligne.
Dans le sens où pattern me donne le type de l'unité, mais sword peut correspondre à un orc, un humain, etc. (ce qui fait que je ne peux pas rassembler mes résultats vu que les caractéristiques changent en fonction de la faction). Enfin en gros, faire le traitement derrière c'est accroitre mon champ de travail.
Et d'ailleurs c'est une solution qui montre rapidement ses limites si je dois par exemple recalculer toute la puissance de tous les joueurs du jeu. C'est assez difficile à expliquer, mais disons que chaque joueur peut avoir 20 types d'unités, j'ai 700 joueurs sans pub, ça me fait directement 1400 champs, donc 1400 requêtes (impossible de faire des jointures en update), ce qui est quand même conséquent. Alors qu'en utilisant cette technique de condition (dont la lisibilité est limité, ça c'est clair), j'ai qu'une seule requête à faire et c'est dans la poche.
Mais c'est vraiment du à la spécificité du jeu et à sa complexité (et richesse) technique.
Le truc c'est que j'aimerais éviter de multiplier les endroits où se trouvent une même information (ici en l'occurrence dans un fichier sérialisé).
J'ai deux ou trois requêtes "gigantesques" de ce type sur tout le site, donc c'est plutôt ponctuel.
Je suis par contre très intéressé par la première solution. J'avais déjà entendu parler des procédures mais sans vraiment m'y attarder. Je vais voir ce que ça donne ^^
Dans le sens où pattern me donne le type de l'unité, mais sword peut correspondre à un orc, un humain, etc. (ce qui fait que je ne peux pas rassembler mes résultats vu que les caractéristiques changent en fonction de la faction). Enfin en gros, faire le traitement derrière c'est accroitre mon champ de travail.
Et d'ailleurs c'est une solution qui montre rapidement ses limites si je dois par exemple recalculer toute la puissance de tous les joueurs du jeu. C'est assez difficile à expliquer, mais disons que chaque joueur peut avoir 20 types d'unités, j'ai 700 joueurs sans pub, ça me fait directement 1400 champs, donc 1400 requêtes (impossible de faire des jointures en update), ce qui est quand même conséquent. Alors qu'en utilisant cette technique de condition (dont la lisibilité est limité, ça c'est clair), j'ai qu'une seule requête à faire et c'est dans la poche.
Mais c'est vraiment du à la spécificité du jeu et à sa complexité (et richesse) technique.
(26-05-2009, 12:19 AM)Allwise a écrit : Pour les grosses requêtes, ou les requêtes qui nécessitent de faire des traitements, les procédures stockées sont une bonne solution. Elles te permettent de délocaliser le traitement dans une fonction mysql en gros, et tu appelles ces fonctions comme tu ferais n'importe quelle requête.Ouep, j'avais déjà eu cette idée là qui est assez facile à mettre en place.
Tu gagneras ainsi en visibilité.
Sinon, je ne connais pas ton modèle de données, mais tu peux aussi plancher sur des optimisations qui te permettraient de te passer de toutes ces conditions. Par exemple là, la donnée que tu calcules semble dépendre de 2 facteurs : pattern et nation. On pourrait envisager une table "bastion_force" ( si c'est bien la force, mais peu importe ) avec dedans les champs pattern, nation, et force.
Pour chaque couple pattern & nation, tu as une force. Tu pourrais donc remplacer toutes ces conditions par une simple multiplication.
Le truc c'est que j'aimerais éviter de multiplier les endroits où se trouvent une même information (ici en l'occurrence dans un fichier sérialisé).
J'ai deux ou trois requêtes "gigantesques" de ce type sur tout le site, donc c'est plutôt ponctuel.
Je suis par contre très intéressé par la première solution. J'avais déjà entendu parler des procédures mais sans vraiment m'y attarder. Je vais voir ce que ça donne ^^