Discussion :

[micouz]

Bonjour,

Je suis actuellement entrain de réaliser une conception de bdd en forme d'arbre.

j'ai lu les articles de sqlpro qui m'ont permis de choisir qu'elle type d'arbre je vais utiliser.

mais maintenant j'ai un petit problème en gros niveau code pure j'ai ça :

une class abstraite "Node" avec des class filles "type1,type2,type3"

donc imaginons j'ai une table Node avec mon arbre dedans et des autres tables type1, type2, type3.Donc je voudrais avec le numero du node récuperer le typeX.

Donc moi j'ai pensé à mettre dans la table node un champ avec le nom du typeX afin de l'identifier puis faire un inner join pour récuperer les données de la tablex.

Donc la question c'est : est-ce que cette façon de faire est bien, vu que l'héritage n'existe pas en mysql ?

deuxième question : est-ce que avec hibernate niveau object cest possible ?

Merci d'avance pour votre aide,
Bonne journée

[StringBuilder]

1/ J'ai pas tout suivi ton truc. En gros, t'as 3 types de feuilles. La feuille ne contient donc que l'information de la position dans l'arbre, et fait référence à une table différente selon le type de feuille, qui contient le détail de la feuille, c'est ça ?
=> Si oui, ça me semble pas mal du tout comme approche.

2/ Si Nhibernate sait pas gérer ça, c'est une très bonne occasion pour laisser tomber ce ramassis de bouse.

[micouz]

Oui c'est à peu prêt ça :
exemple d'arbre
1(type1)
---------------------------
| | |
1:1(type1) 1:2(type2) 1:3(type1)

type1 et type2 sont des tables

dans la tableau avec mes nodes (nom de la table: Node)
id - name - node - id_parent

donc si je veux get le node 1:2 je vais faire une requete qui va recuperer le nom qui sera "type2" puis refaire une requete pour recuperer dans la table type2 les infos concernant ce node.

Mais je vois pas trop comment le faire en une seul requete car il faut que je sache dans qu'elle table je dois chercher la donnée.

Est-ce que cette méthode est bien ? :p

Merci d'avance,
en espérant avoir été clair, c'est pas facile !

[StringBuilder]

Je verrais un truc du genre :

Solution 1 :

node
id
name
node
type1 (int) fk table1.id
type2 (int) fk table2.id
type3 (int) fk table2.id

table1
id
prop1
prop2

table2
id
prop1
etc.

table3
id
etc.

Comme ça tu peux récupérer les infos comme ça :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select node.name, table1.prop1, table1.prop2, table2.prop1, table2.prop2, table3.prop1, table3.prop2
from node
left outer join table1 on table1.id = node.type1
left outer join table2 on table2.id = node.type2
left outer join table3 on table3.id = node.type2
where node.node = '1:2'

Cette requête te permet donc de récupérer les données de la table1, 2 ou 3 selon le type1, type2 ou type3 renseigné.
L'avantage, c'est que ce sera la même requête quel que soit le type de la feuille.
L'inconvénient, c'est qu'il faudra jouter avec des NULL dans la base (si type1 est rempli, alors type2 et type3 doivent être null, à moins qu'une feuille puisse être composite), et dans le résultat de la requête.

Solution 2 :

Une autre solution consiste à stocker un id dans node, sans lien FK vers une autre table, et un champ "type" ou "table", qui permet de déduire dans quelle table aller chercher les informations étendues de la feuille.
Avantage : tu n'as plus de NULL
Inconvénient : tu n'as plus d'intégrité entre les valeurs référencées et l'identifiant de la feuille

Tu peux cependant toujours récupérer les données avec une unique requête, qui contiendra toujours autant de NULL :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
select node.name, table1.prop1, table1.prop2, table2.prop1, table2.prop2, table3.prop1, table3.prop2
from node
left outer join table1 on node.type = 1 and table1.id = node.id_feuille
left outer join table2 on node.type = 2 and table2.id = node.id_feuille
left outer join table3 on node.type = 3 and table3.id = node.id_feuille
where node.node = '1:2'

Il existe certainement d'autres approches, ça c'est ce que je peux te donner en 2 minutes sans trop connaître ton besoin

[micouz]

Merci pour le temps passé,

je pense m'orienter sur la deuxième solution le seul soucis que je rencontre
c'est que les tables ne se ressemblent pas forcement du coup c'est galère de select

