Discussion :

[Lagnio]

Bonjour,

Je dois ré-écrire une requete un peu longuette... (704 lignes de pure bonheur)

Dans cette requete j'ai 10 sous-requetes, ma question est la suivante, ne serait-il pas plus facile a maintenir si en place de chaque sous-requete je mettais une petite fonction retournant une table.

Ou serait-il préférable de passer par des vues (lorsqu'elles ne sont pas paramétrées)?

Idem, au niveau du select, j'ai des joli case énorme, donc ne vaut-il pas mieux les remplacer eux aussi??

Merci pour vos conseils!

[al1_24]

Et pourquoi pas utiliser une expression de table commune (Common Table Expression) ou plusieurs si nécessaire ?

[JeanYvette]

Je rajouterais, outre ce qu'à dit al_1 sur les CTE (les CTE, c'est la vie, n'oubliez jamais ça) qu'Oracle fonctionne mieux en curseur qu'en ensembliste (je l'ai revu il y a peu à mes dépends...) et que en fonction de comment ta/tes requêtes sont faites, parfois, les disséquer pour en sortir des curseur ?

A voir comment le code est fait quoi, sans, on ne peut que faire des hypothéses (bon d'un côté, lire 700 lignes, ça vend pas forcement du rêve)

Après, le mieux serait peut être aussi de dissequer/prendre les requêtes une a une, voir le plan d'exécution si y'en a une ou plusieurs qui ne sont pas opti...

Bisous bisous

[vanagreg]

Je rajouterais, outre ce qu'à dit al_1 sur les CTE (les CTE, c'est la vie, n'oubliez jamais ça) qu'Oracle fonctionne mieux en curseur qu'en ensembliste (je l'ai revu il y a peu à mes dépends...)
Bisous bisous

Bonjour,

Tu as un exemple pour comparer parce que c'est le contraire en fait? Un curseur qui fait du ligne à ligne sera plus lent qu'une requête qui traite tout d'un coup.

[Lagnio]

Merci pour vos réponses.

Envoyé par JeanYvette

Après, le mieux serait peut être aussi de dissequer/prendre les requêtes une a une, voir le plan d'exécution si y'en a une ou plusieurs qui ne sont pas opti...

La je peux confirmer que c'est bien le cas, les sous-requetes en double, les 2 similaires mais sur des tables différentes, bon j'en passes...

en exemple de sous-requete j'ai :

Code :

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

1
2
3
4
5
6
select ac.num_cpt "A", round(sum(balance)/max(valuation),2) "B"
 from  compte c,  propriete p
where c.num_prop=p.num_prop
and   c.type = 'M'
and   c.period='31-dec-19'
group by c.num_prop

et je l'ai en double puisque j'ai besoin de la meme info pour le mois de novembre

de plus, toute les tables utilisés dans la sous-requetes sont présentes dans la requete principale.

Les sous-reauetes sont jointes par le numéro de compte a la requete principale.

mon but est juste que quand je partirai, mon remplacant ne s'arrache pas les cheveux a essayer de comprendre ce que j'ai bien pu fabriquer!

Voila, voilou!

[vanagreg]

de plus, toute les tables utilisés dans la sous-requetes sont présentes dans la requete principale.
Les sous-reauetes sont jointes par le numéro de compte a la requete principale.

Dans ce cas tu certainement mutualiser avec un bloc WITH, des CASE et des fonctions analytiques.

[JeanYvette]

Bonjour,

Tu as un exemple pour comparer parce que c'est le contraire en fait? Un curseur qui fait du ligne à ligne sera plus lent qu'une requête qui traite tout d'un coup.

Un exemple purement personnel. J'avais une requête assez importante, qui utilisez des CTE et des index. Elle était lente, mais lente... (Bon après je soupçonne aussi la base car la même requête mettait, en 30 minutes d'écart, 10 secondes une fois contre 380 une autres...)
J'ai fait la même requête, en terme d'algo, en curseur, ca tourne super bien. Ca me sidère parce que je suis du même avis que toi, mais j'ai eu plusieurs cas qui se sont passés comme ça...

Après, et c'est un fait, Oracle gère mieux les curseurs que d'autres SGBD...




Sinon, pour en revenir au problème actuel. Une requête en double doit clairement être mise dans une CTE (la petite clause WITH, au cas où ce nom ne te parle pas)
Ensuite, deux sous-requête similaires mais sur des tables différentes, bon beh tant pis j'ai envie de dire

[vanagreg]

Bonjour,

Ce n'est pas parce qu'une requête est longue qu'elle est problématique. Pourquoi dois-tu la réécrire? Pose-t-elle des problèmes de perf?
Pour commencer il faudrait que tu montres la requête en question.