Performance des requêtes

Bonjour,

REQ1:

Code:

---

select * from A,B where A.codea =B.code

---

REQ2:

Code:

---

select * from A inner join B on A.codea=B.code

---

Y a t-il une différence entre ces deux requêtes du point de vue performance et temps de réponse ?

Non

Oui ,il y la difference; sinon pourqoui inventer une nouvelle syntaxe.

OUI/NON, y a t-il un document qui justifie?

Il ne devrait pas y avoir de différence à l'exécution.

La syntaxe avec INNER JOIN assure la cohérence avec la syntaxe de xxx OUTER JOIN et CROSS JOIN.
Par ailleurs, elle permet de mettre en évidence les éléments de la jointure et les séparer des conditions de filtrage, rendant la requête plus lisible.

En corollaire, dans une requête complexe comportant des jointures entre plusieurs tables, l'obligation de préciser la condition de jointure dans la clause ON de l'instruction INNER JOIN évite l'oubli de cette condition et la création de produits cartésiens ;)

Citation:

---

Envoyé par al1_24

Il ne devrait pas y avoir de différence à l'exécution.

---

À l'exécution, non, mais au parsing ? Je me suis déjà posé la question, et je n'ai pas encore eu le courage de mettre au point un test, ni de rechercher si quelqu'un a eu le courage de le faire :?

Citation:

---

La syntaxe avec INNER JOIN assure la cohérence avec la syntaxe de xxx OUTER JOIN et CROSS JOIN.
Par ailleurs, elle permet de mettre en évidence les éléments de la jointure et les séparer des conditions de filtrage, rendant la requête plus lisible.

---

Je plussoie totalement ce point (qui explique aussi ma flemme à mettre au point un test : même si le résultat donne un parsing largement en faveur de la jointure "old school", je n'aurais pas envie d'y passer).

La requête est d'abord transformée et ensuite optimisée.
Faite une trace de l'evenement 10053

Citation:

---

...
SQL:******* UNPARSED QUERY IS *******
SELECT "D"."DEPARTMENT_ID" "DEPARTMENT_ID","D"."DEPARTMENT_NAME" "DEPARTMENT_NAME","D"."MANAGER_ID" "MANAGER_ID","
D"."LOCATION_ID" "LOCATION_ID","L"."LOCATION_ID" "LOCATION_ID","L"."STREET_ADDRESS" "STREET_ADDRESS","L"."POSTAL_C
ODE" "POSTAL_CODE","L"."CITY" "CITY","L"."STATE_PROVINCE" "STATE_PROVINCE","L"."COUNTRY_ID" "COUNTRY_ID" FROM "HR"
."DEPARTMENTS" "D","HR"."LOCATIONS" "L" WHERE "D"."LOCATION_ID"="L"."LOCATION_ID"
...
Current SQL statement for this session:
SELECT *
FROM hr.departments d
Join
hr.locations l
On d.location_id = l.location_id

---

Citation:

---

Envoyé par al1_24

...
En corollaire, dans une requête complexe comportant des jointures entre plusieurs tables, l'obligation de préciser la condition de jointure dans la clause ON de l'instruction INNER JOIN évite l'oubli de cette condition et la création de produits cartésiens ;)

---

Je peur que elle n'evite rien. Voilà un exemple limite.

Code:

---

1 2 3 4 5 6

SELECT * FROM hr.departments d Join hr.locations l On 1 = 1

---

Citation:

---

Envoyé par mnitu

Je peur que elle n'evite rien. Voilà un exemple limite.
...

---

Mouais... Il y a une différence entre oublier une condition et mettre volontairement une condition stupide !

@Pomalaix
Pensez aux jointures multi-colonnes, où rien ne vous empêche d’oublier une condition. Voir aussi non equijoins.

Citation:

---

Envoyé par Pomalaix

Mouais... Il y a une différence entre oublier une condition et mettre volontairement une condition stupide !

---

Y a quand même moyen de se planter sur les conditions de jointure et faire un produit cartésien :

Code:

---

1 2 3 4

SELECT * FROM hr.departments d JOIN hr.locations l ON l.location_id = l.location_id

---

Le gros avantage de la syntaxe ANSI c'est lorsqu'un développeur veut faire un produit cartésien, il utilise CROSS JOIN qui est explicite et donc nettement plus maintenable.

malheureusement, personne a une réponse convaincante accompagnée d'un document!!!

Pas de réponse convaincante, mais bon, voici la mienne, qui s'éloigne un peu du domaine de performances mais qui est à prendre en compte lorsque l'on travaille sur des bases conséquentes :

Je n'ai jamais constaté de différence entre les deux syntaxes à un niveau de requête assez standard (jointures sur 2 ou 3 tables).

Cependant, si tu penses à la lisibilité du code et a la maintenabilité, c'est plus facile de faire évoluer des jointures en INNER, OUTER, ...

Pourquoi ? Tout simplement parce que l'on sait directement ou rajouter les conditions de jointures des conditions de filtrage. Si jamais je dois reprendre une requête complexe, j'ose espérer qu'elle n'est pas en jointure WHERE, qui va mélanger les deux conditions et complexifier le tout... :)

Pour la "preuve" par document, je t'invite à lire tout ceci et les liens généraux qui en découlent. Bonne lecture ! :aie:
http://www.developpez.net/forums/d63...tre-jointures/

Citation:

---

Envoyé par haykelFST

Y a t-il une différence entre ces deux requêtes du point de vue performance et temps de réponse ?

---

Non,

Pour vous en convaincre testez un explain plan avec les deux syntaxes en effectuant une trace 10053.

