Discussion :

[goute]

Bonjour,

Il y a deux façons d'utiliser les curseurs explicites :

-La premiere avec les 4 etapes cursor open fetch close ...

-La seconde avec le LOOP FOR


J'ai envie de dire la première est plus laborieuse, pourquoi continuer à l'utiliser ??
Qu'elle façon choisir ?
Il y a t'il encore une bonne raison d'utiliser la première ?
Est ce pour des raisons historiques ou il y a t-il vraiment un intérêt à utiliser la première ?

De grandes questions

Merci pour votre intérêt.

Bye

[mnitu]

En réalité les 4 étapes sont toujours présentes

Code :

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

1
2
3
4
5
 
Declare
Ouverture
Fetch
Close

ce qui diffère est juste qui fait le boulot: le développeur ou le compilateur.

Aujourd'hui il y a 3 cas d'utilisation:
- recherche d'une seul enregistrement: la solution Select ... Into...
- recherche d'un nombre limité et connus d'avance des enregistrements (ex. lignes d'une commande): Select ... Bulk Collect Into
- recherche d'un nombre inconnu des enregistrements: Cursor et Fetch en Bulk

Tous les autres structures existent seulement pour des raisons historiques ou quelque cas limites et marginaux.

Pour plus des informations cherchez l'article de Bryan LLewellyn : Doing sql from pl/sql

[goute]

On est bien d'accord. Je me suis mal expliqué.

Je parle du cas "- recherche d'un nombre inconnu des enregistrements: Cursor et Fetch en Bulk"

On a deux façons d'utiliser les curseurs :

-Avec Declare Ouverture Fetch Close...

ou

-Avec FOR var_iteration IN mon_curseur LOOP [...] END LOOP;

Et la ma question c'est pourquoi utiliser une façon et pas l'autre ? et je trouve la deuxième manière vraiment plus simple alors pourquoi je devrais m’embêter à connaitre encore la façon avec le fetch ??

ahah

Merci

[skuatamad]

FOR LOOP est la syntaxe préconisée depuis des années pour sa simplicité.
OPEN reste nécessaire pour faire du BULK COLLECT (et paramétré le LIMIT) ou pour du SQL dynamique, ou pour une procédure avec paramètre curseur en sortie.

difference between cursors for loop and normal explicit cursors

[goute]

Merci beaucoup pour ces éléments !! Ça répond à ma question

[mnitu]

Le principe de rasoir d'Occam ne fonctionne pas toujours!

La boucle for implicite a été optimisée à partir de la version 10.1 ou 10.2. Avant ce type de traitement était dans la catégorie "row by row is slow by slow". Et la raison de son optimisation a été précisément cet aspect. Donc à partir de cette version cette structure de programmation a été optimisée pour travailler par lot de 100 c'est à dire cela corresponde à un Bulk Fetch avec la limite de 100. Et si ma mémoire est bonne comme toute optimisation "automagique" elle fonctionne que si l'optimiseur a le niveau d'optimisation approprié.

Considérer que 100 est la bonne valeur dans toutes les cas s'apparente à la légende du lit de Procuste.

Et de plus cela n'oblige pas le programmeur feignant à utiliser les collections ce qui est "la solution" des problèmes PL/SQL d'optimisation des traitement.

Pour récapituler:
- select d'un enregistrement : select ... into <Record>
- select de N enregistrements ou N <= 2000 enregistrements: Select ... Bulk Into <Colection des Records>
- select des N enregistrements ou N > 2000 enregistrements : Declare cursor ...Bulk Fetch Into <Colection des Records>

Bref comme toute autre valeur le "2000" c'est à prendre avec les pincettes, ça peut être 100 ça peut être 5000. Au delà la gestion de la mémoire prendre le dessous sur les bénéfices.

Lisez le document cité, vous allez apprendre pas mal des choses.