[CinePhil]

Tu pourrais expliquer ton cas concret parce que "node" et "type" c'est un peu vague.

Il représente quoi ton arbre ?

Pour le moment, j'ai l'impression que tu mélanges deux choses :
- la structure de l'arbre qui, si j'ai bien compris ton allusion aux articles de SQLPro, est un arbre intervallaire ;
- l'appartenance de chaque élément de l'arbre à un type défini dans un héritage de données.

[StringBuilder]

Tu pourrais expliquer ton cas concret parce que "node" et "type" c'est un peu vague.

Il représente quoi ton arbre ?

Pour le moment, j'ai l'impression que tu mélanges deux choses :
- la structure de l'arbre qui, si j'ai bien compris ton allusion aux articles de SQLPro, est un arbre intervallaire ;
- l'appartenance de chaque élément de l'arbre à un type défini dans un héritage de données.

Je pense par exemple qu'il a une problématique genre un catalogue :

Dans un catalogue, tu as des chapitres, des promotions, des têtes de gondole, des textes, des images, des produits, etc.

Et l'arborescence le type de données n'est pas lié au niveau, et les informations d'une promotion (-20% sur le rayon bricolage) sont parfaitement différentes de celles d'un produit ou d'une tête de gondole.

On peut avoir par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Catalogue1
+- Promotion rayon bricolage (-20% sur toute la famille)
+- Rayon charcuterie
|  +- Tête de gondole
|  |  +- Promotion sur les produits traiteur (-10%)
|  |  +- Produit fromage de tête
|  |  +- Pieds de porc
|  +- Produit saucisse
|  +- Produit jambon
+- Rayon jardinage

On a donc des nodes de type hétérogène (des promotions, des produits, des rayons, etc.)
En revanche, ils doivent bien être hiérarchisés dans une structure arborescente.

J'imagine que son problème est de ce type.

On pourrait aussi avoir la modélisation de l'assemblage d'un produit :
- On a en nodes de dernier niveau des produits "simples" (pièces détachées)
- Dans les nodes intermédiaires, des produits semi-finis ou finis plus de la main d'oeuvre (coût d'assemblage)
- Et dans la node de plus haut niveau, à priori un produit fini

On a donc bien 3 à 4 types de nodes (produit fini, produit semi-fini, pièce détachée, et main d'oeuvres, qui peuvent avoir des attributs spécifiques).

[micouz]

Actuellement mon problème n'est pas l'arbre en lui même mais dans l'organisation des données.

Je vais donner ma bdd que je souhaite dans mon cas précis.

J'ai donc un arbre avec des nodes(tableau node qui respecte la représentation intervallaire).
+id
+id_parent
+nodeName
+type(je l'ai rajouté il me permet de savoir de qu'elle table est ce node, donc ça peut être messagerie,routage,menu)
+lft
+rght

StringBuilder résume plutôt bien, dans mon cas menu, messagerie, routage sont des tables avec des champs bien différents les uns des autres.

donc mon but serait de trouver un système qui me permet avec le nodename par exemple de retrouver le bon champ dans la bonne table.
Je pourrais le faire, mais ça serait deux requêtes(une sur node pour récuperer les infos, puis dans la bonne table pour récupérer les data), j'ai un peu du mal dans la conception de bdd. En dev j'aurais juste fait des interfaces :p.

Merci d'avance,
bonne soirée

[CinePhil]

L'arbre sert à ordonner les données dans une structure hiérarchique. Il ne sert pas à rendre en une seule fois toutes les données de tous les noeuds de l'arbre.

Pour reprendre l'exemple d'arbre donné par StringBuilder, j'imagine bien un tel arbre affiché à l'écran que je déplie jusqu'à trouver la feuille qui m'intéresse, cliquer dessus et alors une requête me ramène toutes les informations dont j'ai besoin sur ce produit qui m'intéresse. Les données des autres produits, pour le moment, je m'en fous.

Si tu as un processus de parcours de l'arbre similaire, le type du node que tu as ajouté te permet de savoir quelle table interroger in fine pour récupérer le produit souhaité.

Par contre, je m'interroge sur l'utilité de id_parent ! Avec un arbre intervallaire, tu n'en as en principe pas besoin.

[micouz]

ok merci beaucoup pour la discussion je vois mieux la philosophie de l'arbre en bdd .

Bonne journée