Forums PostgreSQL.fr

scfi

Membre

Arbre sql de définition / data

Bonjour,

Je reviens vers vous pour étoffer mes connaissances et mon appli.

J'ai une fonction récursive qui me dessine l'arbre de l'application. Pour se faire j'ai une table qui rassemble toutes les classes (à chaque classe correspond une table, Ex : la classe adresse et la table t_adresse).
Pas de souci, l'arbre est ok. Par exemple :
Noeud adresse qui possède deux feuilles : code postal et département.

Maintenant question simple , comment lier cet arbre (construit avec les classes) aux données ? Exemple concret : Comment retrouver le code postal et le département de mon adresse d'id 20, à partir de cet arbre ?

Évidemment il n'y a aucune clé étrangère dans l'application.

Merci d'avance,

gleu

Administrateur

Re : Arbre sql de définition / data

La question est beaucoup trop vague pour pouvoir fournir une quelconque réponse.

---

Guillaume.

scfi

Membre

Re : Arbre sql de définition / data

Oui c'est assez compliqué à expliquer. Avec plus de détail :

Ma fonction récursive m'affiche l'arbre de toute l'application. Exemple :
La classe adresse est lié à la classe code postal : adresse/codepostal (en partant du nœud adresse). Comprendre "adresse a un code postal"
La classe adresse est lié à la classe département : adresse/departement(en partant du nœud adresse). Comprendre "adresse a un département"

Les classes sont renseignées dans une table (ce qui me permet de faire ma récursivité). Toutes les classes renseignées dans cette table correspondent à une table (Ex : la classe adresse correspond à la table t_adresse, la classe codepostal à la table t_codepostal... Etc.).

Ce qui me bloque, c'est savoir maintenant comment lier cet arbre aux données (je sais qu'une adresse à un code postal, mais savoir quelle adresse à quel code postal).

flo

Membre

Re : Arbre sql de définition / data

J'ai du mal à saisir si vous avez déjà créé vos tables (t_adresse, t_codepostal, etc...), et si votre problème est que vous ne savez pas concevoir votre base, ou que vous ne savez pas écrire les requêtes pour l'utiliser?
Si j'ai bien compris, votre problème est d'ailleurs vaste (trop vaste). Vous cherchez à résoudre le problème général du mapping entité - relationnel, pour lequel il n'y a pas une bonne solution. Il y a par contre des solutions, avec chacune leurs inconvénients et avantages.

Dites-nous en plus!

Évidemment il n'y a aucune clé étrangère dans l'application.

Là je ne comprends pas. Qu'est-ce que cela a d'évident? Une base sans clé étrangère, ce n'est pas une base, c'est un tas de trucs. Où peut-être vous demandez-vous comment les placer?

scfi

Membre

Re : Arbre sql de définition / data

Non du tout . Il n'y a aucune clé étrangère (c'est la première fois que je suis confronté à ce genre de chose). Le principe est de gagner énormément en performance car il n'y a aucune jointure quand on interroge la bdd.

La base (modele+requête arbre) nous a été fournit. Donc la base est déjà conçue. J'avais déjà au fournisseur demandé pour les clés (car jamais vu auparavant), et c'est bien confirmé. C'est le principe de l'arbre SQL.

flo

Membre

Re : Arbre sql de définition / data

Tu pourrais alors nous donner la définition de quelques tables, qu'on comprenne ton problème?

Marc Cousin

Membre

Re : Arbre sql de définition / data

Non du tout . Il n'y a aucune clé étrangère (c'est la première fois que je suis confronté à ce genre de chose). Le principe est de gagner énormément en performance car il n'y a aucune jointure quand on interroge la bdd.

Si j'ai bien compris, vu qu'on a une table qui pointe vers elle même afin de créer l'arbre, on a des jointures : de la table vers elle même. Donc prétendre qu'on gagne en performance parce qu'il n'y a «aucune jointure» relève de la fumisterie: non seulement on a des jointures (la table vers elle même, 200 fois si nécessaire si on a 200 niveaux de profondeur), mais on n'a aucun moyen de valider la cohérence des données entre elles, le moteur n'a aucun moyen de prédire ce que va lui donner une requête, et donc choisir des plans d'exécution intelligents.

Bref, effectivement, merci de répondre à la question de flo, afin qu'on puisse aider. On pourra certainement fournir une requête qui retourne les données. Quant à ce que ce soit performant, par contre, il ne faut probablement pas trop rêver avec ce genre de «schéma». La récupération d'une entrée le sera raisonnablement, mais si l'arbre devient très grand, il se pourrait que cela devienne très lent.

---

Marc.