SELECT imbriqué ou jointure reflexive

[JauB]

Bonjour,
je suis tombé dans le cas où j'ai besoin de faire une jointure sur la même table deux fois ( dans la même requête). ma question est: en matière de performance, est ce qu'il vaut mieux instancier la même table deux fois dans la clause FROM ou bien faire un SELECT imbriqué et de joindre ma table avec le SELECT imbriqué:
du genre:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
1ère solution:
 
SELECT *
FROM TABLE1 t1, TABLE1 t2
WHERE t1.champ1=t2.champ2
--AND CONDITIONS...
 
2ème solution
SELECT *
FROM TABLE1 t1, ( SELECT champ2 FROM TABLE1 t2 WHERE --CONDITIONS)
WHERE t1.champ1=t2.champ2
--and CONDITIONS.....

Merci pour vos réponses

[Mercure]

J'utiliserais la clause JOIN sur les critères de rapprochement des 2 tables car le fait de placer les critères sur le prédicat WHERE relève d'une méthode ancienne et probablement moins performante.
Sur le WHERE, et dans la mesure du possible, je ne placerais que les valeurs littérales de comparaison, par ex.
WHERE SOCIETE = 10 AND DATEx = Date('20070130'), etc.

En outre, un composant subselect est toujours pénalisant et j'essaierais de l'éviter.

Code :

1
2
3
4
5
SELECT *
FROM TABLE1 t1 JOIN TABLE1 t2
ON t1.champ1=t2.champ2
WHERE ...
--AND CONDITIONS...

[jab]

D'accord avec Mercure je pense que la jointure est le moyen le plus rapide mais tu devrais malgré tout visualiser le ce qui se passe en interne en utilisant l'éditeur de commande. On est parfois très surpris. Jette un oeil sur mon article sur l'optimisation http://jab.developpez.com/tutoriels/db2/optimisation/

L'utilisation de JOIN est plus clair bien que je pense que le moteur va traiter les 2 façon de faire le join de la même manière. Par contre si tu peux évite le * qui en définitive est souvant la cause de problème de performance. Sauf évidemment si tu as besoin de tout les champs.

Envoyé par Mercure

Code :

[JauB]

c'est quoi la différence entre JOIN et INNER JOIN?

[_Jnie_]

Envoyé par JauB

c'est quoi la différence entre JOIN et INNER JOIN?

Aucune, inner est facultatif, voir http://sql.developpez.com/sqlaz/jointures/#L2

[Mercure]

Jaub,

Sous quel OS travailles-tu ?

[JauB]

je suis sous I5 ( soit disons le nouveau AS400)

[Mercure]

JauB,

Avant d'exécuter la requête, fais un STRDBG dans ton job. Le debug va générer dans le log du job des messages qui vont te permettre d'optimiser ta requête. Exécute ta requête et prête ensuite une attention particulière aux messages indiquant que SQL a du créer un chemin d'accés sur telle ou telle colonne (Faire <Aide> sur le message). Si ta requête est utilisée régulièrement, il est bien entendu préférable de créer l'index en question pour éviter que SQL le crée lors de chaque passage.
Démarre également un STRDBMON -> OUTFILE dans ce même job. Quand la requête est terminée, arrête le monitoring avec ENDDBMON. Analyse ensuite le résultat et vois en particulier si ta requête a utilisé le nouveau moteur SQE (SQL Query Engine) ou l'ancien CQE (Classic Query Engine). C'est une mine d'informations.
Tu trouveras également très utile de lire le Redbook "SQL Performance Diagnosis on IBM DB2 Universal Database for iSeries" que tu trouveras à cette adresse http://www.redbooks.ibm.com/redbooks/pdfs/sg246654.pdf.

Si ta requête utilise l'ancien moteur CQE, tu peux déjà améliorer ses performances en faisant un essai avec ce qui suit:

• CRTDUPOBJ QSYS/QAQQINI -> une autre bibliothèque (MABIB par ex.)
• Change la valeur (QQVAL) de l'option (QQPARM) IGNORE_DERIVED_INDEX en *YES dans le nouveau ficher QAQQINI
• CHGQRYA QRYOPTLIB(MABIB)
• Réexécute ensuite ta requête dans le même job

Si tu utilises cette option dans le fichier QAQQINI, le query devrait être exécuté avec le nouveau moteur SQE car tous les chemins d'accés des logiques avec SELECT/OMIT et DYNSLT sont ignorés, ces derniers impliquant d'emblée l'utilisation de l'ancien moteur.

"Visual Explain" dans iSeries Navigator peut aussi t'aider.

[JauB]

c'est un peu lourd comme traitement mais je vais essayer de suivre les étaps