Discussion :

[berceker united]

Bonjour,
J'ai besoin d'avis de spécialiste un peut
Voila, dans mon application j'ai des objets qui seront souvent utilisé. Dans mon cas "Catégorie". Il y a beaucoup d'objet qui tourne autour de ça.
Pour des raisons de gestion de ressource SQL. Je ne souhaite charger tous le temps la même information pour chaque utilisateur. Donc j'ai pensé à un truc.
Comme dans le J2EE il est possible de lever des objets dont il puise ses informations dans une base de données.
Ceci signifie qu'il se connecte une fois à la base. De plus les session peuve être public. C'est à dire qu'elle peuve être partagé par tous le monde. En php ces deux élément n'existe pas en natif mais peuve être simulé.
- Il est possible de sérialisé un objet.
- Il est possible de créer un fichier pour enregistrer le contenu de l'objet.
De là, il est donc possible de lire directement le contenu du fichier est de déserialiser le contenu.

Les avantages : Les requêtes, traitement souvent repété sont déjà rangé dans un objet une fois. L'opération est faite que si le fichier n'hexiste pas.

Inconvénient : Lecture de fichier qui peut être plus long qu'une requête. Donc il faut se dire que nous ne pouvons pas tous placer dans le fichier surtout si cela ne sert à rien.


En résumé : Emulez les objets partagés sans devoir faire le traitement pour chaque client, page. De plus l'information n'est dupliqué sur chaque session. 1 Session = 1 multiplié par le nombre de client = fichier sur le serveur. La c'est X client multiplié par 1.

bonne idée ou pas ?

[Rakken]

Pour ce que j'en sais, une lecture en base est plus rapide que la lecture d'un fichier (quoique sur de petits volumes j'ai un doute, un bench ne serait pas une mauvaise idée).
Par contre, j'imagine que tu peux te creer une table "cache" qui contient ton objet serializé.

Pour ce qui est des temps de traitement... faut que tu te fasse des benchmarks pour savoir, parce qu'en fonction de la maniere dont est créé ton objet (par exemple, il est chargé a partir d'une table ? deux ? vingts ? Il y a beaucoup de calcul de fait dans ton objet ?) et sa taille le choix de la méthode varie.

En gros, il faut que tu connaisse le temps de "création" pure de ton objet avec requetes en base et tout et tout. Et il faut que tu connaisses le temps de "récupération" d'un objet (lecture en base/lecture de fichier + temps de déserialization).

Et que le meilleur gagne ^_^

Il faut également avoir en tête que se creer un cache, c'est devoir le gèrer correctement pour les mises a jour, c'est souvent du boulot en plus, faut être sur que le gain en vaut la chandelle.

Pour finir, a vu de nez, je dirais que tu n'y gagneras probablement pas énormement en terme de performance (voir pas du tout), sauf si ton objet est vraiment complexe, mais avec un nom comme "catégorie", c'est peu probable ;-))

--
Rakken

[berceker united]

Pour ce que j'en sais, une lecture en base est plus rapide que la lecture d'un fichier (quoique sur de petits volumes j'ai un doute, un bench ne serait pas une mauvaise idée).
Par contre, j'imagine que tu peux te creer une table "cache" qui contient ton objet serializé.

Pour ce qui est des temps de traitement... faut que tu te fasse des benchmarks pour savoir, parce qu'en fonction de la maniere dont est créé ton objet (par exemple, il est chargé a partir d'une table ? deux ? vingts ? Il y a beaucoup de calcul de fait dans ton objet ?) et sa taille le choix de la méthode varie.

En gros, il faut que tu connaisse le temps de "création" pure de ton objet avec requetes en base et tout et tout. Et il faut que tu connaisses le temps de "récupération" d'un objet (lecture en base/lecture de fichier + temps de déserialization).

Et que le meilleur gagne ^_^

Il faut également avoir en tête que se creer un cache, c'est devoir le gèrer correctement pour les mises a jour, c'est souvent du boulot en plus, faut être sur que le gain en vaut la chandelle.

Pour finir, a vu de nez, je dirais que tu n'y gagneras probablement pas énormement en terme de performance (voir pas du tout), sauf si ton objet est vraiment complexe, mais avec un nom comme "catégorie", c'est peu probable ;-))

--
Rakken

Ces question je me l'étais posé car en effet ça depend de l'usage. Je pense surtout par exemple au nombre de catégorie que possede amazon. Pour t'expliquer le cas des catégorie.

Une catégorie à des sous catégorie et chaque sous catégorie peut en avoir encore. Bref il y a pas de limite. C'est un systeme hierarchique donc un objet posse une collection d'autre objet de même type. Deux solutions :
- Soit je créé une requête pour récupérer tous les fils donc une requête à chaque noeud. L'avantage : c'est déjà rangé. Inconvéniant : 1000 noeud = 1000 requêtes.
- Faire une requête qui récpère toute les catégories et je les ranges via une methode. Avantage : Les ressource db sont largement light. Inconvéniant : Le temps de calcule peut augmenter selon le nombre.

Ma contrainte est qu'il faut que ça soit fluide jusqu'a :
100 catégories. Chaque catégorie à 100 sous catégorie. A une profondeur de 100 niveaux. Je sais pas si le calcule est bon. 100x100x100 = 1 000 000 catégories. Je ne connais pas l'utilisation finale donc les tests de performance ça sera la marge à indiquer.

J'ai pris "catégorie" comme exemple mais il y a d'autre élements qui seront calculés.

Effectivement, je peux utiliser un cash db optimisé pour la lecture pure en memory qui sera plus bien plus rapide.

[mathieu]

en ce qui concerne la gestion d'une arborescence à plusieurs niveaux, tu peux optimiser la lecture de la base de données grace à la structure suivante :
http://sqlpro.developpez.com/cours/arborescence/

[berceker united]

J'avais lu cette article intéressant au début. Problème c'est que ceci fonctionne sur une table stable static dont les id son dans l'ordre croissant.
Mon problème c'est que dans mon application les fils peuvent changer de parent. Là ça change tous.

[mathieu]

J'avais lu cette article intéressant au début. Problème c'est que ceci fonctionne sur une table stable static dont les id son dans l'ordre croissant.
Mon problème c'est que dans mon application les fils peuvent changer de parent. Là ça change tous.

à toi de faire les alogrithmes pour calculer les nouvelles positions en cas de déplacement. dans l'article tu as déjà les algoroithmes expliqués pour l'ajout ou la suppression d'éléments