[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
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
A voir également:
- [MySQL] centralisation de données (?)
- Fuite données maif - Guide
- Supprimer les données de navigation - Guide
- Mysql community server - Télécharger - Bases de données
- Trier des données excel - Guide
- Reinstaller windows sans perte de données - Guide
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
20 sept. 2007 à 09:39
table noeud:
========
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
========
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
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
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.
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.
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
20 sept. 2007 à 10:28
Donc tu veux avoir une table pour chaque noeud et une table pour stocker l'arborescence ?
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
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.
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.
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
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 ?
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 ?
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
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)
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)
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
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 ^^
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 ^^