Procedures stockées vs autres procedures

[links]

Bonjour,
J'aimerais savoir quelle est la différence entre procedure stockée et procedure coté client.
Mis à part le fait que ce sont des procedure sauvegardés dans la base, donc j'imagine que leur execution est plus rapide, qu'elles vont bénéficier de la sauvegarde automatique et qu'elles seront facilement partageable et gérable. Quel autre interet y'a t il a stocker les procedures et quelles sont les particularités de ces procedures ?. Y'a t il un traitement particulier pour les procedures stockées ?
Merci

[Antoun]

Si tu mets une procédure sur ton appli cliente, elle ne sera pas disponible quand tu utiliseras une autre appli cliente. Tout passer en proc stock permet ainsi de rendre la base autonome par rapport à ses applis, et de ne pas tout redévelopper dans chaque appli. De cette façon, chaque couche est mieux spécialisée sur son rôle : la couche de données s'occupe de tout ce qui est traitement des données, et la couche applicative s'occupe de l'interaction avec les utilisateurs.

[pifor]

Voir aussi ce que dit le
Application Developer's Guide - Fundamentals.

[Vincent Rogier]

L'intêret peut être réellement important.

1/ vitesse : par exemple des traitements locaux faisant intervenir plusieurs dizaines de requêtes et exécutés des milliers des fois sont passer leur temps a faire du ping pong sur le réseau et le temps final (en fonction du traitement) sera en partie du aux roundtrips client/serveur. Avec du pl/sql, les fonctions sont précompilées dans la base et donc plus (ou beaucoup moins) de ping pong. Nous avions au taf un traitement de génération pour chaque patient dans notre appli a exécuter des milliers de fois d'affilé depuis un client lourd. Nous avons passé le code (des dizaines de requetes très lourdes et mettant en oeuvre beaucoup de jointures en PL/SQL. Il ne restait que les appels du client : Résultat : la ou il fallait 30 minutes de traitement total, il ne fallai plus que 2 à 3 minutes.


2 / la réusabilité du code : nous avions notre base Oracle, un appli client serveur developpée avec un 4GL, un intranet en java, des interfaces avec d'autres systèmes en C, des pocket pc qui synchronisent avec un serveur de syncho en C++, ..
Bref, tout ce beau monde faisait plus ou moins la même chose. Mais les "même" traitements que l'on retrouvait dans les 5 vecteurs était écris chacun dans un langage différent, à des période différentes, parfois par des personnes différentes, ... Donc, au final, aucun des traitements partagés était différent !!! Impossible à maintenir et a faire évoluer !
Donc, un beau jour, nous avons pris tout le code commun, crée des packages PL/SQL, avons supprimé les anciens codes par des appels PL/SQL... Et là le bonheur : code identique depuis 5 languages et applications différentes.
En cas de bug ou d'évolution, 1 seule source à modifier et qui plus est dans un bloc note si faut ! pas re-recompilation à la chaine, ...

J'espère que cela t'aura éclairé sur les avantages des procédures stockées.
Surtout que le PL/SQL est le language serveur le plus évolué de tout ceux proposé par des SGDB.. tu faire ce que tu veux (mail, socket, xml, ....)

[Marc Musette]

Envoyé par links

Mis à part le fait que ce sont des procedure sauvegardés dans la base, donc j'imagine que leur execution est plus rapide, qu'elles vont bénéficier de la sauvegarde automatique et qu'elles seront facilement partageable et gérable.

c'est déjà pas mal

[links]

Merci à tous

[dgi77]

Un dernier truc : c'est aussi beaucoup plus facile de mener une étude d'impact dans les procédures stockées que sur des scripts stockés un peu partout sur le serveur et dont le recensement n'est jamais sûr à 100%

[mnitu]

Il y a quand même un inconvenient liée au fait que le language PL/SQL fonctionne que avec Oracle

[Antoun]

Les autres SGBD ont des dialectes SQL dynamique (T-SQL pour SQL Server et Sybase). La norme SQL prévoit même un SQL dynamique normalisé.

