Discussion :

[Stopher]

Bonjour à tous,

Je cherche actuellement le meilleur moyen pour gérer une structure de données sous forme d'arbre "(d'id")

les id représentent en fait des catégories et sous catégories .

Auriez-vous des pistes à me suggérer ?

Merci d'avance ,

Ch.

[wiztricks]

Salut,
Pourquoi ne pas partir d'un pattern "composite" ou d'un dict de dict?
- W

[rambc]

Bonjour.

Attention aux arbres. Pourquoi ? Cette structure théorique peut avoir différentes implémentations et quelques fois il est plus simple d'utiliser des listes de listes, ou des dictionnaires de listes ou de dictionnaires, ou de passer par du XML... etc., que de vouloir implémenter une classe générique Tree en Python. Je me suis déjà fait avoir à ce petit jeu.

Le plus simple serait d'avoir une description précise du type d'arbre à manipuler.

[Stopher]

Salut,
Pourquoi ne pas partir d'un pattern "composite" ou d'un dict de dict?
- W

Je ne connais pas ce pattern, ça semble être effectivement une solution que je garde sous le coude.

Bonjour.

Attention aux arbres. Pourquoi ? Cette structure théorique peut avoir différentes implémentations et quelques fois il est plus simple d'utiliser des listes de listes, ou des dictionnaires de listes ou de dictionnaires, ou de passer par du XML... etc., que de vouloir implémenter une classe générique Tree en Python. Je me suis déjà fait avoir à ce petit jeu.

Le plus simple serait d'avoir une description précise du type d'arbre à manipuler.

En fait jusque là j'ai trouvé deux solutions, la premiére, le module ete2 qui semble répondre à ce genre de problématique.
La seconde, un dict de dict sérialisé avec cPickle ou json pour le coté sauvegarde, seul hic ( enfin c'est un petit hic ) est que lorsque je souhaite me "balader" / "modifier" un noeud de mon arbre, cela va me demander des "for in" à gogo , ne serait ce que pour localiser mon noeud, et ça ne me plait pas trop, je cherche une solution plus éfficace.

Pour ce qui est de la structure, c'est ni plus ni moins qu'un arbre d'id chaque id représente un enregistrement en base , afin que je récupère d'autres infos.

[mont29]

Dans ce cas, pourquoi pas un simple dict {id: (parent, [child, ...])} (parent et child étant du même type qu’id)*? De cette façon, on a accès à tous les nœuds directement par leur id, et de façon “arborescente” en suivant les chaînes de parentées, le tout avec une structure de données plane…

Enfin, c’est juste une idée, à vous de voir.

[Stopher]

Trés bonne idée .. je ne sais pas pourquoi dans ma tête je ne voyais pas autre chose qu'une structure "arbre".

Comme quoi une idée peut en cacher d'autres .. bien meilleurs

Merci ,

je pense partir sur cette idée qui devrait répondre à mes besoins .

Je et ce sujet en RESOLU cependant si d'autres personnes ont des suggestions, je suis bien évidemment toujours preneur .

Bonne soirée,

Ch.

[wiztricks]

Salut,

Si votre soucis est côté "persistance" jetez un œil à HDF.
Après tout dépend de la taille et de la profondeur.
Vous avez des solutions côté SGDB avec nested set.
Mais le module shelves peut aussi très bien faire l'affaire.
Vous pouvez aussi stocker du JSON dans un cluster Hadoop.

Côté programmation, c'est toujours le "pattern composite".
Persistance et choix d'un "backend" pour stocker des millions de nœuds, garder en mémoire qu'un s/ensemble de... accéder rapidement aux nœuds relèvent d'une architecture technique, la "programmation" vient après.

- W

[Stopher]

Merci pour ces informations sur le sujet .

Je travaille actuellement sur une base MongoDB, qui offre aussi une representation nested set

http://docs.mongodb.org/manual/tutor...ee-structures/

Des approches qui semblent intéressantes bien que mon besoin ne requiert pas une telle infra pour ce point.

"4 arbres d'une profondeur de 20 niveaux environ"

Mais je vais explorer ces point malgré tout, ne serait-ce que par curiosité ( et qui peut le plus, peut le moins )

Merci encore .

Ch.