Bonjour,
 
Non ma question ne porte pas sur un simple inner join, mais c'est plus complexe que ça. Le truc, c'est que dans google, je ne sais pas trop quoi chercher, ni ici d'ailleurs.
 
SELECT     AO.NumArticle, AO.NumOption, O.NomTableOption, O.NumIDTableOption
FROM         Article_Option AO INNER JOIN
                      [Option] O ON O.NumOption = AO.NumOption INNER JOIN
                      [O.NomTableOption] OPT ON O.NumIDTableOption = OPT.ID
ORDER BY AO.NumArticle, O.NomTableOption
 
En fait j'ai le nom d'une table qui est un champ d'une table, et je voudrais faire une jointure.
Dans la requete du dessus, le nom de ma table serait contenu dans O.NomTableOption...
 
En gros, j'ai des articles, une liste d'options, et certains articles n'ont droit qu'à certaines options.
Donc mes options j'en ai fait des tables du type OPTION_NomOption qui contient deux champs dedans, ID et Libelle
La table Option (tout court cette fois) contient la liste de toutes les options du site disponible de la forme :  
 
NumOption         NomTableOption     NumIDTableOption
1                       OPTION_Couleur             1
 
etc
 
sachant que dans OPTION_Couleur j'ai
 
ID            Libelle
1             Noir et blanc
2             Couleur
 
Et ma table Article_Option qui donne à mes articles les options auquelles ils ont droit
 
NumArticle     NumOption
1                     1
1                     2
1                    37
2                     1
2                    21
etc
 
Voilà, La requete que j'ai postée en premier me permettrait d'afficher, par article, l'ensemble des options disponibles.
Le truc c'est que le nom de la table d'option, c'est un champ....
 
J'ai essayé des caractères spéciaux pour faire comprendre à SQL server qu'il fallait qu'il me transforme le champ en nom de table, mais j'ai rien trouvé.
 
Si quelqu'un à déjà eu le cas, ça m'arrangerait, ça m'éviterait d'avoir à faire plusieurs requêtes pour arriver au résultat, et de passer par le code.
 
Voilà, merci d'avance

Oulà, tu veux utiliser la valeur d'un champ comme nom de table, c'est bien ça?

 
Tout à fait !

Je sais pas si c'est possible en une seule requête, ça...je passe la main.

 
Ah moi qui croyais que t'avais de suite compris et que t'avais la solution....  
 
Je trouve rien sur google pour l'instant, et je vois pas trop d'autre système pour gérer mes options de façon la plus dynamique possible, et mes articles aussi en dynamique en même temps....
 
Je trouvais mon idée pas trop mauvaise en analyse, mais maintenant que j'en suis à coder tout ça....
 
Bref si quelqu'un à une idée, même une piste de recherche, ça m'aiderait bien.
 
Merci

Niveau analyse, le coup des noms de tables comme champ d'une autre j'ai un doute, perso.

 
Tu verrais ça autrement ? Pour garder le coté dynamique des options, à savoir qu'on peut en rajouter à des articles, etc etc ?

 
Perso je verrais plutôt une table des options avec à la place du nom de la table contenant les valeurs un libellé, éventuellement, et ensuite une table avec toutes les valeurs dispos pour chaque option.

en gros, remplacer ta table option_couleur par une table plus générique en lui rajoutant une colonne contenant l'id_option de ta table option.

en oracle tu pourrais faire une stored procedure qui te retourne tes rows basées sur un sql construit dynamiquement a l'intérieur, ca doit bien être possible en Tsql je suppose.
 
sinon si tu as une couche de programmation au dessus tu peux le faire en deux passes, mais dans ce cas il faut oublier les prepared statement et de nouveau construire ta requete et puis l'executer.

les deux solutions sont effectivement possible. tout comme on peut passer par un execute(statement) et passer par une table temporaire. mais toutes ces solutions sont pourries niveau performances et sécurité.
la solution présentée par skeye est bien mieux, dans la mesure ou le modèle des données devient en plus extensible sans devoir toucher à la structure des tables par la suite (alors que là, il faut toujours créer de nouvelles tables, donc j'appelle pas trop ça un modèle extensible )

Exemple détailé de la notion de modèle dynamique :
http://forum.hardware.fr/hfr/Progr [...] m#t1668734

 
disons que je répondais a la question d'origine qui était est ce que c'est possible.
 
Mon avis personnel est différent, personellement véritablement en production je n'ai jamais vu un modèle dynamique qui ne soit pas une usine a gaz et qui ne finissait pas avec une table gigantesque a 12 milliards de records, conceptuellement c'est très élégant c'est vrai, mais en pratique ca va finir en une table avec tous les types de donnée possible par record et un bordel monstre ou on mélange tout.
en db j'aime ce qui est simple, et a moins que le besoin de l'application soit elle même de pouvoir créer des choses dynamiques j'en resterai aux modèles classiques.

Merci pour vos solutions. Le temps me manquant un peu, je dois rester sur ma solution et avancer, mais je vais y revenir un peu plus tard de toute façon. J'ai pas trop bien compris la solution de skeye, mais il me semble que j'avais eu cette idée la au départ, mais ça posait une contrainte, et je sais plus laquelle....
 
Merci en tout cas !