Nil Le 31/03/2017 à 12:18 Hum...
Je cherche la façon la plus efficace de reconstruire un arbre depuis une table de données dans laquelle j'ai un identifiant de noeud, et le numéro du parent (s'il existe) - et j'ai évidemment d'autres informations spécifiques à chaque noeud.
J'étais parti par faire ça avec des requêtes SQL récursives (mes données sont dans une base de données), mais la multiplication des requêtes (mon arbre est assez profond et j'ai des quantités de données de l'ordre du million d'enregistrements) rend la chose extrêmement lente.
J'ai vu qu'il existait la structure WITH ... RECURSIVE en SQL, mais je ne suis pas certain que ça me permette de faire ce que je veux.
Du coup, pour l'instant, j'ai décidé de travailler avec des dumps partiels (pour ne pas prendre trop de mémoire d'un coup, même si ça ne semble pas être problématique de charger mon million de lignes d'un coup) et de faire un traitement par script pour reconstruire mon arbre.
Le souci, c'est que j'en arrive à multiplier les parcours de mon tableau pour reconstruire l'arbre, du coup je n'ai pas l'impression d'être parti dans un système optimal. Donc si quelqu'un connaît un algo générique (ou a déjà utilisé WITH... RECURSIVE et me dit que c'est LA solution).

Nil Le 31/03/2017 à 14:18 Bon, j'ai fait un peu de récursivité, ça a l'air de fonctionner plutôt bien.
Pen^2 Le 31/03/2017 à 14:27 Encore une victoire de canardsouane!
Nil Le 31/03/2017 à 15:32 Pen² > Ouais c'est exactement ce que je fais, en fait. Ca fonctionne très bien sur un petit nombre d'éléments, mais là c'est too much.
Du coup, je pense faire un peu le bourrin, et enregistrer tout en BDD (ce sont des logs assez complexes) uniquement pour consultation en cas de problème (puisque ça ajoute une entrée à quasi chaque événement), par contre pour une consultation classique si le processus est allé jusqu'au bout sans planter, je vais simplement sérialiser mon objet principal (qui contient toutes mes données) à la fin du traitement, et stocker cette donnée dans un fichier.
Pourquoi ne pas recuperer toutes les donnes dans un tableau et generer l'arbre dans le code l'utilisant plutot que faire 150^9000 requetes?
table = "SELECT * FROM TABLE;"
et puis
doit(table, entry)
{
l = table[entry].left;
r = table[entry].right;
if (l) doit(table, l)
if (r) doit(table, r)
faire_quelquechose_avec_le_noeud_en_cours()
}
et paf pasteque

Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Ben c'est pas super complique:
doit(table, entry)
{
current = table[entry]
foreach(child_id, child_count(current))
{
doit(table, current.childs[child_id])
}
faire_quelquechose_avec_le_noeud_en_cours()
}
Et pasteque!

Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.