Union de requêtes et indicateur

Version imprimable

Bonjour tout le monde,

Je cherche à faire un truc un peu bizarre.
Basiquement j'ai une table avec les colonnes " ID, Ressource1, Ressource2"

Je cherche à récupérer une vue de la forme:
ID Ressource1
ID Ressource2
...
et ce pour chaque ID de ma table (Sachant que les champs de ressources peuvent être nulls). J'ai donc fait un truc dans le genre
Code:

1 2 3 4 Select ID, R.Ressource from MaTable, MatableRessource R where R.Ressource=Ressource1 and Ressource1 is not null Union Select ID, R.Ressource from MaTable, MatableRessource R where R.Ressource=Ressource2 and Ressource2 is not null
ça marche bien sauf que dans mon traitement suivant je voudrais savoir si ma ligne de résultat correspond à la première ou la deuxième requête. Donc avoir un champ avec "1" ou "2" par exemple.
C'est surement pas si compliqué que ça mais je bloque

Citation:

Envoyé par Towandaa

C'est surement pas si compliqué que ça mais je bloque

En effet :

Code:

1
2
3
Select 1 as source, ID, R.Ressource from MaTable, MatableRessource R where R.Ressource=Ressource1 and Ressource1 is not null
Union
Select 2 as source, ID, R.Ressource from MaTable, MatableRessource R where R.Ressource=Ressource2 and Ressource2 is not null

Edit : Et avec des jointures normalisées, c'est plus joli ;)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Select  1 as source
    ,   T.ID
    ,   R.Ressource 
from    MaTable T
    inner join
        MatableRessource R 
        ON R.Ressource = T.Ressource1 
where   T.Ressource1 is not null
Union
Select  2 as source
    ,   T.ID
    ,   R.Ressource 
from    MaTable T
    inner join
        MatableRessource R 
        ON R.Ressource = T.Ressource2 
where   T.Ressource2 is not null

06/02/2015, 14h19
Towandaa

Ah comme prévu c'était tout con c'est le petit coup du "1 as source" qui me manquait :oops:!

Merci!:mrgreen:

Le iner join apporte-t-il qqch à part la "jolitude" de la requête?
06/02/2015, 14h52
al1_24

L'utilisation de la forme normalisée des requêtes offre plusieurs avantages :
- Elle permet de séparer les conditions de jointures des restrictions
- On peut être certain de ne pas avoir oublié une condition de jointure si la requête fait appel à de nombreuses tables et ainsi éviter un produit cartésien
- Il est aisé de transformer une jointure stricte en jointure externe
- Avec des SGBD dont l'optimiseur est paresseux, les jointures sont bien mises en évidence pour lui simplifier le travail
- Elle est conseillée depuis plus 20 ans (1992) par le comité de normalisation du langage SQL et prise en charge par la majorité des SGBDR
09/02/2015, 17h20
Towandaa

Citation:

Envoyé par al1_24

L'utilisation de la forme normalisée des requêtes offre plusieurs avantages :
- Elle permet de séparer les conditions de jointures des restrictions
- On peut être certain de ne pas avoir oublié une condition de jointure si la requête fait appel à de nombreuses tables et ainsi éviter un produit cartésien
- Il est aisé de transformer une jointure stricte en jointure externe
- Avec des SGBD dont l'optimiseur est paresseux, les jointures sont bien mises en évidence pour lui simplifier le travail
- Elle est conseillée depuis plus 20 ans (1992) par le comité de normalisation du langage SQL et prise en charge par la majorité des SGBDR

Ok merci je vais essayer de m'y efforcer dès à présent alors ^^
10/02/2015, 10h06
mnitu

Citation:

Envoyé par al1_24

L'utilisation de la forme normalisée des requêtes offre plusieurs avantages :
- Elle permet de séparer les conditions de jointures des restrictions
- On peut être certain de ne pas avoir oublié une condition de jointure si la requête fait appel à de nombreuses tables et ainsi éviter un produit cartésien
- Il est aisé de transformer une jointure stricte en jointure externe
- Avec des SGBD dont l'optimiseur est paresseux, les jointures sont bien mises en évidence pour lui simplifier le travail
- Elle est conseillée depuis plus 20 ans (1992) par le comité de normalisation du langage SQL et prise en charge par la majorité des SGBDR

Je suis certain de l’avoir déjà dit sur ce forum mais vu l’aspect mythologique des jointures ANSI je pense qu’il est utile de le redire.

Le fait est que Oracle transforme vos jolies requêtes ANSI à son sauce habituel et que ce sont ces requêtes transformées qu’il optimise par la suite. Donc le mantra disant que l’optimiseur est capable du meilleur en présence des requêtes ANSI est mythologique chez Oracle.

Ces transformations ont été souvent source des bugs au moins jusqu’à la version 11g d’Oracle. De plus comme Jonathan Lewis l’avait mentionné sur son blog elles rendent plus difficile l’utilisation des astuces SQL (SQL Hints) dans certaines casses.

Concernant les avantages de type « séparation des conditions des jointures » et « sécurisation de l’écriture » ces sont des avantages assez relatives. Rien n’empêche de séparer les conditions de jointure etc. dans une jointure classique et rien non plus n’empêche un semi-produit cartésien si l’utilisateur de la base, c’est-à-dire le développeur dans ce cas, a un niveau de maitrise du SQL assez bas.

Cela ne veut pas dire que l’écriture ANSI est déconseillée avec Oracle, loin de ça. Choisissez ce que vous arrange mais fait un choix avisé.