Une grosse table ou plusieurs avec jointures

[atra27]

Heu, la j'ai un cache session pour chaque user dans sa session.
L'économie c'est surtout que sinon je suis obligé de récuperer tous les champs de la table user a chaque page, ces valeurs ne changement pas souvent mais sont affichées sur toutes les pages (pour la plupart) ou servent dans d'autres traitements donc je dois les récuperer.

Alors vu que sa change pas souvent, une requete sql a chaque page pour des données statiques je trouve sa plutot useless..

Le fichier est utilisé pour les listings généraux, communs a tous le monde (exemple quartier marchant, tribunal)...
Mais je doute que le pseudo, la position ou encore le nom du vaisseau soit commun... d'ou l'utilisation du cache session.
Et vu que derrière il faut utiliser ses valeurs pour traiter certaines actions... bah sa va plus vite en session que d'écrire dans un fichier qu'il faut ensuite parser.

Et puis un fichier sa pose le probléme des fichiers non détruis quand la session correspondante se détruis...

[Anthor]

Heu, la j'ai un cache session pour chaque user dans sa session.
L'économie c'est surtout que sinon je suis obligé de récuperer tous les champs de la table user a chaque page, ces valeurs ne changement pas souvent mais sont affichées sur toutes les pages (pour la plupart) ou servent dans d'autres traitements donc je dois les récuperer.

Alors vu que sa change pas souvent, une requete sql a chaque page pour des données statiques je trouve sa plutot useless..

Super tu économises 1ms à 2ms pour une seule requête ?
Tu as déjà fait du profiling pour dire que c'est useless ?

Le fichier est utilisé pour les listings généraux, communs a tous le monde (exemple quartier marchant, tribunal)...

Si tu as déjà ton architecture, pourquoi ne pas s'en servir ?

Mais je doute que le pseudo, la position ou encore le nom du vaisseau soit commun... d'ou l'utilisation du cache session.

Ha donc en fait tu as un jeu sans aucune interaction entre les personnes ?
Tu économise une requête pour un joueur, mais tu l'a refait autant de fois pour les autres pour afficher quelque chose que tu as "caché" dans un fichier de session.
Je doute fortement, que personne ne voit le pseudo d'un autre ou son emplacement sur une carte...

Et vu que derrière il faut utiliser ses valeurs pour traiter certaines actions... bah sa va plus vite en session que d'écrire dans un fichier qu'il faut ensuite parser.

Et la session tu crois que c'est quoi ?
Tu penses qu'il vaut mieux sérialiser un plus gros tableau ou plusieurs petit ?

Et puis un fichier sa pose le probléme des fichiers non détruis quand la session correspondante se détruis...

Quel intérêt de le détruire si tu le fait uniquement quand tu as un update ?
Et qu'en plus cette information peux servir ailleurs.. (Liste de membres, Classement, Cartes...)

En conclusion, je te le répète, économiser sur une requête qui est indexé et cachée par MySQL, pour utiliser une fichier de session qui doit être désérialiser et resérialiser à chaque page, ça n'a strictement aucun intérêt.
Comme en plus ça doit pas être la seule requête que tu as, tu ne gagnes mais alors vraiment rien.
La session ne sert pas à faire du cache, elle sert juste à transiter des bribes d'informations d'une page à une autre pour pallier les manques du protocole HTTP.

[php_addict]

En conclusion, je te le répète, économiser sur une requête qui est indexé et cachée par MySQL, pour utiliser une fichier de session qui doit être désérialiser et resérialiser à chaque page, ça n'a strictement aucun intérêt.
Comme en plus ça doit pas être la seule requête que tu as, tu ne gagnes mais alors vraiment rien.
La session ne sert pas à faire du cache, elle sert juste à transiter des bribes d'informations d'une page à une autre pour pallier les manques du protocole HTTP.

L'accès aux données des variables de sessions est quand même nettement plus rapide que l'acces des données de la base de donnée...!


Variable de session:
- open
- read
- close
- deserialize

Accès SQL:
- ouverture connexion BDD
- open client
- accept serveur
- authentification
- composer requête
- envoyer requête client
- recevoir requête serveur
- parser requête
- composer arbre d'exécution
- exécution
- open index
- seeks + reads index
- close index
- open heap
- seeks + reads heap
- close heap
- filtres
- composer réponse
- write réponse serveur
- lecture réponse client
- parser réponse client
- close serveur
- close client

[Anthor]

Nul part je dis qu'un cache ne sert à rien.
Je dis qu'il ne sert à rien en session, et sur une seule requête.

Faut pas lire à moitié l'explication ^^

[php_addict]

Nul part je dis qu'un cache ne sert à rien.
Je dis qu'il ne sert à rien en session, et sur une seule requête.

Faut pas lire à moitié l'explication ^^

oups...j'ai cru comprendre que n'utilisais pas de trucs comme $_SESSION['id_joueur']

[Anthor]

oups...j'ai cru comprendre que n'utilisais pas de trucs comme $_SESSION['id_joueur']

La session ne sert pas à faire du cache, elle sert juste à transiter des bribes d'informations d'une page à une autre pour pallier les manques du protocole HTTP.

L'id du joueur en fait partie, mais uniquement cela.

Faire un cache par utilisateur n'a pas de sens, puisque tu ne fais généralement pas une seule requête pour afficher ta page, ce qui fait que ce qui prend du temps (Connexion à la BDD) n'est pas touché, et tu économises uniquement une requête qui prend 2ms.

Je dis simplement que ce genre de cache doit être global, et non en session.

[atra27]

J'ai un variable config pour activer/desactiver ce systeme.
Je testerai les deux donc...

[php_addict]

J'ai un variable config pour activer/desactiver ce systeme.
Je testerai les deux donc...

tiens nous au courant ;-)

[Anthor]

Je pense pas que tu y verras de différence sans ton application globale et des centaines d'utilisateurs en même temps.

[atra27]

Dans tous les cas l'appli est globale vu que le reste du script s'execute que le cache soit utilisé ou non,
la var de config désactive juste la mise en cache et la verrif de la validité.

De toute façon la question est pas primordiale je pense, enfin pour moi c'est dans les questions secondaires étant donné que sa a pas d'impact négatif avéré sur le jeu.

Je testerai juste pour le fun quand même. Sa sentira le déterrage de vieux sujet mais je le note sur ma TODO list... (en espérant que les intéressés soient encore sur ce forum, ou même que ce forum existe encore :p)