Ecriture de query avec select dans select

Bonjour,


Je viens m'adresser aux experts Oracle, car y'a un truc qui me semble assez contre intuitif et sur lequel j'aimerai avoir des explications.


Imaginons deux tables :
contrat
ref_status


J'execute la requete suivante :

Code:

---

1 2 3 4

select a.num_contrat, b.lib from contrat a left outer join ref_status b on a.status = b.status ;

---

Pour moi, c'est la bonne facon de faire. C'est jusqu'a présent comme ca que j'ai toujours rédigé mes requêtes.


Donc me voila avec ma requete qui a cette forme, et un de mes collègues s'occupe actuellement d'optimiser mon code car on a des problèmes de perf... Et justement, une de ces pistes d'amélioration, c'est de faire la chose suivante :

Code:

---

1 2 3

select a.num_contrat, (select b.lib from ref_status b where a.status = b.status) as lib from contrat a ;

---

Et effectivement, quand je regarde par exemple le plan d'execution, ca semble améliorer entre autre le cout, et aussi d'autres choses...
Donc, est ce que vous pourriez m'expliquer si j'ai tord de faire comme je fais, et si je dois changer ma facon de faire les requetes par celle de mes collègues, ou alors, si mes collègues ont tord, pourquoi est ce que ca semble justement mieux marcher avec leur requète qu'avec la mienne ?


Merci d'avance pour vos réponses.


Steven

bonjour,

Tout d'abord, (je l'ai appris récemment, merci mnitu ;)), oracle bug avec la syntaxe join ... on
donc je dirais, que la 1ere façon de faire est la bonne...hors SGBD oracle

Ensuite, le plan d'exécution dépend énormément de la plate forme sur laquelle la requête est exécutée (statistiques différentes, voire index différents)

@escartefigue
Vous avez certainement raté quelque chose à l'époque.

1. Ca ne sert à rien de comparer le coût d'exécution de deux requêtes différentes!
2. Parfois le plan d'exécution ment!
3. Les deux requêtes sont équivalentes, cela veut dire qu'une peut être réécrite comme l'autre presque mécaniquement.
4. D'une manière générale remplacer une jointure externe par une sous-requête scalaire est inefficace sinon Oracle le féra systématiquement (voir 3)
5. Parfois une requête sous-scalaire peut être exécutée d'une manière plus efficace du à un mécanisme de cache des valeurs qu'Oracle utilise dans ce cas. Cela est le cas si la requête sous-scalaire ramène peut des valeurs distinctes qui peuvent donc être cachées en mémoire.

Dans ce cas comme très probablement la cardinalité de l'ensemble des valeurs possibles de la colonne statut est réduite il pourrais s'avérer plus efficace; mais c'est un cas particulier. Et encore il faut comparer des statistiques montant qu'effectivement c'est plus efficace sinon dans la plupart de cases la différence est minimale.

Si vos collègues pense que cela devrait avoir un caractère systématique ils ont tort parce qu'ils n'ont pas compris ce qui se passe derrière la scène!

Merci pour vos réponses qui me conforte un peu dans mon idée.
Je vais les laisser faire leur petite amélioration, j'ai aucune envie de remettre les mains dans le camboui et je préfère qu'ils s'en occupent vu qu'ils seront ceux qui maintiendront le tout.


Juste un ti truc en plus que je comprends pas très bien:
@mnitu

Citation:

---

1.Ca ne sert à rien de comparer le coût d'exécution de deux requêtes différentes!

---

Qu'est-ce que vous appelez deux requêtes différentes ?
Est-ce que dans mon cas ci-dessus, mes requêtes sont "différentes" ?
De facon général, je compare les plans de requêtes qui ramène les mêmes choses, mais sur lesquels la façon de joindre peut être différente. Par exemple, utiliser des group by ou introduire une CTE, un exists ou un in, autant d'éléments qui peuvent faire grandement varier mon plan mais pas mon résultat pour autant.
Vous dites que dans ce cas, ça ne sert à rien de comparer ? N’y a-t-il vraiment aucun élément qui serait un peu immuable et que l'on pourrait analyser avant de se lancer dans l'exécution de requêtes qui mettent plusieurs heures à s'exécuter ?

Dans un monde idéal cette affirmation devrait être erronée ; mais nous sommes dans un monde fini et imparfait. En principe le coût représente le temps que la requête devrait mettre à s’exécuter, exprimé dans une unité de mesure un peu particulière.

Deux requêtes sont équivalentes s’ils retournent le même résultat correct. Deux requête qui retournent le même résultat mais qui différent dans leur texte sont souvent différentes. L’optimiseur d’Oracle est actuellement assez intelligent pour permettre la réécriture des requêtes via son composant de transformation de requêtes. Par conséquence vous voyez parfois dans les plans des exécutions ces transformations. Si l'optimiseur opère ces transformations sur vos requêtes de texte différente elles deviens identiques.

La presque unique cause qui fait qu’une requête est mal optimisée vient d’un mauvais calcul des cardinalités. Ces mauvais cardinalités se traduisent en :

1. des mauvaise méthodes des accès, qui impliquent
2. des mauvaise méthodes des jointures, qui impliquent
3. des mauvaise ordre des jointures des tables, qui impliquent
4. un temps d’exécution décevant

Pour optimiser les requêtes la bonne méthode consiste donc

• à comprendre la requête (on peut pas optimiser ce qu’on comprends pas)
• à connaître les données
• à identifier le plan d’exécution réel si possible (oui explain plan peut mentir)
• à examiner les cardinalités pour identifier là où ça dérape
• à imaginer le bon plan d’exécution
• à utiliser l’arsenal des méthodes offert par Oracle pour imposer le bon plan d’exécution.

... j'aime pas Oracle lol

^^

Merci en tout cas pour ce complément d'information

Citation:

---

Envoyé par bstevy

... j'aime pas Oracle lol
...

---

Vous pouvez vous consoler en vous disant qu'ailleurs c'est pire encore :)

Citation:

---

Envoyé par mnitu

Vous pouvez vous consoler en vous disant qu'ailleurs c'est pire encore :)

---

Je sais pas trop... je viens de teradata ^^
donc déjà, je pourrais dire que j'aime pas le OLTP lol