Application : Les procedures stockées sont-elles inévitables ?

[nytmare]

Salut gurus
Durant mon experience, J'ai travailler chez 2 compagnies qui concoivent leur system informatique de la facon suivante:
un ensemble de jsp qui pointent vers une classe java, cette derniere etablie une connexion a une base de donnee, puis pour chaque requete specifique de la page il existe une methode . chaque methode n'est en faite qu'un exec d'une procedure stocke oracle ou sqlserver qui recupere un recordset. puis le transfert vers l'IHM.
Je me pose les questions suivantes :
Es que c'est le meme shema de developement ailleurs (je parle du principe)?
Es que la logique metiers es innevitablement regis par des procedures stocke?

Par logique metiers j'entend des requete complexes sur la base, pour les resoudre je fait intervenir des curseurs, des loop des requetes imbriques ou bien meme des table temporaire.

J'entend bcp parler de persistence objet relationelle (j'en ai personellement construit un mais mon system ne contenait pas de requetes complexes donc c'etait vraiment du ORM basic) alors je me demande si les frameworks actuels permetent de construires des methodes metiers complexes.

pour resumer , est il innevitable de constuire sont system autour de procedures stocke ou bien je suis, ainsi que les compagnies pour lesquelles j'ai travailler completement dephaser. Si c'est le cas alors please orienter moi , sinon je me demande vraiment a quoi sert toutes ses couches d'abstractions et frameworks si finalement le coeur du system est embarque sur la DB.

merci beaucoup

[Xo]

Pour une appli mono-SGBD, ça n'est pas requis, tu peux faire tes SELECT, INSERt & co via des commandes SQL,

Pour une appli multi-SGBD, vu que le SQL est une norme que chaque éditeur reprend plus ou moins à sa sauce, la moindre requêtre SQL va être propres à un SGBD : dans un tel cas, la seule solution viable est effectivement de tout encapsuler dans des procédures stockées.

[nytmare]

Donc vous evitez les SPs ?
Comment vous faites pour remplacer les curseurs ?

pouvez vous me donnez des cas pratiques, des best practices pour faire le bon choix entre codage de la business layer ou bien encapsulation dans des SPs sur les projets SI.

encore une fois je tiens a preciser que c'est dans le cas de requettes complexes .

merci

[Xo]

Envoyé par nytmare

Donc vous evitez les SPs ?

Non. En ce qui me concerne, je travaille sur une appli mono SGBD, Oracle en l'occurence, mais qui peut être attaquée par des clients lourds (VB6) et plus récemment léger (PHP) : sur les parties communes, les procédures/fonctions stockées (ou plus exactement les packages) offrent l'avantage de centraliser les règles de gestion métier, directement au coeur de la BDD !

Envoyé par nytmare

Comment vous faites pour remplacer les curseurs ?

La question est un peu floue, pourriez-vous la préciser ? Vous parler de curseurs renvoyés par une fonction stockée ? Pour l'affichage de données, des vues ou mêmes de simples SELECT me suffisent dans la plupart des cas

Envoyé par nytmare

pouvez vous me donnez des cas pratiques, des best practices pour faire le bon choix entre codage de la business layer ou bien encapsulation dans des SPs sur les projets SI.

encore une fois je tiens a preciser que c'est dans le cas de requettes complexes .

Moi, non, je n'ai pas assez de bouteille pour cela .
Je pense que cela peut dépendre du type d'appli sur lequel vous travaillez. Les réponses peuvent varier selon les volumes de données lus / mis à jour, par exemple.
Des traitements centralisés sur le serveur seront plus performants, mais avec une gestion d'erreur plus complexe/délicate. Et d'un autre côté, si l'appli est utilisée par un grand nombre d'utilisateurs, cela ne sera pas viable puisque le serveur sera plus facilement surchargé.

[Mercure]

Il faudrait d'abord savoir ce que sont les procédures stockées et à quoi bon peuvent-elles servir ?

Je répondrai à cette question par un extrait de la doc .PDF que tu pourras trouver à cette adresse chez Big Blue et qui t'en dira beaucoup plus long sur les procédures stockées et en détail.

http://www.redbooks.ibm.com/abstract...6503.html?Open

Un exemple typique montrant comment les procédures stockées peuvent être vraiment efficaces.



Une société fait tourner ses programmes de gestion d'une part sur un serveur dans les locaux de sa maison-mère et d'autre part sur des systèmes client dans chaque succursale. Un utilisateur dans une succursale travaille sur l'application facturation pour solder une facture, ce qui implique la mise à jour de trois tables sur le serveur:
- La table facture (INVOICE)
- La table client (CUSTOMER)
- La table des comptes client (ARBLNCE).
Un flag dans l'enregistrement dans la table facture est marqué "soldé".

L'enregistrement client correspondant est mis à jour suite à déduction du montant de la facture sur le montant dû.
L'enregistrement compte client correspondant est à son tour mis à jour par déduction du montant de la facture sur le compte courant.

Le diagramme en figure 4-1 (en haut de l'image) montre l'application telle qu'implémentée sans avoir eu recours aux procédures stockées.

Le poste client en succursale doit accéder plusieurs fois à la BDD sur le serveur pour faire chaque mise à jour, en envoyant et recevant les données sur les lignes de communication lors de chaque requête. De plus, toute la logique d'application, la programmation, est implémentée sur le site client.

La figure 4-2 (en bas de l'image) nous montre comment nous pouvons tirer parti des procédures stockées lors du développement de cette application.

Les mêmes fonctionnalités peuvent être mises à exécution en appelant une simple procédure stockée qui tourne sur le serveur.
Le dialogue est grandement réduit sur les lignes de comm et les ressources réseau bien mieux équilibrées par le partage de la logique d'application.

(réponse originale : http://as400.free-bb.com/sujet-18479...erche-etc.html)