Discussion :

[gaboo_bl]

Bonjour à tous, j'aimerais avoir votre avis sur une requête que je suis en train d'étudier en vue d'optimisation.
Voilà le morceau d'existant qui me gène:

Code :

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

1
2
3
4
5
6
7
8
9
10
select data.clé,tbl1.mnt, nvl(tbl2.mnt,0) + nvl(tbl3.mnt,0) + nvl(tbl4.mnt,0)
from data, couts tbl1,couts tbl2,couts tbl3,couts tbl4  
where  tbl1.clé(+) = data.clé
   AND tbl1.type(+) = 'a'
   AND tbl2.clé(+) = data.clé
   AND tbl2.type(+) = 'b'
   AND tbl3.clé(+) = data.clé
   AND tbl3.type(+) = 'c'
   AND tbl4.clé(+) = data.clé
   AND tbl4.type(+) = 'd'

en prennant en compte que couts est une table qui contient beaucoup de données, cette requête perds très vite en temps de réponse selon les clauses where qu'on y ajoute.
Alors le but avoué de cette requête, après étude, est de présenter des données qui sont dans plusieurs enregistrements dans la table couts dans un seul enregistrement au final. Je suis OK pour dire que c'est une très mauvaise solution et qu'il faudrait faire çà de manière logicielle, mais pour l'instant çà n'est pas possible pour cause de contraintes projet.

J'ai essayé ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
select data.clé,
       tbl1.montant,
       tbl2.somme
from data, 
        (select clé, nvl(montant,0) as montant 
                from couts 
                where type='d') tbl1, 
        (select clé,sum(nvl(montant,0)) as somme 
                from couts 
                where type in ('a','b','c')group by clé) tbl2
 WHERE tbl1.clé(+) = data.clé
           and tbl2.clé(+) = data.clé

En effet comme le volume de couts est imposant (celui de data aussi d'ailleurs), je me suis dit qu' en réduisant le nombre de full table access, je gagnerais en perfs, mais au contraire, les tris supplémentaires me plombent encore plus...j'ai donc cherché d'autres solutions mais à chaque fois il me faut un group by, et donc je perds plus que je ne gagne.

Quelqu'un aurais une idée, ou est ce que je peux pas faire mieux uniquement au niveau sql?
J'ai oublié de préciser: C'est sur Oracle 9i

[PpPool]

Bonjour

je n'ai que parcouru ta requete.

je pense que tu devrai regarder du coté des fonctions analytiques si tu es au moins en Oracle 9i.

pour ton pb de tri sur ta colonne type, tu devrais pouvoir t'en sortir avec les case ou les decode.

je suis désolé je suis sur le point de partir, j'essaierai de t'aider plus ce we ou lundi

[gaboo_bl]

J'ai également essayé avec une fonction analytique:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
select  distinct data.clé,
          tbl1.montant,
          sum(tbl2.montant) over(partition by data.clé)
from data, 
       (select clé, nvl(montant,0) as montant 
                from couts where type='d') tbl1, 
       (select clé,nvl(montant,0) as montant 
                from couts 
                where type in ('a','b','c')) tbl2
 WHERE tbl1.clé(+) = data.clé
       and tbl2.clé(+) = data.clé

sauf qu'avec ces jointures je récupère 4x plus de lignes, et donc je dois rajouter un distinct d'où replombage grrr

enfin peut être que je m'y prend mal je viens à peine de me mettre aux fonctions analytiques.

[remi4444]

Si tu as un index sur le couple type/clé et que tes stats sont correctement passées, je vois pas pourquoi ta premiere version de requête poserait problème... tu as le plan d'exéction ?

[orafrance]

4 produits cartésiens c'est un peu violent quand même

[gaboo_bl]

remi444 -> là est le problème justement: le plan d'execution me sort uniquement des full table access, mais étant donné qu'il s'agit des tables d'un progiciel je ne peux pas modifier le schéma pour ajouter des indexs ou des clés.

Fred_D -> effectivement à la base j'aurais conçu çà différemment, mais bien que j'eusse (çà faisait pas beau "aie" ) pensé le contraire, c'est plus rapide qu'avec le group by.