rapidité de recherche sur plusieur table et index

[xorax]

bonjour,

je souhaite créer une structure similaire à la façon dont sont organisé repertoire-fichier et y stocké dans des base sql

je prend un exemple simple :

je cherche a allez au point de l'arborescence "/cat 1/souscat 2/txt 3"

je vais stocké dans un table ENTREE les donnée associé à "cat 1", "souscat 2" et "txt 3" à savoir

id, title, message

ici :

1, "cat 1", "letextedecat 1"

2, "souscat 2", "letextedesouscat 2"

3, "txt 3", "letextedetxt 3"

dans une autre table nommé CONNECT je ferais la correspondance entre l'identifiants et ses enfant afin de pouvoir mettre plusieur sous entree dans une entree :

id, idchild

ici :

1, 2

2, 3

seulement il va falloir que je créé une autre table CONNECT car je ne veux pas passé les id dans l'url et je ne veux pas qu'il y est de caractère échapé (%20..) dans l'url.

donc pour allé au point "/cat 1/souscat 2/txt 3" mon url sera par exemple "/cat-1/souscat-2/txt-3"

et la table qui permettra d'assicié les titre d'url au id sera du genre :

id, urltitle

donc ici :

1, "cat-1"

2, "souscat-2"

3, "txt-3"

seulement si il peu éxister un autre point comme "/cat 1/txt 3" qui n'aura pa le même contenu que "/cat 1/souscat 2/txt 3" donc, pour aller à "/cat 1/souscat 2/txt 3", je dois partir de "/cat 1", lister les entré contenu, puis trouver "souscat 2", lister et enfin trouver "txt 3" ce qui me semble assez lourd...

une autre façon serait d'enregstrer les chemins entier dans la tables CONNECT, cela donnerai :

1, "cat-1"

2, "cat-1/souscat-2"

3, "cat-1/souscat-2/txt-3"

mais dans 40 % des cas je devrais lister les entrées apartenant aux entrées parentes.

donc en optant pour cette dernière solution j'utiliserais la recherche de texte en faisant LIKE "cat-1/souscat-2/*" mais il me semble que la aussi ça n'est pas très optimisé...

en partant sur cette optique je peux modifié la table connect :

"1", "cat-1"

"1/2", "cat-1/souscat-2"

"1/2/3", "cat-1/souscat-2/txt-3"

cela me semble être la meilleurs solutions mais ça implique que je sois obligé de faire plusieur requete sql car il me semble que parser "1/2/3" pour faire resortir les id va être assez dur non?

bref j'aimerais votre avis la dessus

Merci!

[dièse]

Bonjour,

Je n'ai pas vraiment le courage de me plonger dans ton post . Mais je peux tout de même essayer de te donner quelques pistes. Une structure arborescente peut très bien être modélisée avec une seule table et le travail sur les chaînes de catactères peut être fait avec ton langage de programmation ( peut-être PHP ), ou même avec des fonctions SQL ( dans ton exemple SUBSTRING() devrait faire l'affaire), mais pas à l'aide d'une table dédiée.

Bon courage

[xorax]

oui désolé je voulait faire simple mais ça ne l'es pas vraiment... merci pour la réponse

Le travail avec arborescence sur une seul table est possible et même très performant grace à cet algo : http://sql.developpez.com/arborescence/

mais si l'on cherche à créé des "doublons" (? ex: un post dans plusieurs catégories, comme wordpress) une autre table doit obligatoirement être créer à mon avis.

[Portekoi]

Non tu peux dupliquer en changeant l'ID parent.

Mais dans ce cas, ce n'est pas cette structure qu'il te faudra car tu vas avoir pas mal de redondance...

[robinsonvendredi]

J'ai développé une gestion de nomenclatures de produit avec un algorithme similaire.

Justement sa force est de pouvoir réutiliser un sous arbre pour plusieurs parents sans avoir d'enregistrement redondant dans la base.

Pour l'interface, je te conseille vivement un treeview en ajax ce qui permet de charger seulement les noeud enfants au fur et à mesure de la recherche, d'où une simplification de l'algorithme de présentation et un gain de performance très important sur une grosse table.

[xorax]

je comptais bien installé un treeview c'est pour ça que je me demande si c'est très optimisé...

sachant que pour un chemin donné il devra listé tout les noeuds enfant de chaque noeuds du chemin, ça me semble gros non?

si il y a en moyenne 6 noeuds par chemins, chaque noeuds contenant 6 noeuds...

ça fait du 6 requète et 36 enregistrement retourné

il y a surement moyen de mettre tout en 1 requete mais je suis pas une masse en sql

ça me poserais pas de problème si je n'avais que ça à effectuer mais derrière j'ai quasiment le même shéma pour des droits d'accès... et j'ai peur que ce soit un peu lourd.

[robinsonvendredi]

je comptais bien installé un treeview c'est pour ça que je me demande si c'est très optimisé...

Tu peux pas faire plus optimisé !

L'algo SQL ci-dessus est utilisé par les grands éditeurs d'ERP depuis très longtemps pour les nomenclatures de production.

En revanche si tu fais du SQL "classique" tu auras bcp de problème dans la réalisation de ce module : par exemple répercuter les changements faits dans un noeud enfant sur tous ses parents.

Si tu le développes en procédures stockées c'est encore mieux pour les performances.

Un treeview en ajax te permet de ne charger que les noeuds immédiatement inférieurs à chaque clic et non pas l'ensemble de l'arbre enfant : donc tu n'auras pas plus d'une fraction de seconde à attendre après chaque clic pour voir se développer ton arborescence.

[xorax]

ok merci

effectivement je viens de faire des test sur un millier enregistrement c'est très rapide !

merci encore!