Requête récursive (en vue) lente avec jointure d'une table

Bonjour,

j'ai un petit souci de compréhension, j'ai une requête récursive qui fonctionne très bien pour des nomenclatures d'articles. Cette requête est enregistrée en tant que une vue.
si j'interroge cette vue sur différents critères, la réponse est instantanée :

Code:

---

1 2 3

select rec.* from VUEREC rec where rec.CRI1='critere1' and rec.CRI2=40 and rec.CRI3=1

---

Cette vue en total ramène 1 million de lignes en 30 secondes :

Code:

---

1 2	select count(*) from VUEREC

---

J'ai une table à côté qui s'exécute aussi instantanément pour me ramener une ligne de résultat (interroger précédemment dans la vue) :

Code:

---

1 2 3

select t1.* from TABLE1 t1 where t1.CLEA1='Cle1' and t1.CLEN2=36788

---

Si je veux la nomenclature du résultat précédent, je réalise une jointure comme celle-ci :

Code:

---

1 2 3 4

select rec.* from VUEREC rec inner join TABLE1 t1 on (t1.CLEA2=rec.CRI1 and t1.CLEN1=rec.CRI2) where t1.CLEA1='Cle1' and t1.CLEN2=36788 and rec.CRI3=1

---

J'ai bien mon résultat précédent mais en 30 secondes !!
Cela sous-entend que la vue est entièrement générée avant de faire la jointure.
Comment faut-il faire pour que le résultat de la vue soit filtré correctement ?
Merci de votre aide,
je dois passer à côté d'un principe important...

Bonjour

Quelle est la définition de la vue ?

C'est une requête récursive de ce type:

Code:

---

1 2 3 4 5 6 7 8 9

WITH tree (gpere,niv,pere,seq,article,lnk,qte,unit,tri,alt) AS (SELECT p.ARTICLE,0,p.ARTICLE,0,p.ARTICLE,cast(p.QTYDEF as decimal(10,5)),cast(p.QTYDEF as decimal(10,5)),' ',cast('' as varchar(max)),p.ALT FROM BOM p UNION ALL SELECT t.gpere,t.niv + 1,f.ARTICLE,cast(f.SEQ as integer),f.CPNARTICLE,cast(f.QTE as decimal(10,5)),cast((f.QTE*t.qte) as decimal(10,5)),cast(f.UNI as varchar(3)) ,t.tri+str(f.SEQ,3,0),f.ALT FROM BOMD f INNER JOIN tree t ON (t.article=f.ARTICLE AND t.alt=f.ALT AND (f.DATFIN>=getdate() or f.DATFIN<0))) SELECT alt,gpere,niv,pere,seq,article,lnk,qte,unit,tri FROM tree

---

Au lieu de faire une vue, faites une fonction table inline et paramétrez les critères dans l'UDF table.

A +

Bonjour,

désolé mais je ne comprends pas la réponse. Elle ne m'explique pourquoi cette jointure entre vue et table est si longue !
Je n'ai pas trop de choix pour la création de cette vue. Elle me permet de minimiser l'utilisation de table temporaire (avec traitement préalable) avant l'édition dans Crystal Report.
Mais vous m'avez fait avancer dans mon analyse, car j'ai déjà d'autres jointure dans d'autres états Crystal, qui fonctionnent très bien.
La plupart du temps quand les utilisateurs demandent une nomenclature ils savent l'article parent. Mais dans mon cas particulier, on part d'un ordre de fabrication duquel on veut imprimer la nomenclature de l'article fabriqué.
Donc,
cette requête met 30 secondes avec un filtre sur la Cle1 :

Code:

---

1 2 3 4

select rec.* from VUEREC rec inner join TABLE1 t1 on (t1.CLEA2=rec.CRI1 and t1.CLEN1=rec.CRI2) where t1.CLEA1='Cle1' and t1.CLEN2=36788 and rec.CRI3=1

---

et celle-ci sur la clé2 est instantanée :

Code:

---

1 2 3 4

select rec.* from VUEREC rec inner join TABLE1 t1 on (t1.CLEA2=rec.CRI1 and t1.CLEN1=rec.CRI2) where t1.CLEA2='Cle2' and t1.CLEN2=36788 and rec.CRI3=1

---

Tout ça parce que cette Cle2 est le critère de jointure entre la table et la vue !
Pour moi c'est déjà une solution pour corriger mon problème.(je peux avoir l'article et l’envoyer à Crystal comme paramètre)

Mais j'aimerai bien comprendre la dynamique de ce problème ?
Avez-vous une explication ?
Merci

Bonjour,

Pour pouvoir répondre à la question, il nous faudrait toutes les informations :
structure de toutes les tables en jeu, avec les index.
Par ailleurs, vous semblez avoir modifié les requêtes que vous avez postées, en y incluant des erreurs (notamment, les alias ne sont pas bons) Cela rend l'analyse difficile voire impossible.
Si les filtres ne sont pas les mêmes, cela peut expliquer la différence, car le plan d’exécution ne sera plus le même.
mais la réponse à votre question doit se trouver dans les plans d’exécution. Les avez vous comparés ?

Vos statistiques sont -elles à jour ?