[FORMS] Procédure stockée ou PLL ?

Version imprimable

14/04/2005, 12h50
comment_ca

[FORMS] Procédure stockée ou PLL ?

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]
14/04/2005, 13h06
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...
14/04/2005, 13h12
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)
14/04/2005, 14h18
plaineR

Citation:

Envoyé par 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)

Ce sont les 2 et 3è points que j'ai cité :wink:
J'accorde que le point 2 n'était pas très clair...
14/04/2005, 14h29
orafrance

ha oui, j'avais pas compris ça comme ça :oops:
14/04/2005, 16h05
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 ?
14/04/2005, 16h09
Jaouad

Citation:

Envoyé par 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 ?

la phase d'analyse est switché puisque le plan d'éxècution est déja en mémoire
14/04/2005, 18h04
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.
14/04/2005, 23h06
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.
15/04/2005, 10h48
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 :D à 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 ?
15/04/2005, 10h53
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.
15/04/2005, 11h14
comment_ca

merci sheik c tout ce ke je voulais savoir
15/04/2005, 12h10
orafrance

Citation:

Envoyé par 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 ;)
15/04/2005, 12h27
SheikYerbouti

Citation:

Envoyé par orafrance

Citation:

Envoyé par 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...
15/04/2005, 14h36
orafrance

certes mais attention aux traitements par batch qui peuvent faire des boucles sur ces requêtes unitaires qui ne prennent que quelques ms ;)
15/04/2005, 14h43
Jaouad

Citation:

Envoyé par orafrance

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 )