SQL & requête dynamique

Bonjour,

Je souhaiterai vous solliciter pour m'aider dans ma réflexion ...

Je souhaiterai mettre en place un système de "Requête Dynamique", que j’appellerai dans mon cas un système de "Présentation de données".
Un utilisateur voulant extraire des données de la base dans mon applicatif, pourra faire appel à une présentation (qui porte un nom, un libellé, une description ..) et qui se compose de X colonnes de tables de ma base de données .

Je vois les entités suivantes :

Code:

---

1 2 3 4

#PRESENTATION (ID_P [PK], NAME_P, LIBELLE_P)   #PRESENTATION_COLUMNS (ID_PC [PK], ID_P [FK], COLUMN_NAME, TABLE_NAME)

---

Je pourrais ainsi composer des "Présentations" regroupant des colonnes de tables. Mon seul problème est comment établir les jointures entre plusieurs tables d'une même présentation. J'ai pensé à référencer dans une autre table les FOREIGN_KEY. Mais si deux colonnes de deux tables ne sont pas liées directement, je ne vois pas comment faire.

A votre avis, je dois gérer cela coté applicatif ? Un moyen de mettre en œuvre ce système en SQL ?

Merci de votre attention ...

Cordialement

J'avais fait il y a une dizaine d'années un outil similaire qui se basait sur l'IR pour automatiser la pose des jointures dans l'EDI d'un outil d'extraction de données.

La chose est aujourd'hui plus simple qu'il n'y parait, car vous pouvez utiliser des requêtes récursives pour trouver le "chemin" de jointure entre deux tables.

Il suffit d'interroger conjointement les vues :

Code:

---

1 2 3

SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS SELECT * FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE

---

Pour trouver les jointures à produire entre une table et l'autre

TABLE_CONSTRAINTS => PK/UK et FK
REFERENTIAL_CONSTRAINTS => liens d'IR
KEY_COLUMN_USAGE => colonnes utilisées par les PK_UK et les FK

Le mieux étant de créer une fonction qui prend en argument deux tables (schéma SQL compris) et livre la jointure sous la forme d'une clause FROM toute faite (chaîne de caractères).

Aidez vous de ce que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p7...lcul-de-joint/

A +

Bonjour SQLPro.

Merci pour ta réponse, c'est exactement ce que je souhaite réaliser.

Par contre, j'ai une question, si j'ai trois tables TABLE_A, TABLE_B et TABLE_C
dont les contraintes sont :

Code:

---

1 2 3

TABLE_A (ID_A) TABLE_B (ID_B, ID_A) TABLE_C (ID_C, ID_A, ID_B)

---

Si dans ma présentation je n'ai que des colonnes de la TABLE_A et de la TABLE_C, les deux fonctions fournis ne permettent pas d'établir la jointure entre TABLE_A puis TABLE_B puis TABLE_C, il faut archiver un ordre de sortie dans les tables ?

Merci encore ...

Cordialement

Vous prenez le cas d'une jointure triangulaire... C'est l'exemple qui tue. En effet, vous ne devriez pas avoir ce genre de chose dans une base de données rationnelle, car cela signifie qu'il existe deux chemins différents pour parvenir aux mêmes données. Or cette dualité de chemin pose le problème du bon chemin !!! Si j'ai deux chemins, alors rien n'empêchera jamais de conduire à deux résultats différents..
La présence de ce genre de chose prouve que le modèle de données est faux. Soit par erreur, soit par la redondance qu'il entraîne.
Et dans tous les cas cela conduit à des requêtes impossible à optimiser.
A lire : http://blog.developpez.com/elsuket/p...triangulaires/

A +

Merci pour votre réponse ... J'avance dans ma réflexion ...

Cordialement

Citation:

---

Envoyé par SQLpro

Vous prenez le cas d'une jointure triangulaire...
...
A lire : http://blog.developpez.com/elsuket/p...triangulaires/

---

Bonjour SQLpro, Elsuket, et les autres. Pouvez-vous m'éclairer ?
C'est quoi au juste une jointure triangulaire ? Je ne comprend plus rien !

1) En lisant l'article d'Elsuket, cela semble être simplement une sous-requête corrélée.
Je comprend aisément que cela soit contre-performant, mais pourquoi diable appeler cela jointure triangulaire ?
Et SQLpro, sans son excellent article sur les sous-requêtes, ne nous a pas prévenu de son coté contre-performant.
(si, quand même, dans cet article il nous conseille de chercher une solution alternative quand elle existe)

2) Par contre, de l'intervention de SQLpro dans cette discussion, cela semble être
la possibilité de joindre la table C avec la table A, soit directement, soit en passant par la table B.
Là je comprend mieux l’appellation triangulaire, et le risque d'incohérence que cela induit,
mais je ne voit pas du tout les problèmes de performances ou d'optimisation
(du moins tant que l'on n'utilise qu'un seul des deux chemins dans la même requête).

3) dans cette discussion, il y a une jointure dont un champ est lié a deux tables différentes dans l'arborescence des tables de la requête.
Dans ce cas l'appellation triangulaire est parfaitement adaptée,
l'optimisation semble effectivement assez impossible,
par contre cela ne pose de problème architectural QUE si ce champ qui se retrouve à plusieurs niveaux
est 'hérité' du niveau supérieur, c'est à dire s'il revêt la même signification.

Cela reste tout a fait acceptable dans le cas, par exemple,
d'une contrainte que le pays de livraison soit le même que le pays l'expéditeur ET que le pays de fabrication de l'article :
on a une jointure entre le champ CodePays de la table FabricantArticle, AdresseLivraisonClient et AdresseStockFournisseur.
Il ne s'agit pas du tout de choisir entre plusieurs chemins, car les différents codePays n'ont pas la même signification et ne sont pas redondants.
Un filtrage dans la cause WHERE serai peut-etre plus adapté qu'une jointure, mais elle n'est pas incohérente non plus.