26-04-2009, 06:48 PM
prendre en compte le temps pour savoir si la requête en cache est toujours valide ou pas c'est bien... mais pour ça n'importe quel système de cache est capable de le faire; pas besoin qu'il soit interne à la classe sql non ? ^^
l'intérêt de coupler un système de cache interne à une classe SQL, c'est principalement dans 2cas (y en a surement d'autres que j'oublie
)
1) un cache pour éviter à chaque requête http, de relancer la même série de requête SQL qui retourne les même résultats (surtout si les requêtes sont lourdes et récurrente alors que les données ne changent que rarement). Comme le souligne zamentur, l'intégrer à la classe SQL ça n'a de sens que si il permet une gestion "intelligente" du cache. (vider le cache lors des inserts, updates correspondant - ce qui est assez complexe si on veut quelque chose de suffisamment fin).
2) un cache pour éviter les requêtes SQL doublon; je l'ai vu sur des système modulaire; ou en fait chaque module est une brique quasiment indépendante. Chaque module fait donc ses requêtes dans son coin comme si il était tout seul; si la requête à déjà été présentée, par un autre module, on lui retourne direct le cache. L'intérêt étant de pas avoir à se préoccuper dans quel ordre les modules sont chargés, de pas avoir à gérer un chargement de données "communes". Tout ça étant géré de manière "transparente" pas ce cache SQL.
---
par contre ton système... je vois pas comment il peut fonctionner (compter le nombre de requête effectuées, et utiliser ce compteur comme id pour tes caches; tu pense pas que tu vas avoir un sérieux problème ?
genre tu vas faire comment quand tu auras plusieurs page/plusieurs module, donc en fonction de la page demandée par le joueur tu n'auras pas le même nombre de requête, et même si le nombre de requête est identique; chaque requête correspondra à une requête SQL différente).
l'intérêt de coupler un système de cache interne à une classe SQL, c'est principalement dans 2cas (y en a surement d'autres que j'oublie
)1) un cache pour éviter à chaque requête http, de relancer la même série de requête SQL qui retourne les même résultats (surtout si les requêtes sont lourdes et récurrente alors que les données ne changent que rarement). Comme le souligne zamentur, l'intégrer à la classe SQL ça n'a de sens que si il permet une gestion "intelligente" du cache. (vider le cache lors des inserts, updates correspondant - ce qui est assez complexe si on veut quelque chose de suffisamment fin).
2) un cache pour éviter les requêtes SQL doublon; je l'ai vu sur des système modulaire; ou en fait chaque module est une brique quasiment indépendante. Chaque module fait donc ses requêtes dans son coin comme si il était tout seul; si la requête à déjà été présentée, par un autre module, on lui retourne direct le cache. L'intérêt étant de pas avoir à se préoccuper dans quel ordre les modules sont chargés, de pas avoir à gérer un chargement de données "communes". Tout ça étant géré de manière "transparente" pas ce cache SQL.
---
par contre ton système... je vois pas comment il peut fonctionner (compter le nombre de requête effectuées, et utiliser ce compteur comme id pour tes caches; tu pense pas que tu vas avoir un sérieux problème ?
genre tu vas faire comment quand tu auras plusieurs page/plusieurs module, donc en fonction de la page demandée par le joueur tu n'auras pas le même nombre de requête, et même si le nombre de requête est identique; chaque requête correspondra à une requête SQL différente).