Discussion :

[haykelFST]

Bonjour,

REQ1:

Code :

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

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

REQ2:

Code :

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

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 ?

[skuatamad]

Non

[islamov2000]

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

[haykelFST]

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

[al1_24]

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

[Rei Ichido]

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

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

[mnitu]

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

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

1
2
3
4
5
6
 
SELECT *  
  FROM hr.departments d 
       Join
       hr.locations l 
    On 1 = 1

[mnitu]

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

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

[ojo77]

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

[haykelFST]

Bonjour,

Quelle est la requette la plus performante, (1) ou (2)

(1)

Code :

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

1
2
3
4
5
 
SELECT d.department_id, e.last_name
   FROM departments d LEFT OUTER JOIN employees e
   ON d.department_id = e.department_id
   ORDER BY d.department_id, e.last_name;

(2)

Code :

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

1
2
3
4
5
 
SELECT d.department_id, e.last_name
   FROM departments d, employees e
   WHERE d.department_id = e.department_id(+)
   ORDER BY d.department_id, e.last_name;

[mnitu]

Quelles réponses précédentes n’étaient pas claires pour vous ?

[haykelFST]

j ai pas compris:

Par exemple Oracle vous recommande (recommandait ?) fortement d'utiliser RAC avec ASM et ce depuis la 10.1 dont l'ASM était fortement buggué

[ojo77]

j ai pas compris:

Très rapidement parcequ'on est hors sujet :

Oracle recommande des trucs.
Oracle vend des trucs

Donc quand oracle recommande il peut ne pas être objectif parcequ'il a un intérêt financier à court ou moyen terme à faire utiliser telle ou telle fonctionnalité.

En clair ce n'est pas parce qu'oracle recommande un truc qu'il faut absolument le faire.

Fin du HS