[mnitu]

Envoyé par Antoun

Les autres SGBD ont des dialectes SQL dynamique (T-SQL pour SQL Server et Sybase). La norme SQL prévoit même un SQL dynamique normalisé.

Désolé, mais caractériser PL/SQL voir T-SQL, etc. comme des «dialectes SQL dynamique » c'est être complètement dans le choux.
Mais peut être j'ai raté quelque chose ...

[Antoun]

Envoyé par mnitu

Désolé, mais caractériser PL/SQL voir T-SQL, etc. comme des «dialectes SQL dynamique » c'est être complètement dans le choux.

Pourquoi ? Le SQL est statique, le PL/SQL est en la partie dynamique sous Oracle (donc un dialecte) et le T-SQL est son équivalent sous SQL Server.

[Vincent Rogier]

Excusez moi, mais on ne peut pas comparer PL/SQL et T-SQL.

Le PL/SQL est language devenu au fil du temp "généraliste" et il est désormais possible de tout faire et de coder des application entières 100% PL/SQL avec support complets de toutes fonctionnalités des 4GL et outils actuels (xml, mail, socket, math, file I/O, ...)

MS T-SQL est de loin moins puissant. C'est un peu le parent pauvre des languages procéduraux serveurs des SGDB

[pifor]

Du point de vue Oracle, il ne faudrait pas parler de SQL dynamique pour PL/SQL car le SQL dynamique a un sens particulier. Le standard de langage de procédures stockées s'appelle SQL/PSM: Persistent Stored Modules. Je pense qu'il faudrait plutôt parler de language de procédures stockées.

Historiquement, PL/SQL est très proche du langage ADA, langage conçu par une société française qui avait remporté un appel d'offre du ministère de la défense américain dans les années 80 afin d'unifier tous les langages de programmation de toutes les applications (gestion, temps réel embarqué, etc.).

[mnitu]

Envoyé par Antoun

Pourquoi ? Le SQL est statique, le PL/SQL est en la partie dynamique sous Oracle (donc un dialecte) et le T-SQL est son équivalent sous SQL Server.

SQL = langage non procédural
PL/SQL (T-SQL) langage procédural ou "extensions procédurales" du SQL

[orafrance]

Envoyé par vicenzo

Le PL/SQL est language devenu au fil du temp "généraliste" et il est désormais possible de tout faire et de coder des application entières 100% PL/SQL avec support complets de toutes fonctionnalités des 4GL et outils actuels (xml, mail, socket, math, file I/O, ...)

non, le PL/SQL ne permet pas d'avoir une interaction avec l'utilisateur

[Vincent Rogier]

Qui parle d'interaction utilisateur ??

Pas moi... Quand je parle d'application, c'est tout le code applicatif, fonctionnel, métier, traitement, communication, échanges, ....

Il est évident que PL/SQL ne gère pas de fenêtre Windows, etc...

Ecrans de saisie mis à part , des applications peuvent être entièrement codées en PL/SQL.

[Antoun]

Envoyé par pifor

Du point de vue Oracle, il ne faudrait pas parler de SQL dynamique pour PL/SQL car le SQL dynamique a un sens particulier. Le standard de langage de procédures stockées s'appelle SQL/PSM: Persistent Stored Modules. Je pense qu'il faudrait plutôt parler de language de procédures stockées.

Ah, je connaissais pas cette spécificité Oracle. J'utilisais le terme "dynamique" par opposition au SQL statique, càd sans variables, sans boucles, etc.

[mnitu]

Envoyé par Antoun

Ah, je connaissais pas cette spécificité Oracle. J'utilisais le terme "dynamique" par opposition au SQL statique, càd sans variables, sans boucles, etc.

Faut-il comprendre que toutes les langages qui utilisent des boucles, des variables, etc. sont des langages dynamiques ? Pourriez-vous nous indiquer le(s) lien(s) où ce terme est défini ou employé de la façon que vous le fait ?

[Antoun]