Discussion :

[chrifo]

Oracle 9i

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

Code :

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

1
2
3
4
5
declare
  toto number(1);
begin
  select 1 into toto from dual;
end;

et :

Code :

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

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;

[chrifo]

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 ==> il y a donc apparemment une différence de perf entre les 2 écritures

[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.

[McM]

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

[chrifo]

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 ...

[LeoAnderson]

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

[Magnus]

D'accord, autant pour moi
Toutes mes excuses

[chrifo]

D'accord, autant pour moi
Toutes mes excuses

Pas de problème

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.

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.

[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 !

[chrifo]

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 !

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"

[LeoAnderson]

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 !

[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 explicite.

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

[chrifo]

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
Merci à tous pour vos réponses