devenu un fan (à tiques) de la représentation intervallaire, je me
demande s'il n'y a pas un moyen simple de retrouver le chemin d'accès à
un noeud ou une feuille.
dans mon arbre j'ai :
l'id, le niveau dans l'arborescence et le parent_id
pour le noeud "root" j'ai choisi : id = parent_id (càd 0 avec hsqldb)
PB : tous les grands crus d'Alsace commencent par Alsace, si un utilisateur fait une recherche sur "Alsace" (il n'est pas obligé de connaître le découpage en régions et sous-régions) j'aimerais lui ramener tout l'arbre sous Alsace en tant que région comprenant toutes les sous-régions où il y a au moins d'une solution et bien sûr les solutions.
Autre intérêt de trouver toutes ces solutions, le select where peut porter sur autre chose que le nom de l'appellation : - couleur du vin par ex ; - nature du sol certainement plus intéressant oenologiquement parlant.
Là je ne vois qu'une solution en trois étapes : - sélectionner toutes les feuilles solutions (sql) ; - pour chaque feuille solution remonter le "path" racine-feuille (sql) ; - parcourir l'arbre pour visualiser les "paths" sans doublons (java).
-- yt
Fred BROUARD - SQLpro <brouardf@club-internet.fr> wrote:
SELECT *
FROM MATABLE
WHERE BG <= :BG_Feuille AND BD >= DB_Feuille
ORDER BY NIVEAU
Oui, merci, la question se pose quand il y a plus d'une solution, car
mes BG_feuille et BD_feuille je les obtiens par un select.
PB : tous les grands crus d'Alsace commencent par Alsace, si un
utilisateur fait une recherche sur "Alsace" (il n'est pas obligé de
connaître le découpage en régions et sous-régions) j'aimerais lui
ramener tout l'arbre sous Alsace en tant que région comprenant toutes
les sous-régions où il y a au moins d'une solution et bien sûr les
solutions.
Autre intérêt de trouver toutes ces solutions, le select where peut
porter sur autre chose que le nom de l'appellation :
- couleur du vin par ex ;
- nature du sol certainement plus intéressant oenologiquement parlant.
Là je ne vois qu'une solution en trois étapes :
- sélectionner toutes les feuilles solutions (sql) ;
- pour chaque feuille solution remonter le "path" racine-feuille (sql) ;
- parcourir l'arbre pour visualiser les "paths" sans doublons (java).
PB : tous les grands crus d'Alsace commencent par Alsace, si un utilisateur fait une recherche sur "Alsace" (il n'est pas obligé de connaître le découpage en régions et sous-régions) j'aimerais lui ramener tout l'arbre sous Alsace en tant que région comprenant toutes les sous-régions où il y a au moins d'une solution et bien sûr les solutions.
Autre intérêt de trouver toutes ces solutions, le select where peut porter sur autre chose que le nom de l'appellation : - couleur du vin par ex ; - nature du sol certainement plus intéressant oenologiquement parlant.
Là je ne vois qu'une solution en trois étapes : - sélectionner toutes les feuilles solutions (sql) ; - pour chaque feuille solution remonter le "path" racine-feuille (sql) ; - parcourir l'arbre pour visualiser les "paths" sans doublons (java).
-- yt
Etienne SOBOLE
"Fred BROUARD - SQLpro" a écrit dans le message de news: 415c4675$0$15747$
plutôt :
SELECT * FROM MATABLE WHERE BG <= :BG_Feuille AND BD >= DB_Feuille ORDER BY NIVEAU
A +
Ouarf. Je connais pas moi ca. Fred, y a quelque part sur ton site ou ca parle de cette syntaxe??? Ca marche sur tout les SGBD?
merci Etienne
"Fred BROUARD - SQLpro" <brouardf@club-internet.fr> a écrit dans le message
de news: 415c4675$0$15747$7a628cd7@news.club-internet.fr...
plutôt :
SELECT *
FROM MATABLE
WHERE BG <= :BG_Feuille AND BD >= DB_Feuille
ORDER BY NIVEAU
A +
Ouarf.
Je connais pas moi ca.
Fred, y a quelque part sur ton site ou ca parle de cette syntaxe???
Ca marche sur tout les SGBD?
Par contre il y a un coquille, il manque un ":" avant DB_Feuille...
C'est plutôt BD_Feuille non ? (coquille)
mais que signfie le ":" ??? -- yt
Ph. B.
Yvon Thoraval wrote:
Ph. B. wrote:
Par contre il y a un coquille, il manque un ":" avant DB_Feuille...
C'est plutôt BD_Feuille non ? (coquille)
mais que signfie le ":" ???
le ":" précède tout paramètre que tu passes à ta requête avant de l'exécuter. Dans le cas présent le paramètre pourrait tout à fait être nommé DB_Feuille bien que pour la cohérence de l'ensemble BD_Feuille soit préférable...
-- Philippe.
Yvon Thoraval wrote:
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
Par contre il y a un coquille, il manque un ":" avant DB_Feuille...
C'est plutôt BD_Feuille non ? (coquille)
mais que signfie le ":" ???
le ":" précède tout paramètre que tu passes à ta requête avant de l'exécuter.
Dans le cas présent le paramètre pourrait tout à fait être nommé DB_Feuille bien
que pour la cohérence de l'ensemble BD_Feuille soit préférable...
Par contre il y a un coquille, il manque un ":" avant DB_Feuille...
C'est plutôt BD_Feuille non ? (coquille)
mais que signfie le ":" ???
le ":" précède tout paramètre que tu passes à ta requête avant de l'exécuter. Dans le cas présent le paramètre pourrait tout à fait être nommé DB_Feuille bien que pour la cohérence de l'ensemble BD_Feuille soit préférable...
-- Philippe.
yvon.thoravalNO-SPAM
Ph. B. wrote:
le ":" précède tout paramètre que tu passes à ta requête avant de l'exécuter.
c'est du sql ça ? lequel ? est-ce l'équivalent du "?" des preparedStatement() ???
-- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
le ":" précède tout paramètre que tu passes à ta requête avant de l'exécuter.
c'est du sql ça ? lequel ?
est-ce l'équivalent du "?" des preparedStatement() ???