Optimisation requête sql

Version imprimable

Bonjour,

j'ai une grosse requête et lorsque je sélectionne mes champs ( dans mon select), il m'arrive d'avoir plein pas mal de sous requête, du genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ........... NVL((SELECT t6.rue FROM tableAdresse t6 WHERE t6.x550_id=ta.x503_id and t6.typeadresse ='012' AND rownum=1),' ') AS ADR_PERSO, NVL((SELECT t6.rue FROM tableAdresse t6 WHERE t6.x550_id=ta.x503_id and t6.typeadresse ='013' AND rownum=1),' ') AS ADR_pro, ... ... from table2 ta inner join ....
donc je me suis renseigné un peu pour une question d'optimisation et j'ai cru comprendre que c'etait mieux de faire des jointures du genre :
Code:

1 2 3 4 5 6 7 8 9 select ta.identifiant, t6.rue as rue_perso, t5.rue as rue_pro etc.... .... from table2 ta inner join tableAdresse t6 on .... and t6.typeadresse = '012' inner join tableAdresse t5 on .... and t5.typeadresse = '013'
à votre avis est-ce mieux la méthode 2, donc avec des jointures ou la méthode 1?

Merci à vous

19/02/2019, 08h48
Scriuiw

Bonjour,

La 1ère requête contient surtout des rownum=1, elle ne ramènera donc pas potentiellement le même résultat que la seconde qui est à base de jointure mais sans la restriction sur le nombre de lignes à extraire.

J'ai oublié de préciser, par exemple j'ai ceci à la fin de la requête :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
...........
NVL((SELECT t6.rue 
FROM tableAdresse t6
WHERE t6.x550_id=ta.x503_id
and t6.typeadresse ='012'
AND rownum=1),' ') AS ADR_PERSO,
 
NVL((SELECT t6.rue 
FROM tableAdresse t6
WHERE t6.x550_id=ta.x503_id
and t6.typeadresse ='013'
AND rownum=1),' ') AS ADR_pro,
...
...
from table2 ta
inner join ....
where numpers=....
and date=....

et pour la seconde methode :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
select ta.identifiant,
t6.rue as rue_perso,
t5.rue as rue_pro
etc....
....
from table2 ta
inner join tableAdresse t6 on .... and t6.typeadresse = '012'
inner join tableAdresse t5 on .... and t5.typeadresse = '013'
....
where numpers=....
and date=....

donc en gros , pour une question d'optimisation et de temps d’exécution, la seconde méthode serait la plus adapté selon vous ?

19/02/2019, 10h23
Scriuiw

Je ne peux répondre à cette question, il faudrait en premier lieu regarder les plans d'exécution des deux requêtes.
Si la deuxième méthode semble plus naturelle, la première en passant par des sous-requêtes est parfois nécessaire pour obtenir le résultat voulu.

Obtenez-vous le même résultat entre les deux déjà ?
19/02/2019, 10h36
skuatamad

Vous utilisez un rownum = 1 mais sans critère de tri, votre 1ere requête est donc potentiellement non consistante dans le temps, plusieurs exécutions peuvent renvoyer des données différentes si vous avez bien plusieurs valeurs possibles.

Ensuite, la transformation d'une sous requête scalaire (un SELECT dans un SELECT) se traduit par une jointure externe, il faut donc remplacer les INNER JOIN par des LEFT JOIN pour ne pas filtrer les lignes en cas d'absence d'adresse pro par exemple.

Concernant la partie optimisation, ce n'est pas si simple, et dépend de l'utilisation faites de la requête ainsi que potentiellement du nombre de ligne renvoyé et/ou paginé.
En gros la 1ere requête pourrait répondre plus vite pour renvoyer les 1eres lignes, celle avec jointure sera peut être plus performante pour traiter l'ensemble des lignes comme par exemple alimenter une table dans un job ETL.
19/02/2019, 10h50
Waldar

Citation:

Envoyé par android59

à votre avis est-ce mieux la méthode 2, donc avec des jointures ou la méthode 1?

Probablement aucune des deux, vous avez a priori besoin d'un PIVOT.
19/02/2019, 11h02
dramanebox

Salut,

Au vue de la 1ère requête, la sous-requête doit retourner plus d'une ligne d’où le ROWNUM.

Je propose si toutefois ta requête sera très souvent utilisée que tu crées une fonction sur la rue pour ne retourner qu'une seule valeur (exacte).

Ceci va non seulement alléger la structure de la requête et tu gagneras aussi en temps d'exécution.

Voir le TIMING sous SQLPLUS

Citation:

SINON A L’ÉTAT ACTUEL, LES DEUX REQUÊTES SONT QUASI DIFFÉRENTES ET NE RETOURNENT PAS DU TOUT LE MÊME RÉSULTAT
21/02/2019, 07h57
android59

Bonjour,

merci pour vos retour je vais étudier la question :)