Vous verrez qu'oracle réécrit les jointures ANSI comme des jointures non ANSI (en prédicat).

Citation:

---

Envoyé par haykelFST

malheureusement, personne a une réponse convaincante accompagnée d'un document!!!

---

Que voulez-vous de plus convaincante que la trace de l’optimiseur montrant la réécriture de la requête en format non-ANSI ? :roll:

Citation:

---

Envoyé par haykelFST

malheureusement, personne a une réponse convaincante accompagnée d'un document!!!

---

Moi, j'ai dit oui, mais pourquoi?

REQ1:

Code:

---

select * from t1,t2 where t1.a=t2.b

---

Avant que la requete projecte le resultat en vérifiant la condition, elle fait un produit cartésien. donc la condition vient apres la jointure(produit cartésien).

Par contre, la requete REQ2

Code:

---

select * from t1 join t2 on t1.a=t2.b

---

, elle ne peut pas etre executé sans verifier la condition de jointure. Cette derniere (condition) est une part de la syntaxe de jointure.

Citation:

---

Envoyé par islamov2000

Moi, j'ai dit oui, mais pourquoi?

REQ1:

Code:

---

select * from t1,t2 where t1.a=t2.b

---

Avant que la requete projecte le resultat en vérifiant la condition, elle fait un produit cartésien. donc la condition vient apres la jointure(produit cartésien).

Par contre, la requete REQ2

Code:

---

select * from t1 join t2 on t1.a=t2.b

---

, elle ne peut pas etre executé sans verifier la condition de jointure. Cette derniere (condition) est une part de la syntaxe de jointure.

---

Malheureusement pour vous, et heureusement pour nous, le moteur d'Oracle ne fait pas stupidement un produit cartésien avant de restreindre les lignes en fonction des jointures (sauf probablement s'il estime qu'il peut le faire, avec des cardinalités très faibles) ; d'ailleurs si tel était le cas, les requêtes écrites en mode "traditionnel" (par opposition à ANSI) auraient des performances tellement catastrophiques que personne ne pourrait les utiliser (concrètement, ça signifierait l'abandon de la compatibilité).
On en revient toujours au même point : faites l'essai, comparez les plans d'exécution.
La seule question qui me reste concerne le temps de parsing de la requête, ce qui est dans la très grande majorité des cas complètement anecdotique, mais pourrait intéressant dans certains contextes spécifiques de requêtages massifs et non bindés.

Citation:

---

Envoyé par islamov2000

Moi, j'ai dit oui, mais pourquoi?

---

On peut se tromper, on peut croire quelque chose qui n'est pas vrai, mais l'intérêt de participer sur un forum c'est que même sans poser de question on en apprend tous les jours.

Par contre maintenir une affirmation fausse alors que certains messages permettent d'avoir la bonne démarche pour analyser et comprendre le phénomène, c'est pas très pro.

Citation:

---

Envoyé par mnitu

La requête est d'abord transformée et ensuite optimisée.
Faite une trace de l'evenement 10053

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

... SQL:******* UNPARSED QUERY IS ******* SELECT "D"."DEPARTMENT_ID" "DEPARTMENT_ID","D"."DEPARTMENT_NAME" "DEPARTMENT_NAME","D"."MANAGER_ID" "MANAGER_ID"," D"."LOCATION_ID" "LOCATION_ID","L"."LOCATION_ID" "LOCATION_ID","L"."STREET_ADDRESS" "STREET_ADDRESS","L"."POSTAL_C ODE" "POSTAL_CODE","L"."CITY" "CITY","L"."STATE_PROVINCE" "STATE_PROVINCE","L"."COUNTRY_ID" "COUNTRY_ID" FROM "HR" ."DEPARTMENTS" "D","HR"."LOCATIONS" "L" WHERE "D"."LOCATION_ID"="L"."LOCATION_ID" ... Current SQL statement for this session: SELECT * FROM hr.departments d Join hr.locations l On d.location_id = l.location_id

---

---

[edit] Pour info c'est le forum oracle, les réponses ne concernent donc qu'oracle, d'autres SGBDR peuvent fonctionner différemment.

Citation:

---

Envoyé par skuatamad

On peut se tromper, on peut croire quelque chose qui n'est pas vrai, mais l'intérêt de participer sur un forum c'est que même sans poser de question on en apprend tous les jours.

Par contre maintenir une affirmation fausse alors que certains messages permettent d'avoir la bonne démarche pour analyser et comprendre le phénomène, c'est pas très pro.

[edit] Pour info c'est le forum oracle, les réponses ne concernent donc qu'oracle, d'autres SGBDR peuvent fonctionner différemment.

---

Tu as raison skuatamad, meme moi,je suis là pour apprendre et faire apprendre.
C'etait mon analyse; la preuve que personne a fournie une docamentation qui prouve l'avis de chaque'un d'antre nous.

Citation:

---

Envoyé par skuatamad

[edit] Pour info c'est le forum oracle, les réponses ne concernent donc qu'oracle, d'autres SGBDR peuvent fonctionner différemment.

---

Moi je n'ai pas pensé seulement Oracle, j'ai penser aus autres SGBD. je sais bien que Oracle a son propre optimiseur de SQL et il trace son plan d'execution.

Bonjour,

Citation:

---

Envoyé par haykelFST

malheureusement, personne a une réponse convaincante accompagnée d'un document!!!

---

Et voilà, la doc Oracle qui recommande fortement la syntaxe ANSI: Oracle strongly recommends that you use the more flexible FROM clause join syntax shown in the former example.

Ce n'est pas une question de performance. Mais si elle est recommandée par l'éditeur, c'est là qu'il y aura le moins de bugs.

Cordialement,
Franck.