Table noeud:
========

id            int     auto_increment, clé primaire
id_pere   int
.....

Merci pour ta réponse, néanmoins mon problème ne se trouve pas dans la construction de l'arbre à partir de la bdd, ça je savais le faire et j'avais opté pour cette solution, à savoir une table en dur récapitulant tous mes noeuds avant de m'apercevoir d'un problème.

Je suppose que cette réponse vient du fait du manque d'explication plus globale, je reprend donc.

Pourquoi je veux construire cet arbre. En fait, j'ai besoin de connaître tous les noeuds dépendant directement ou indirectement d'un noeud donné. Donc j'ai besoin de connaître tous les noeuds composant l'arbre d'un noeud racine (ce noeud racine étant le paramètre de ma fonction)

Je construit donc mon arbre en récupérant les données de ma bdd, ce qui me donne la liste complète de mes noeuds.

Si j'utilise une table "noeud" contenant une référence (c'est à dire l'idnoeud) de tous les noeuds, stockés chacun dans la table spécifique à leur type, aucun problème.

MAIS une fois que j'ai récupéré cette liste de noeud, j'ai besoin d'exploiter les données contenues dans les tables spécifiques. Je dois donc pour chaque noeud refaire un SELECT * FROM noeudtypeX WHERE idnoeud = idnoeudtypeX

Ce qui m'oblige donc à connaître les types existants dans mon code, ce que je veux éviter.

Ce que je voudrais savoir, c'est s'il existe une fonction SQL permettant de lier d'une façon ou d'une autre, et de façon transparente, ma table "noeud" et toutes les tables de type noeud spécifique.
En gros, je voudrais qu'en faisant SELECT * FROM noeud WHERE idneoud = idnoeudtypeX, SQL sache qu'il doit aller chercher, non pas dans la table noeud, mais dans la table noeudtypeX.

Au début,je pensais que les FOREIGN KEY servaient à ça, mais je me trompais complètement.

J'espère avoir été plus clair.
Merci encore pour votre aide.

Donc tu veux avoir une table pour chaque noeud et une table pour stocker l'arborescence ?

Une table pour chaque type de noeud, ça je ne peux pas l'éviter, chacun ayant des données différentes.

Après, je ne veux pas réellement stocker une arborescence car d'une part je n'ai pas qu'un seul arbre, j'en ai un certain nombre et d'autre part la profondeur de la racine dont je veux connaître les fils n'est pas toujours la même.

Ce que je veux, c'est récupérer tous les noeuds "en dessous" d'un noeud donnée et ce par l'intermédiaire de la donnée noeuds père.

Donc une table contenant tous les noeuds me permet cela, c'est une solution. Elle m'évite de devoir faire un SELECT idnoeud FROM noeudType1, noeudType2 ....

Mais elle pose problème après, quand je dois exploiter la liste des noeuds obtenus et récupérer les données spécifiques pour chaque noeud, contenu dans les tables spécifiques.
Je veux réussir à écrire un code générique pour ne pas avoir besoin de connaître le nombre de types de noeuds

Donc géré par SQL le lien entre mes tables noeudTypeX et ma liste totale de noeud qui peut être contenu dans une table "noeud" avec un lien vers chacune des table spécifique. Ou bien une autre forme qui ne nécessite pas de table physique mais crée un lien d'une façon ou d'une autre ... façon justement que je ne connais pas.

J'espère avoir été clair :')
Merci.

Donc tu pourrais pas te satisfaire d'une table
noeuds:
=====
id_noeud int auto_increment, clé_primaire
id_pere int
in_arbre int


et d'une table
champs_noeuds:
==========
id_noeud int
nom_champ varchar(100)
valeur_champ varchar(100)

à priori ?

tu pourrais donner un exemple de champs dans tes noeudTypeX car là c'est peut-être un peu trop abstrait comme conception ?

Mes noeuds sont en fait des éléments d'un réseau.
Chaque élément possède un module communicant permettant de dialoguer avec les autres. C'est un réseau mesh (ou maillé).

J'ai donc besoin d'un système de gestion générique car mes noeuds peuvent potentiellement dialoguer avec n'importe quel autre noeud.

ça c'est mon système générique.

Après pour le système spécifique auquelle j'applique mon réseau mesh, j'ai quatre niveaux de profondeur, donc 4 types de noeud possédant chacun des attributs complètement différents (hormis idnoeud et idpere) et qui établissent donc le fameux arbre (la hiérarchie étant toujours la même : un noeudType1 sera toujorus racine, un noeudType2 toujours fils de la racine etc ..).

Je connais donc mon nombre actuel de NoeudTypeX mais je voudrais éviter de développer du code statique au cas ou on me demanderait une évolution future (ajout de type, changement dans la hiérarchie de mes noeuds ...)

Je ne peux pas détailler plus, le projet étant confidentiel.

J'espère que ces quelques éléments supplémentaires peuvent aider.

************

Concernant ta proposition, j'avoue que je ne vois pas bien ou tu veux en venir avec la table champs noeud. Pourrais tu développer un peu ton idée ?

merci :)

************

Sinon, je pense avoir trouvé une solution, ajouter dans ma table "noeud" un champs "type". Ce champs me permettant de connaître dynamiquement le nom de la table spécifique sur laquelle je dois faire le SELECT pour un noeud donné. Et ainsi préserver la généricité de mon code.

Pour reprendre la forme des réponses précédentes, ça donne ça

table noeud (contenant une entrée pour tous les noeuds du réseau)
=======
idnoeud
idpere
type

type étant égal au nom d'une table NoeudTypeX.

table NoeudTypeX
===========
idnoeud
attribut 1
attribut 2 ....

Avec autant de table NoeudTypeX que nécessaire.

Mais par curiosité, j'aimerai quand même savoir s'il existe une solution spécifique SQL pour ce que j'expliquais précédement. Cela pourrait certainement amener un gain de performance et peut être même éviter la table noeud (qui crée des doublons en terme de stockage)

Pour infos, j'ai trouvé ce que je voulais faire.

C'est de l'héritage conditionnel.

Voir ce lien http://sql.developpez.com/modelisation/heritage/ pour plus d'infos.

J'avais donc trouvé une des deux solutions tout seul ^^