Discussion :

[SQLNewbie]

Bonjour, comme mon pseudo le souligne, je suis débutant en SQL et je bute sur un problème que les différents (et excellents) tutoriels disponibles sur Developpez.com ne m'ont pas permis de résoudre. Je dois mal poser mon problème ...
Voilà, je souhaite convertir une requête de cette forme, où les jointures sont faites avec "WHERE" en son équivalent avec l'instruction "JOIN" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
SELECT DISTINCT
SUBSTR(ls.lot_id,1,16) AS lot, 
SUBSTR(ct.slot_id,1,2) AS slot, 
etc.. 
SUBSTR(rn.equipment_id,1,5) AS equip
 
FROM
run rn,
chamber_tracking ct,
operation oper,
lot_step ls
 
WHERE
ls.lot_id LIKE 'ABC%'
AND ls.lot_id= ct.lot_id 
AND ls.run_id = rn.run_id
AND ls.operation_name=oper.operation_name
AND ct.run_id = rn.run_id

Les tables ct, ls et rn sont jointes chacune à l'autre, et je n'arrive pas
à traduire ceci correctement.

Merci pour votre aide éventuelle.

[SQLpro]

Voici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT DISTINCT SUBSTR(ls.lot_id,1,16) AS lot,
       SUBSTR(ct.slot_id,1,2) AS slot,
       -- etc..
       SUBSTR(rn.equipment_id,1,5) AS equip
 
-- une jointure est un arbre. Il y a une table "racine" :
FROM   run rn
-- une première branche relative à la racine :       
       INNER JOIN chamber_tracking ct ON rn.run_id = ct.run_id 
-- une seconde branche mal foutue est grefée à la fois sur la racine et sur la première branche :
       INNER JOIN lot_step ls         ON rn.run_id = ls.run_id AND ls.lot_id= ct.lot_id
-- une troisième branche gréfée sur la seconde :       
              INNER JOIN operation oper      ON ls.operation_name=oper.operation_name
 
WHERE ls.lot_id LIKE 'ABC%'

Chaque clause ON introduit un prédicat de jointure qui indique sur quelle critère elle se fait.
Relisez les cours que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/jointures/

Cependant la présence de cette branche mal foutue est généralement synonyme d'erreur de modélisation, ou de codage de requête...
On appelle cela jointure cyclique et dans votre cas particulier triangulaire...

A +

[CinePhil]

De la même manière qu'il y a

une troisième branche gréfée sur la seconde

, ne peut-on couper la deuxième branche mal foutue en deux ?

Code :

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

1
2
3
4
5
6
7
8
FROM  run rn
-- une première branche relative à la racine :       
       INNER JOIN chamber_tracking ct ON rn.run_id = ct.run_id 
-- une seconde branchecoupée en 2 :
       INNER JOIN lot_step ls         ON rn.run_id = ls.run_id 
              INNER JOIN chamber_tracking ct2 ON ls.lot_id= ct2.lot_id
-- une troisième branche greffée sur la seconde :       
              INNER JOIN operation oper      ON ls.operation_name=oper.operation_name

Je vois bien que ça met en jeu deux fois la même table.
Est-ce tout simplement faux ?
Est-ce équivalent à la branche mal foutue ?
Est-ce mieux ?

[Waldar]

Je dirai que c'est faux, car ni ct ni ct2 ne remplissent toutes les conditions.

[SQLNewbie]

Merci pour votre aide,

En réfléchissant aujourd'hui j'ai écrit ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT DISTINCT SUBSTR(ls.lot_id,1,16) AS lot,
       SUBSTR(ct.slot_id,1,2) AS slot,
       -- etc..
       SUBSTR(rn.equipment_id,1,5) AS equip
 
FROM   lot_step ls
       INNER JOIN chamber_tracking ct
             ON ls.lot_id = ct.lot_id
              AND ls.run_id = ct.run_id     (c1)
       INNER JOIN run rn
              ON  ls.run_id = rn.run_id       (c2)
       INNER JOIN operation oper
              ON ls.operation_name=oper.operation_name
 
WHERE ls.lot_id LIKE 'ABC%'

Il me semble que ça donne les mêmes résultats, mais est-ce correct ?
En effet, je pense que (c1) & (c2) est équivalent à "ct.run_id = ls.run_id"

[SQLpro]

J'espère que vous comprenez maintenant pourquoi écrire des jointures avec JOIN est plus précis et efficace qu'en mettant tout dans un WHERE fourre tout ou vous ne voyez rien, et surtout pas vos erreurs !

Je m'étonne d'ailleurs toujours que l'on continue à enseigner la jointure dans le WHERE alors que cette syntaxe est obsolète depuis plus de 15 ans !

A +

[SQLNewbie]

Bonsoir,

Oh, on ne m'a rien enseigné ...

Pour les besoins de mon travail j'ai repris des routines SQL qui avaient été écrites par d'autres avant moi sans vraiment les comprendre.

J'ai à présent le temps et le recul pour me pencher sur SQL et sur la réécriture de ces requêtes et je découvre des horreurs.

Ceci étant dit, une fois réécrites convenablement, les requêtes tournent PLUS LENTEMENT sur le serveur sqlplus de mon entreprise. Je n'y comprends rien.

Juste une remarque : avant de faire cette démarche, j'ai également généré beaucoup de requêtes avec TOAD et Business Object. Le résultat de ces générateurs automatique contient uniquement les horribles jointures avec "WHERE".

Bonnes fêtes !

[SQLpro]

Juste une remarque : avant de faire cette démarche, j'ai également généré beaucoup de requêtes avec TOAD et Business Object. Le résultat de ces générateurs automatique contient uniquement les horribles jointures avec "WHERE".

Ces outils doivent marcher avec des versions antérieures et par conséquent délivrent en règle générale une syntaxe SQL très bas de gemme !

Ceci étant dit, une fois réécrites convenablement, les requêtes tournent PLUS LENTEMENT sur le serveur sqlplus de mon entreprise. Je n'y comprends rien.

SQLplus n'est pas un SGBDR. C'est un outil client...
Avez vous fait un portage de votre base ?

A +

[SQLNewbie]

SQLplus n'est pas un SGBDR. C'est un outil client...
Avez vous fait un portage de votre base ?

Pardon pour cette imprécision ... étant autodidacte en informatique, je manque de rigueur.

La base elle même est de type Oracle version 9.
Qu'entendez-vous par portage ?

[SQLpro]

Migré une base d'un serveur à l'autre ou d'une version à l'autre ?

A +

[SQLNewbie]

Non, ce genre de manipulations est réservé à l'équipe IT de ma compagnie.

Je suis simplement un employé qui code dans son coin des applications pour simplifier son travail quotidien.

J'écris des programmes en VB qui génèrent des requêtes SQL, les soumettent à SQL*Plus, puis récupèrent le résultat et effectuent des calculs spécifiques avec.

Je n'ai donc aucun pouvoir sur l'architecture même des bases ou leur implémentation.