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

[berceker united]

Mon problème ne se situ pas du coté SQL. La génération de mon arbo fonctionne. Le tous est géré en objet c'est à dire que l'arbre est présent dans un objet.
Ma question est qu'au final j'ai mon objet entier. Plutôt que de recalculer "qui est le fils de qui" pour reconstruire après le même objet.
Ne serait il pas plus simple de conserver l'objet en le stockant dans une source de données.
Un enregistrement dans une base ou stocké dans un fichier partagé par tous le monde. En gros, émuler une variable de session partagée.

[s.n.a.f.u]

Une table temporaire de type MEMORY n'offre-t-elle pas déjà un gain de performances par rapport à une table ISAM ?
Et dans cette table, il doit être possible de stocker l'objet avec toutes ses données agrégées plutôt que toutes les colonnes à recalculer.

[berceker united]

Une table temporaire de type MEMORY n'offre-t-elle pas déjà un gain de performances par rapport à une table ISAM ?
Et dans cette table, il doit être possible de stocker l'objet avec toutes ses données agrégées plutôt que toutes les colonnes à recalculer.

Ben c'est de cela que je parlais et ce qui m'a été conseillé par Rakken. J'ai ajouté le faite que ça serait une table de type memory mais pas une table de type temporaire.
A partir ou il y a un changement dans la source de données elle génère automatique l'objet qui fera une mise à jour dans cette table.

[s.n.a.f.u]

Autant pour moi, je n'avais pas bien lu ton message.

[Petibidon]

hello,

j'ai un gros doute (parce que je suis une quiche en maths) mais :

100 rubriques avec 100 sous-rubriques sur 100 niveaux... ca donne pas plutot un truc du genre 100^100 ? et du coup un truc légerement ingérable ?

hormis cela... en général tu n'affiches que la descendance directe d'une arbo... c'est peut etre un peu plus simple et plus efficace d'utiliser une base de données qu'un tableau sérialisé (ou un objet on s'en fout) contenant N milliards d'index

[Rakken]

Vu la taille potentielle de tes données, serialiser le tout dans un fichier me semble suicidaire. Tu devrais repenser à l'idée des arbres intervallaire qui ont certes l'inconvénient d'être très lourd pour chaque mise à jour mais aussi (et surtout) l'énorme avantage d'être très rapide en consultation, et dans la mesure ou tu songeait a faire un système de cache, la mise à jour doit être relativement rare et pouvoir se permettre d'attendre un peu.

Si tu te fait une ptite classe bien pensée, tu peux avec ca récuperer l'intégralité des fils d'un noeud donné, à une profondeur donnée, en seulement une requête, (genre : select * from arbre_cat where val_noeud < xx and val_noeud > yy and pronfondeur=yy) donc en terme de perf, j'pense pas que tu puisse faire mieux.
Après en mettant quelques index sur ta table d'arbre, tes perfs devraient rester raisonnable (considérant le volume a traiter)

Ca a aussi l'avantage de ne pas être un système de cache, donc avec des données toujours à jour.

--
Rakken

[berceker united]

Houla alors si le calcul de Petibidon est correcte c'est pas jouable et improbable qu'il y ait une tel utilisation. Je vais reduire le test de volume de telle sorte que je puisse avoir au total 1000 categories.

La requête la plus speed est SELECT [...] FROM categorie ORDER BY parent_id, ordre. En gros car il y a beaucoup d'autre dépendance.
A partir de là j'aurais une methode qui range les noeuds mais cette opération je veux la réaliser la moin possible d'ou l'idée de sérialiser l'objet total.
Dans les exemples que vous avez cité je retourne qu'un segment de l'arbre alors que dans l'apli j'aurais quasiment tous le temps d'avoir acces à l'abre entier.

La modification d'une catégorie seront très rare, du moin je pense (je sais pas ce que va en faire l'utilisateur) mais il y a pas de raison que sa move. Il y a trop d'élement qui en dépende.
Le précessus pour une modification :
- Copie des données pour qi'll y ait aucune incidence sur les données réele
- Modification, suppression ou ajout.
- Contrôle de l'intégrité de l'information par rapport au autre éléments existant
- Soumission à un responsable qui contrôle le tous.
- Si ok il lance le processus de mise à jour sur les tables > génération de l'objet > Mise en cach.

[berceker united]

Après avoir fait de test de performance sur 10 000 catégories sur 100 noeuds.
Les différentes techniques.

1 - Faire un select qui recupère à chaque fois les fils du parents.
Avantage : Les fils sont chargé directement dans la parent, c'est donc déjà rangé.
Inconvéniant : 100 noeud = 100 requêtes.
Temps : 0,8s

