[PL/SQL] Cout ouverture d'un curseur

Oracle 9i

Bonjour,
une fois le code compilé, y a-t-il une différence fondamentale entre ces 2 écritures ? :

Code:

---

1 2 3 4 5

declare toto number(1); begin select 1 into toto from dual; end;

---

et :

Code:

---

1 2 3 4 5 6 7 8

declare cursor c_toto is select 1 from dual; toto number(1); begin open c_toto; fetch c_toto into toto; close c_toto; end;

---

http://www.editions-eyrolles.com/Cha...893b98f6fc6d00
C'est un ouvrage 10g, mais j'imagine que cela s'applique à la 9i.
Il y est dit que les curseurs implicites sont moins performants que les explicites 8O ==> il y a donc apparemment une différence de perf entre les 2 écritures

Votre 1er exemple n'utilise pas un curseur donc votre comparaison n'a pas de sens !!!!

Si votre requête ramène une seule ligne (a priori => cf l'exception WHEN TOO_MANY_ROWS) alors vous utilisez votre 1er exemple.
Si vous devez récupérer un ensemble de lignes (au moins une mais pas nécessairement plus) alors vous utilisez un curseur donc le 2ème exemple.

2 problématiques différentes, 2 solutions différentes.

Vu qu'on ne parle pas de lisibilité de code, mais de perf pure du moteur plsql, tu peux faire le test avec DBMS_PROFILER.
Moi je peux pas, il n'est pas installé, il n'est pas installé non plus sur APEX.
http://fdegrelle.over-blog.com/article-1012629.html

Citation:

---

Envoyé par Magnus

Votre 1er exemple n'utilise pas un curseur donc votre comparaison n'a pas de sens !!!!

Si votre requête ramène une seule ligne (a priori => cf l'exception WHEN TOO_MANY_ROWS) alors vous utilisez votre 1er exemple.
Si vous devez récupérer un ensemble de lignes (au moins une mais pas nécessairement plus) alors vous utilisez un curseur donc le 2ème exemple.

2 problématiques différentes, 2 solutions différentes.

---

Euhhh ... Votre réponse n'est-elle pas précipitée ?

Je considère dans ma question le cas ou l'on ramène une seule ligne, et en ma connaissance, un "select into" ouvre un curseur implicite ... d'où ma question tordue ...

Oui oui, un select ouvre bien un curseurs au sens v$open_cursor et max_cursors ! ;)

D'accord, autant pour moi :oops:
Toutes mes excuses

Citation:

---

Envoyé par Magnus

D'accord, autant pour moi :oops:
Toutes mes excuses

---

Pas de problème :D

En fait la norme de dév. d'un produit sur lequel je bosse en TMA en ce moment impose l'utilisation de la 2e syntaxe ... Je cherche à comprendre pourquoi, mais il existe certainement des raisons liées à l'historique de l'applicatif.

Citation:

---

Envoyé par McM

tu peux faire le test avec DBMS_PROFILER.

---

DBMS_PROFILER n'est pas installé ici non plus, merci pour l'info, je ferai le test à l'occasion.

Simple : l'exception TOO_MANY_ROWS ne sera jamais déclenchée et ça leur évite de faire des WHERE ROWNUM=1 s'ils ont codés comme des pieds ! :roll:

Citation:

---

Envoyé par LeoAnderson

Simple : l'exception TOO_MANY_ROWS ne sera jamais déclenchée et ça leur évite de faire des WHERE ROWNUM=1 s'ils ont codés comme des pieds ! :roll:

---

Je ne pense pas, ils n'auraient pas fait ça sur les selects avec recherche sur la PK, ou les requetes de type "select max() from"

Sur les PK, si car rien ne dit que la PK d'aujourd'hui le sera demain.
et sur les max( ) ? pourquoi pas, ils le font partout !

autant avoir une règle simple, comme ça le contrôle qualité n'a pas à chercher à comprendre le code et on peut même l'automatiser par scripts !

Selon Tom Kyte, en général les curseurs implicites sont plus rapides que les curseurs explicites car il y a moins de code interprêté PL/SQL à exécuter qu'avec un curseur explicite.

Il faut aussi savoir qu'en interne toute requête SQL créé un curseur interne d'après le Concepts Guide .

Citation:

---

Envoyé par pifor

Selon Tom Kyte, en général les curseurs implicites sont plus rapides que les curseurs explicites car il y a moins de code interprêté PL/SQL à exécuter qu'avec un curseur implicite.

---

Ah bah oui :D
Merci à tous pour vos réponses :king: