Curseur explicite vs cursor implicite

Version imprimable

04/12/2013, 22h38
devkais

Curseur explicite vs cursor implicite

bonjour ,
en termes de performances , de normalisation et de maintenance qu'elle est le meilleur choix dans un bloc PL/SQL :

Curseur implicite ou explicite.
avantages et inconvénients de chacun ?
merci
05/12/2013, 09h55
mnitu

Un curseur implicite ou explicite reste un curseur! Si ce sujet vous intéresse lisez l'article "doing sql from pl/sql worst and best practices" sur OTN.
05/12/2013, 10h36
pacmann

Salut,

Le curseur explicite permet de faire bulk collect, puis for all.
S'il n'y a pas de mise à jour d'insertions directes à faire, le curseur implicite fait un bulk fetch automatique (je crois paramétré à 100) depuis 10g je crois...

Le curseur implicite est plus léger en terme de lisibilité et écriture de code.
C'est ce que je privillégie pour faire des choses simples et pas trop volumineuses.
05/12/2013, 15h38
mnitu

Le curseur qu’il est implicite ou explicite permet de remplir une collection via le bulk fetch. L’instruction ForAll s’applique aux collections peu importe comment elles ont été remplies (via un curseur ou construite "manuellement").
L’optimisation que PL/SQL fait par-dessous de la table dans une boucle For utilisant un curseur implicite n’est pas synonyme de remplissage d’une collection mais c’est plutôt un « array fetch ».
Cela étant dit il y a des différences bien plus subtiles que ça d’où ma recommandation de lire l’article.
05/12/2013, 16h21
pacmann

Oui tu as raison Mnitu sur le forall, il est parfaitement possible d'alimenter à la main sa collection.

Sur le curseur implicite, je sais bien que ça remplit pas automatiquement une collection, c'est pour ça je disais "bulk fetch" :lol:
... cela dit, en soi, le principal intérêt du bulk collect est l'array fetch, non ?
05/12/2013, 17h10
mnitu

Bref, si vous pensez que

Citation:

Envoyé par pacmann

...
Sur le curseur implicite, je sais bien que ça remplit pas automatiquement une collection, c'est pour ça je disais "bulk fetch" :lol:

alors vous ne pouvez pas non plus dire

Citation:

le curseur implicite fait un bulk fetch automatique (je crois paramétré à 100)
06/12/2013, 09h55
pacmann

Je ne vois pas pourquoi...
Bulk, ça veut juste dire "en masse".
Utiliser le mot "bulk" à la place de "array" est au pire maladroit par rapport aux habitudes, mais je pense pas que cela soit pour autant une terrible aberration...

http://asktom.oracle.com/pls/asktom/...:4696422878211

Citation:

Envoyé par oncle tom

Followup May 20, 2005 - 6pm UTC:

only with refcursors if you are forced to use dynamic sql.

and in 9ir2 and before when you need bulk collect (which you don't need in 10g as it bulk collects
100 rows at a time for you automagically)

Pensez vous que ces deux requêtes font du

Citation:

bulk fetch automatique (je crois paramétré à 100)

Code:

1
2
3
4
5
 
Select ename 
  Into l_ename
  From emp
 Where empno = 7369

Code:

1
2
3
4
5
6
7
8
9
10
 
Declare
  Type all_objects_nt Is Table Of all_objects%RowType;
  tab_all_objects     all_objects_nt;
Begin
  Select *
    Bulk Collect Into tab_all_objects
   Where rownum <= 1000; 
End;  
/

06/12/2013, 11h15
pacmann

Vous jouez sur le fait que tout DML "est" (utilise) un curseur, et en cela vous avez évidemment raison.

J'ai interprété la question postée comme "dois je explicitement ouvrir mes curseurs, fetch et fermer ou plutôt utiliser des FOR ... LOOP...". Je pense avoir raison, mais quoi qu'il en soit, je ne suis pas certain que la suite de cette discussion ait vraiment un grand intérêt.

Bref, si c'est ce qui vous importe, je veux bien le redire : "vous avez raison"... voilà !
06/12/2013, 14h05
mnitu

Citation:

Envoyé par pacmann

...
Bref, si c'est ce qui vous importe, je veux bien le redire : "vous avez raison"... voilà !

Si le sujet vous intéresse passez un peu des temps à lire l’article évoqué et après revenez sur ce fil de discussion pour nous dire si vous avez changé d’avis ou pas.
06/12/2013, 17h25
pacmann
Merci Mnitu pour le lien, très intéressant en effet, et recommander sa lecture est une bonne chose, même si c'est quand même un joli pavé.

1) Maintenant, voyons voir ce que ce document dit :
A. Ceci est un explicit cursor :
Code:

1 2 3 4 5 -- Code_22 Explicit_Cursor_vs_Cursor_Variable.sql for r in Pkg1.Cur_Proc(PK=>Some_Value)loop Process_Record(r); end loop;
Notez que dans la communauté, la définition de ce qu'est un explicit cursor n'est pas claire :
http://asktom.oracle.com/pls/asktom/...:1584829077861

Notez également que même le document est un peu inconsistant sur ce qu'est un implicit cursor :

Citation:

... It is the PL/SQL runtime system, reflecting the analysis done by the PL/SQL compiler, that manages the session cursor without the help of explicit language constructs that specify operations like open, parse, bind, execute, fetch and close.

... et pas très précis sur ce qu'est un explicit cursor :

Citation:

While the words suggest that this might be the natural opposite of an
implicit cursor this is not the case43. An explicit cursor is a specific PL/SQL
language feature — and the term belongs, therefore, firmly in the overt
domain. The identifier Cur_Proc, declared in the spec of package Pkg1 in
Code_20, denotes an explicit cursor

=> Cela voudrait donc dire que le simple fait de déclarer une variable cursor rend le cursor explicite ? Je pense que de gens l'ont compris ainsi... bref.

B. Ce best practice indique tout simplement de ne pas utiliser l'explicit cursor for loop.

Citation:

... from Oracle Database 10g, the explicit cursor for loop is significantly faster than the infinite cursor fetch loop... However, we shall see that all this is of no practical intereste because neither approach is ever preferred to batched bulk fetch or entire bulk fetch

Voilà, l'avis est donné, ce passage suffit finalement à répondre à la question. Maintenant, on peut avoir un avis différent, comme le mien, ou celui (moins important) de Tom Kyte (cf le lien ci-dessus, mais on peut en trouver d'autre).

2) Et le posteur dans tout ça ?

Finalement, on se débat pour savoir qu'est-ce qu'un implicit cursor, un explicit cursor. Je vois que vous vous délecter à débattre entre Overt et Covert comme dirait le document.
Parce qu'il est bien là le problème de vocabulaire : le mot "cursor" à une signification très particulière dans le covert Oracle, mais dans le monde du développement, surtout si on regarde un peu plus loin qu'Oracle, il revet une signification plus large, différente.

Alors quel est votre but ?
Me prendre de haut, m'humilier ?
=> Bravo, ça marche bien, preuve étant l'effort que je mets dans la présente réponse.
Vous montrer d'une élite Oraclienne et remballer ceux (intervenants OP et "aideurs") qui n'utilisent pas les terminologies exactes ?
=> Cela vous relègue au niveau de SQLPro et ses éternelles vannes (entre autres) sur les champs et les enregistrements, c'est bien dommage.

Parce que je repose la question : selon vous, l'OP cherchait-il le plus probablement à savoir la différence entre curseur EXPLICIT CURSOR FOR LOOP, le BATCHED BULK FETCH et un INFINITE CURSOR FETCH LOOP, ou cherchait-il un long débat de spécialistes sur l'overt et le covert ?

Comme dit, c'est bien dommage, parce qu'on vaut plus que ça. D'ailleurs, je vais finir de lire le document que vous avez recommandé (j'en suis à la moitié)
09/12/2013, 10h16
mnitu

Si en relisant votre première intervention (et les suivantes) vous pensez toujours que c’est la (bonne) réponse vous avez raison,

Citation:

c’est bien dommage

nous avons tous perdu le temps ici.
11/12/2013, 16h15
devkais

Curseur explicite/ implicite & Performances

Pour récapituler ,hormis la différence côté normes , lisibilité , options offertes par chacun et simplicité d'écriture existe-t-il une vrai différence point de vue performances entre un curseur EXPLICITE et IMPLICITE ?
11/12/2013, 16h51
mnitu

Citation:

cursor
A handle or name for a private SQL area in the PGA. Because cursors are closely associated with private SQL areas, the terms are sometimes used interchangeably

Donc un pointer/identifiant d'une zone de mémoire privé.

Citation:

private SQL area
An area in memory that holds a parsed statement and other information for processing. The private SQL area contains data such as bind variable values, query execution state information, and query execution work areas.

Une zone de mémoire qui contient une instruction SQL après compilation (parsing) et des autres information connexes.

Curseur explicite: le programmeur PL/SQL écrit les instructions nécessaires à sa gestion.
Curseur implicite: le compilateur PL/SQL ajoute les instructions nécessaires à sa gestion.

Donc un curseur ça reste un curseur.