2 - Faire un select simple. Les objets se trouve dans un tableau. Je parcours le tableau et les parents cherchent ses enfants.
Avantage : 1 requête quasiment liniaire donc rapide.
Inconvéniant : temps de calcule sur du gros volume.
Temps 0,65s

3 - Même technique que la deuxième sauf que l'objet final est sérialisé et placé dans une table de type memory. J'utilise les methodes spécifiques de php5 telle que :wakup et sleep
Temps 0.65s pour la première étape.
L'acces à l'objet par la suite 0.003s.

[Petibidon]

question bete...

pourquoi tu veux charger tes 10000 catégories dans ton objet ? ne peux tu pas simplement charger les catégories nécessaires à ton script courant ?

perso j'ai beaucoup de mal à comprendre ce que tu veux faire.

[berceker united]

question bete...

pourquoi tu veux charger tes 10000 catégories dans ton objet ? ne peux tu pas simplement charger les catégories nécessaires à ton script courant ?

perso j'ai beaucoup de mal à comprendre ce que tu veux faire.

C'est simplement une phase de test sur le volume.
L'application n'est pas destiné à un client spécifique. Je ne connais pas leur volume d'utilisation donc je fais des test pour que je puisse garantir que l'application est stables jusqu'a x éléments sur n niveaux.
Il y a des cas ou les catégories sont toute chargées.

Dans des projets web, bien souvent nous faisons pas de test sur le volume.
Si nous donnons pas de limite supérieur alors il faut tester le volume. Dans un développement sensible il faut faire ce genre de test. ceci permet de détecter les faiblesses. Des résultats retourné, il faut adapter le code.
Personnellement, je ne vois pas qui pourrait à avoir 10 000 catégories .

[s.n.a.f.u]

C'est vrai que ces tests peuvent être nécessaire si les volumes de données sont susceptibles d'exploser.
Mais ces volumes doivent d'abord être évalués (limite basse, limite haute) pour pouvoir ensuite élaborer un modèle d'accès aux données performant.
Je veux dire par là que c'est plus que de l'adaptation de code, c'est peut-être l'architecture même de la base qui doit être différente en fonction des volumes traités et des priorités de l'appli.
C'est par exemple la différence entre une base de données relationnelles optimisée pour l'intégrité des données et un datawarehouse optimisé pour l'accès à ces même données.

[berceker united]

C'est vrai que ces tests peuvent être nécessaire si les volumes de données sont susceptibles d'exploser.
Mais ces volumes doivent d'abord être évalués (limite basse, limite haute) pour pouvoir ensuite élaborer un modèle d'accès aux données performant.
Je veux dire par là que c'est plus que de l'adaptation de code, c'est peut-être l'architecture même de la base qui doit être différente en fonction des volumes traités et des priorités de l'appli.
C'est par exemple la différence entre une base de données relationnelles optimisée pour l'intégrité des données et un datawarehouse optimisé pour l'accès à ces même données.

Je suis daccord avec toi. C'est pourquoi j'ai testé si avec 10 catégories il avait pas de trop grosse différence. Comme je l'ai précisé, 10k catégories même amazon n'a pas autant. En fait, l'application c'est une boutique en ligne générique.

[s.n.a.f.u]

Ah, le générique...
Quel beau mot, qui n'est supplanté que par l'utopique "universel".
Une bien belle idée, mais si difficile à concrétiser...

Quoi qu'il en soit, il est évident que tu as toutes les cartes en main pour réaliser l'appli, aussi ne puis-je que te souhaiter bonne chance.

PS : si vraiment tu arrive à produiire le script générique pour toute boutique en ligne, je te propose de monter une start-up pour vendre le concept. Disons une association 98% pour toi, 2% pour moi. J'apporterais le café le matin et je m'y retrouverais largement sur le plan financier !

[berceker united]

Ah, le générique...
Quel beau mot, qui n'est supplanté que par l'utopique "universel".
Une bien belle idée, mais si difficile à concrétiser...

Quoi qu'il en soit, il est évident que tu as toutes les cartes en main pour réaliser l'appli, aussi ne puis-je que te souhaiter bonne chance.

PS : si vraiment tu arrive à produiire le script générique pour toute boutique en ligne, je te propose de monter une start-up pour vendre le concept. Disons une association 98% pour toi, 2% pour moi. J'apporterais le café le matin et je m'y retrouverais largement sur le plan financier !

Merci parce que je peux t'avouer que c'est pas simple et comme mon souhait c'est de ne pas pondre une merde donc je pose ce genre de question. Si tu regardes mes postes tu comprendras sur mes question