Petite solution pour alléger le code de certains

[Sephi-Chan]

Quelqu'un pourrait m'expliquer l'intérêt de stocker ça autre part que dans la table qui contient les bâtiments ? Je ne comprends pas pourquoi vous vous emmerdez à vouloir mettre ça ailleurs.

Perso je pars du principe que tout ce qui est stocké en base sont des données qui sont supposées changer plus ou moins fréquemment. Le prix des unités, bâtiments et autres ne répondent pas à ce critère donc pour moi ça n'a rien à faire dans une table.

Par contre, le coup du design pattern est pas mal. Je fais pas vraiment de la POO quand je fais du php donc ce ne sera pas ma solution ici, mais elle a l'air bien sympathique quand même. JE ferais du java, je prendrais probablement une idée dans ce genre.... mais avec les prix stockés en tant que public static final ou réunis dans une autre classe. Pas en base en tout cas, ça sert à rien d'ajouter un select inutile sur toutes les pages.
Le mieux, ce serait de les avoir en mémoire et de les conserver ainsi entre deux requêtes HTTP et indépendamment des sessions, mais bon, faut pas rêver, je vois pas comment c'est faisable en php de manière simple, ou alors j'ai loupé un chapitre.

Dans tous les cas, tu dois sélectionner dans la table… Que tu ramasses les ressources ou non, ça ne change rien.

Enfin, je pense que vous oubliez le rôle d'une base de données : contenir des données et les donner quand on lui demande. De plus, les requêtes de ce type (des SELECT vraiment basiques) sont très rapides puisque très optimisés par MySQL. Bref, ce n'est pas sur ces requêtes là qu'il faut grapiller.

Vous vous compliquez pour rien et manquez de pragmatisme sur ce sujet. M'est avis que vous feriez mieux de passer du temps

Si tu veux faire persister les données pour optimiser encore tout ça, tu peux utiliser Memcached. Ça fait exactement ce que tu indiques : stocker ce que tu veux en RAM (donc de manière distribuée). Ça implique toutefois d'avoir un environnement dédié (puisque Memcached est un serveur qui tourne à côté (Memcached, d comme daemon).

Exemple de pseudocode issu de Wikipedia - Memcached :

function get_foo(int userid){

  result = db_select("SELECT * FROM users WHERE userid = ?", userid);

  return result;

 }



function get_foo(int userid){

  result = memcached_fetch("userrow:" + userid);

    if(!result){

      result = db_select("SELECT * FROM users WHERE userid = ?", userid);

      memcached_add("userrow:" + userid,  result);

    }

  return result;

}

En adaptant ça (très simple) et en le foutant dans une méthode statique find_by_id de ta classe BuildingModel, ça roule et ton ancien code continue de fonctionner au poil. Si tu cesses d'utiliser Memcached, ça continue de fonctionner à merveille.

Et si vraiment tu n'es pas sur un dédié (donc pas de Memcached) ou que ça te fait vraiment chier d'interroger ta base, tu peux toujours mettre en cache les données de la table building_models dans un fichier JSON (ma préférence, car très simple et performant) et le tour est joué. C'est con comme tout à implémenter avec json_encode() et json_decode().

M'enfin avant de penser performances, pensez robuste ! Vous perdrez moins de temps. Si vous avez des modèles de données bien construits, mettre des caches deviens très simple puisqu'il suffit de modifier les accesseurs comme on l'a vu dans le pseudocode donné pour illustrer la manière d'implémenter Memcached.


Sephi-Chan