Discussion :

[Benji1986]

Bonjour,

Voilà j'ai une question bête je voudrais savoir pourquoi ces requêtes fonctionnent :

Contexte :Lister les articles les moins chers (basés sur VENTE.PRIX1) que le moins cher des articles dont le VENTE.CODART commence par R, afficher le PRODUIT.LIBART et le VENTE.PRIX1)

1/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Select P1.LIBART, V1.PRIX1
FROM VENTE V1, PRODUIT P1
where V1.PRIX1 < 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
and V1.CODART = P1.CODART
GROUP BY P1.LIBART, V1.PRIX1

2/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Select Distinct P1.LIBART, V1.PRIX1
FROM VENTE V1, PRODUIT P1
where V1.PRIX1 < 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
and V1.CODART = P1.CODART

Alors que celle là, avec une jointure (qui à la base me semblait la plus logique)

3/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Select V1.LIBART, V1.PRIX1
FROM VENTE V1
where V1.PRIX1 < 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
INNER JOIN
PRODUIT P1
on V1.CODART = P1.CODART
GROUP BY V1.LIBART, V1.PRIX1

Merci par avance pour vos lumière et votre indulgence

Ben

[sevyc64]

Je dirais à priori parce que ta jointure est celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
INNER JOIN
PRODUIT P1
on V1.CODART = P1.CODART

Par contre, cette requête-ci devrait marcher (c'est l'équivalent en jointure explicite de la première requête)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Select V1.LIBART, V1.PRIX1
FROM VENTE V1
INNER JOIN PRODUIT P1 on V1.CODART = P1.CODART
where V1.PRIX1 < 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
GROUP BY V1.LIBART, V1.PRIX1

[Benji1986]

Je viens de l'executer dans SQL DEV et il me sort une erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Select V1.LIBART, V1.PRIX1
FROM VENTE V1
INNER JOIN PRODUIT P1 on V1.CODART = P1.CODART
where V1.PRIX1 < 
(Select MIN(V1.PRIX1) from VENTE v1 where V1.CODART like 'R%')
GROUP BY V1.LIBART, V1.PRIX1

ORA-00904: "V1"."LIBART" : identificateur non valide
00904. 00000 - "%s: invalid identifier"
*Cause:
*Action:
Erreur à la ligne 163, colonne 10


Petite précision la donnée LIBART se situe dans la table PRODUIT, mais vu qu'on a affaire à une jointure selon moi ça devrait passer. . .

[sevyc64]

Petite précision la donnée LIBART se situe dans la table PRODUIT, mais vu qu'on a affaire à une jointure selon moi ça devrait passer. . .

Donc c'est pas V1.LIBART, mais P1.LIBART
Dans le select et dans le group by

[Benji1986]

Super ça fonctionne, donc si j'ai bien compris, la jointure doit se faire avant le WHERE, d'ailleurs je ne savais pas qu'on pouvait mettre un where après une jointure , j'ai toujours vu dans les différents docs que j'ai vu des trucs de la forme basique Select/From/Where, donc je pensais que c'était impossible...

Bref j'ai encore du taff ! Vous n'avez pas fini de me voir sur le forum

Merci beaucoup !!!!!!!!!

Ben

[sevyc64]

La jointure se fait entre les éléments immédiatement à gauche et immédiatement à droite du mot clé JOIN (et ses déclinaisons, INNER, LEFT, RIGHT, etc).

Ensuite, la forme FROM VENTE V1, PRODUIT P1 est ce que l'on appelle une jointure implicite. C'est la même chose que le INNER JOIN mais en beaucoup moins lisible, avec les condition de jointure dans le Where ou carrément absente (là on laisse le SGBD se démerder).

Malheureusement cette forme est encore très largement enseignée, et, en plus, bien souvent pour aborder le sujet des jointures.
Pour ma part, je fais partie de ceux qui pensent que cette forme devrait purement et simplement être interdite car non seulement grande source d'erreurs et de mauvaises compréhensions du fonctionnement des jointures par les débutants, mais aussi sources de bugs et de difficultés de compréhension des requêtes en production.
De plus, pour moi, le Where, c'est une clause pour filtrer, écrémer les résultats obtenus par la requête. Ce n'est pas dans le Where que devrait se trouver les conditions d’exécution de la requête.

[mnitu]

...
Malheureusement cette forme est encore très largement enseignée, et, en plus, bien souvent pour aborder le sujet des jointures.
Pour ma part, je fais partie de ceux qui pensent que cette forme devrait purement et simplement être interdite car non seulement grande source d'erreurs et de mauvaises compréhensions du fonctionnement des jointures par les débutants, mais aussi sources de bugs et de difficultés de compréhension des requêtes en production.
De plus, pour moi, le Where, c'est une clause pour filtrer, écrémer les résultats obtenus par la requête. Ce n'est pas dans le Where que devrait se trouver les conditions d’exécution de la requête.

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é.