Bonjour,
 
Je vous expose mon souci qui va vous paraître simple (vu mon niveau en SQL ) :
Voilà, j'ai besoin de lister les enregistrements de la table Solution, avec des infos de la table Produit. Jusque là j'ai réussi à faire avec un FULL OUTER JOIN sur ROW_ID.
 

 
La difficulté pour moi est que cette table Produit contient une arborescence sur 2 niveaux : "produit" et "famille de produits", avec la clé étrangère PAR_PROD_INT_ID qui pointe vers la colonne ROW_ID.
 
Je veux tout simplement obtenir toutes les Solutions par famille de produits (c'est-à-dire la famille de produits associée à la solution, le nom du produit ne m'intéresse pas).
 
J'arrive pas à associer deux FULL OUTER JOIN.
Qu'en pensez-vous ?

Après recherches avec d'autres, j'ai trouvé !
 

 
 
La subtilité pour moi était notamment de bien mentionner la 2e table de la jointure tProd2.NAME pour obtenir mon résultat.

Une clé étrangère qui fait référence à la clé primaire de la table à laquelle elle appartient, j'ai jamais vu ça
Pourquoi une telle aberration ?

Pour faire une arborescence comme dit plus haut. J'emploie cette technique régulièrement. Tu le ferais comment toi?

Ben j'aurais créé une table "Famille", et j'aurais défini une clé étrangère dans la table "Produit" qui référence la clé primaire de la table "Famille"

pour le coup de la famille si la classification, c'est "une famille possède 0 ou plusieurs produits" et "un produit appartient à une seule famille", ok pour ta solution. Mais pour modéliser une arborescence "d'objets" de même types, comme tu ferais ta modélisation sans avoir de clé étrangère qui pointe sur la même table?

Ben déjà, qu'appelles tu une arborescence d'objets de même type ? Poste un exemple stp

Ex : une arborescence de titres (comme dans un document Word) :
1 Titre du 1
1.1 Titre du 1.1
1.2 Titre du 1.2
2 Titre du 2
2.1 Titre du 2.1
2.1.1 Titre du 2.1.1
...
Pour faire ça en BD, j'aurais une table ayant la structure suivante :
Table "Titres"
ID (clé primaire)
Libellé  
Ordre
ParentID
 
ParentID pointe sur l'ID du titre parent et Ordre permet d'ordoner les titres d'un même niveau. Dans la table "Titres", avec mon ex, ça donnerait les lignes suivantes :
1   "Titre du 1"       1     NULL
2   "Titre du 1.1"     1      1
3   "Titre du 1.2"     2      1  
4   "Titre du 2"       2     NULL
5   "Titre du 2.1"     1      4
6   "Titre du 2.1.1"   1      5
 
Bien entendu, on n'est pas obligé de rentrer dans l'ordre d'affichage dans la table. Ordre sert justement à remettre le bon ordre d'affichage.

moi j'ai pas de problème avec la structure hiérarchique, par contre j'en ai un avec tes "full outer join".
 
t'es vraiment sûr que t'as besoin du "full outer join" ? un "left outer join" (voir un "inner join" ) ne serait pas amplement suffisant ?
 
ensuite, pour ce qui est des tables hiérérchiques, il faut utiliser l'équivalent de "connect by ... prior" d'oracle pour pouvoir les relire. avec sql server on utilise une syntaxe un peu sioux, et avec mysql... je crois que pour le moment on n'a pas d'autre choix que de faire X auto-jointures à la suite, en limitant de facto le niveau hiérérchique au nombre de jointures de la requête

ah ok, je voyais pas ça comme ça

Je confirme MagicBuzz, pour MySQL, effectivement, c'est pas évident de relire de genre de structure, faut faire plusieurs requêtes.
 
Après, j'avais vu une autre structure de stockage mieux adapté pour Mysql, basée sur les arbres il me semble, mais je me souviens plus trop (je crois que dans le nom de la méthode, y'avait le mot "left" )...

et sinon, pourquoi ne pas stocker l'arbre de ta hiérarchie directement dans la base, et le "déplier" dans le code client ?

je suis pas sûr de comprendre ce que tu me proposes, là

ben tu établis un arbre à partir de ta hiérarchie (pour reprendre ton exemple) :

à partir de là, tu batis un fichier XML en parcourant cet arbre, de manière préfixe (noeud parent, puis noeud enfant gauche et noeud enfant droit) :

tu stockes ce fichier dans ta base, et ensuite tu en fais ce que tu veux. ça t'évite des requêtes compliquées, et c'est largement plus efficace

ah, oui, et quand ces titres ont des relations avec d'autres tables, tu fais comment sans une clé primaire pour chaque titre?
Un ex plus parlant sur lequel j'ai fais bossé MagicBuzz y'a pas loin de 2 ans. J'ai fais un soft de gestion de configurations (confs contenant du logiciel et du matériel). Une conf est constituée de composants, c'est constituants étant composés chacun d'attributs. Les composants sont organisés sous la forme d'une arborescence de composants. Il y a donc bien là une nécessité de lier les composants entre eux pour la partie arbo, lier les composants à la configuration et lier les composants aux attributs. La modélisation en XML n'est pas possible dans ce cas là

Bonjour,
 
Sans chercher à entrer dans le détail, pour la gestion des arborescences, il y a ça :
http://sqlpro.developpez.com/cours/arborescence/

en fait, je crois que c'est de cette méthode dont je parlais précédemment. Merci de l'avoir retrouvée (et donc, rien à voir avec le terme "left" dans le nom)