Discussion :

[comment_ca]

salut a tous ,
je voudrais avoir quelques éclaircissements à propos des procédures fonctions pl/sql.
Vu que les fonctions et procédures pl/sql peuvent aussi bien être ds une pll que stockés dans la base
quel avantage j'ai de stocker les programmes dans la base ?

Je suppose bien evidement que ça réduit le trafic réseau entre le client forms et le serveur mais j'aimerais savoir par exemple si on gagne en temps d'analyse . lorsque on crée une procédure stockée est ce que son p-code est stocké dans la base (dictionnaire) de façon que le serveur n'a pas besoin de la réanalyser ?

si j'ai une fonction ou procédure qui est indépendante des routines forms càd que je peux bien la stocker ds la base que ds une pll sur quels critères dois-je faire mon choix ?


[Modération : Titre initial ("avantage des programmes stockées ?") édité par LeoAnderson]

[plaineR]

Pour les avantages, tu trouveras un premier élément de réponse dans le guide pl/sql de Sheik :
http://sheikyerbouti.developpez.com/...?page=Chap4#L4

Après pour ce qui de savoir si je mets ma procédure dans une PLL ou si je la stocke, je me pose les questions suivantes :
- vais-je utiliser des fonctionnalités de forms ?
- ce code sera-t-il exécutable ailleurs que dans forms ?
- vais-je utiliser des fonctionnalités que forms ne reconnait pas (exemple execute immediate pour forms6i) ?
- enfin, j'aurais tendance à mettre les gros traitements dans une procédure stockée, plutôt que dans une pll...

[orafrance]

et :
- la version PL/SQL de forms ne me limite-t-elle pas
- le code est-il réutilisable (en mode batch par exemple)

[plaineR]

et :
- la version PL/SQL de forms ne me limite-t-elle pas
- le code est-il réutilisable (en mode batch par exemple)

Ce sont les 2 et 3è points que j'ai cité
J'accorde que le point 2 n'était pas très clair...

[orafrance]

ha oui, j'avais pas compris ça comme ça

[comment_ca]

merci pour le lien et les réponses
juste une dernière question : dans le lien il cite un des avantages suivants :

'Cela permet également de tirer parti de la réutilisation des requêtes dans la base qui se trouvent dans le pool partagé de la zone SGA(System Global Area) '

J'ai pas trop bien compris ce qu'il veut dire par la

cela implique t-il qu'il ya pas de réutilisation de ce qu'il ya dans le cache library pour les sous-programmes applicatifs ?

[Jaouad]

merci pour le lien et les réponses
juste une dernière question : dans le lien il cite un des avantages suivants :

'Cela permet également de tirer parti de la réutilisation des requêtes dans la base qui se trouvent dans le pool partagé de la zone SGA(System Global Area) '

J'ai pas trop bien compris ce qu'il veut dire par la

cela implique t-il qu'il ya pas de réutilisation de ce qu'il ya dans le cache library pour les sous-programmes applicatifs ?

la phase d'analyse est switché puisque le plan d'éxècution est déja en mémoire

[comment_ca]

voila ce ke je crois comprendre si c faux prière de me corriger :

Lorsqu'un sous programme est executé pour la première fois à partir d'une pll(et non pas stocké) c'est le moteur pl/sql coté client qui le prend en charge (celui du client runtime).Ce moteur divise la tache en 2 parties :
*il traite tout ce qui est instruction pl/sql lui même
*il envoie les instructions sql au moteur sql coté serveur.ces dernières seront analysées, un pcode généré et un plan d'execution pour chaque instruction seront mis ds la zone de memoire partagée(shared pool) plus exactement ds le cache library.s'ils sont mis ds le cache c pour être réutilisés en cas de re-call non ?

que ce soit à partir d'une pll ou à partir la base je vois pas la différence au niveau de la réutilisation des instructions sql.

Pour moi la seule différence pour les procédures stockés c ke c le moteur pl-sql coté serveur qui les prend en charge donc il y'a moins de trafic réseau.

[SheikYerbouti]

Pour répondre à la question initiale, voici la méthode à laquelle je m'efforce de m'astreindre concernant les procédures et Forms:

Si la proc/fonction ne concerne qu'une seule forme, je la place dans une unité de programme de la forme.
Si elle concerne plusieurs formes, je la place dans une PLL.
Si elle doit être également utilisée depuis d'autres points d'appel que Forms, je la place en base.

[comment_ca]

merci sheik c un peu plus clair dans ma tête en ce qui concerne ou je dois mettre une proc .
mais j'ai posé une autre question je tiens à avoir la réponse si possible à savoir :

etant donné que même si je n'ai pas besoin d'appeler une proc ailleurs que dans forms je peux quand même la stocker ds la base.

est ce que j'ai un avantage en faisant ça ?(mis à part la réduction du trafic réseau)

quelqun'un m'a dit qu'on gagne en temps d'analyse(parse) c à d que le serveur stocke le pcode(code analysé des requètes sql) de la prcédure dans la base
est-ce que c vrai ?

[SheikYerbouti]

Oui, mais il ne faut pas tomber dans l'excès.
Stocker une procédure en base qui n'est utilisée que pour un écran afin de gagner un quart de seconde d'exécution, ça n'a pas de sens !

Le gain de la procédure stockée se situe également dans l'utilisation de fonctionnalités coté serveur (execute immediate, bulk collect,etc...) non disponibles coté client.

[comment_ca]

merci sheik c tout ce ke je voulais savoir

[orafrance]

Stocker une procédure en base qui n'est utilisée que pour un écran afin de gagner un quart de seconde d'exécution, ça n'a pas de sens !

Attention, cet argument est assez "dangereux".

Imaginons, 100 utilisateurs qui lance 10 fois la procédure -> 0.25s *1000 = 4 minutes... si on extrapole encore on peut perdre pas mal de temps sur une journée au bout du compte

Si je dis ça c'est parce que souvent j'en entends tenir le même raisonnement concernant les requêtes SQL. Gagner 10ms sur une requête c'est rien, mais si cette requête est lancée 1 millions de fois dans la journée c'est quasiment 3h de perdue au final

[SheikYerbouti]

Stocker une procédure en base qui n'est utilisée que pour un écran afin de gagner un quart de seconde d'exécution, ça n'a pas de sens !

Attention, cet argument est assez "dangereux".

Imaginons, 100 utilisateurs qui lance 10 fois la procédure -> 0.25s *1000 = 4 minutes... si on extrapole encore on peut perdre pas mal de temps sur une journée au bout du compte

Si je dis ça c'est parce que souvent j'en entends tenir le même raisonnement concernant les requêtes SQL. Gagner 10ms sur une requête c'est rien, mais si cette requête est lancée 1 millions de fois dans la journée c'est quasiment 3h de perdue au final

Pour l'utilisateur X, il s'agit toujours d'un quart de seconde...

[orafrance]

certes mais attention aux traitements par batch qui peuvent faire des boucles sur ces requêtes unitaires qui ne prennent que quelques ms

[Jaouad]

certes mais attention aux traitements par batch qui peuvent faire des boucles sur ces requêtes unitaires qui ne prennent que quelques ms

Exactement , sous peopleSoft ( lors d'un batch ) une reqûete qui dure 3.2s a été optimisé pour gagner 1s , résultat des courses ( 1h30 heures de traitements gagnés )