[MySQL] centralisation de données (?)

Résolu/Fermé
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007 - 20 sept. 2007 à 09:18
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007 - 20 sept. 2007 à 16:59
Je m'excuse pour le titre particulièrement non explicite mais je ne voyais pas vraiment comment nommer ce topic. Je vais essayer d'être plus clair dans mon explication.

Tout d'abord, je précise que je suis développeur Java débutant et que je n'ai pas l'habitude de manipuler des bases de données MySQL autre que des choses très simples à unique but de stockage.

Pour une application je dispose d'un arbre composé d'objet "noeuds" génériques. Objet qui peut se décliner en un certain nombre de "noeuds spécifiques". Mes noeuds possèdent tous un identifiant, ainsi qu'un numéro de noeud père.

Mon arbre se construit donc à partir d'un noeud racine (qui n'aura donc pas de père), chaque noeud possédant un nombre non défini de fils, c'est à dire des noeuds qui possède son identifiants comme numéro de noeud père.
Rien de bien exotique, un arbre quoi.

Pour gérer cela en java, facile, une classe "noeud" abstraite et des classes héritées noeuds spécifiques, une liste de type "noeud", chaque noeud instancié avec le bon type ...

Mon problème viens donc du stockage en MySQL et plus particulièrement dans l'exploitation de la base. Chaque "noeud spécifique" est stocké dans une table spécifique, les noeuds ont donc en commun les fameux id et idpere, le reste des champs étant spécifique.

J'ai besoin d'accéder à tous mes noeuds en une seule requête, notamment pour le parcours de l'arbre, mais sans avoir besoin de connaître le nombre de type de noeud possible. En effet, je cherche à faire un code générique pouvaint s'adapter à un base de données qui évolue (ajout/suppression de type de noeud).

En d'autre terme, je ne veux pas faire un SELECT idnoeud FROM Noeudtype1, Noeudtype2 ....

Je veux que la gestion soit transparente, pouvoir accéder directement à la l'objet dans la bonne table spécifique à partir d'une table "noeud" qui référencerai tout le monde. En gros une table qui représenterai mais liste d'objets "noeud" en java.

ça existe en SQL ? :')

Ou je dois me taper le remplissage de ma table "noeud" à la main en parallèle des tables spécifiques ? (ce qui ne résoudrait même pas tous les problèmes)

merci d'avance pour vos pistes ( et rien que pour avoir lu ça jusqu'au bout ...)

7 réponses

vignemail1 Messages postés 1246 Date d'inscription vendredi 8 octobre 2004 Statut Contributeur Dernière intervention 13 septembre 2019 259
20 sept. 2007 à 09:39
table noeud:
========
id            int     auto_increment, clé primaire
id_pere   int
.....


où .... sont les éventuels valeurs du noeud

après en java tu fait une fonction de recherche d'un noeud dans un noeud racine en fonction de son id
et une autre avec recherche sur id_père

et là c'est tout simple, le noeud racine de tous aura id=-1 ou 0
ensuite tu parcours la liste des noeuds construit à partir du retour du SELECT et tu cherches ceux avec l'id_père -1 ou 0
et tu fais cela en récursif. Dès que tu ajoutes un fils à l'arbre, tu lances la fonction en récursif pour lui chercher tous ses fils et les ajouter.

Sinon y a plus simple pour stocker ton arbre, tu stocke en XML avec la librairie java JDOM
0
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007
20 sept. 2007 à 10:12
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.
0
vignemail1 Messages postés 1246 Date d'inscription vendredi 8 octobre 2004 Statut Contributeur Dernière intervention 13 septembre 2019 259
20 sept. 2007 à 10:28
Donc tu veux avoir une table pour chaque noeud et une table pour stocker l'arborescence ?
0
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007
20 sept. 2007 à 10:40
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.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
vignemail1 Messages postés 1246 Date d'inscription vendredi 8 octobre 2004 Statut Contributeur Dernière intervention 13 septembre 2019 259
20 sept. 2007 à 10:59
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 ?
0
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007
20 sept. 2007 à 11:24
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)
0
eracius Messages postés 12 Date d'inscription mercredi 19 septembre 2007 Statut Membre Dernière intervention 26 septembre 2007
20 sept. 2007 à 16:59
Pour infos, j'ai trouvé ce que je voulais faire.

C'est de l'héritage conditionnel.

Voir ce lien https://sqlpro.developpez.com/cours/modelisation/heritage/ pour plus d'infos.

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