Conversion d'une requête avec JOIN

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:

---

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.

Voici :

Code:

---

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 +

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

Citation:

---

Envoyé par SQLPro

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

---

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

Code:

---

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 ? :roll:
Est-ce mieux ? 8-)

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

Merci pour votre aide,

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

Code:

---

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"

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 +

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 :oops: 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 !

Citation:

---

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 !

Citation:

---

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 +

Citation:

---

Envoyé par SQLpro

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 ?

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

A +

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.