IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

SQL & requête dynamique


Sujet :

MS SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé Avatar de JmL40
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    348
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 348
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre éclairé Avatar de JmL40
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    348
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 348
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre éclairé Avatar de JmL40
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    348
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 348
    Par défaut
    Merci pour votre réponse ... J'avance dans ma réflexion ...

    Cordialement

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 3
    Dernier message: 04/08/2008, 15h35
  2. Réponses: 1
    Dernier message: 01/08/2008, 17h25
  3. [PL/SQL] Requête dynamique
    Par Ridculle dans le forum PostgreSQL
    Réponses: 0
    Dernier message: 25/02/2008, 11h56
  4. Requête SQL avec groupement dynamique
    Par driou1 dans le forum Langage SQL
    Réponses: 4
    Dernier message: 01/02/2007, 18h31
  5. [pb requête sql] Requête dynamique
    Par viny dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 15/09/2005, 12h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo