Logique métier stockée en PL SQL ou en service Java ?

Bonjour,

Désolé si je ne poste pas dans la bonne section du Forum. Après avoir hésité entre plusieurs section (Java, Oracle, etc.) j'opte pour celle ci.

Voici mon problème
Je travaille sur une application client/serveur hors d'âge développée en NSDK et dans laquelle:
- les données sont stockées en BDD Oracle et sont manipulées par des procédures stockées
- les écrans ont été développé avec de la logique métier dedans

La stratégie de la société est :
- dans un premier temps de migrer toute la logique métier dans des procédures stockées sous Oracle
- dans un second temps de migrer l'application sous Java en ne l'utilisant que pour l'affichage des écrans, mais en conservant toute le métier dans les procédures stockées

J'ai tellement l'habitude de travailler avec des applis Java dans lesquelles la BDD ne contient que des données et où la logique métier est contenue dans des services, que cette façon de stocker la logique métier sous forme de procédures stockées me choque. Malheureusement je n'arrive pas à trouver de raison valable ni d'argument objectif pour défendre ce point de vue.
Le seul que j'ai trouvé est : "Attention, si un jour Oracle disparaît, vous perdez tout votre métier !". Il m'a été répondu qu'Oracle détenait Java, et donc si Oracle disparaît, Java aussi. 1 point partout :aie:

Voici donc ma question :
dans une appli Java Web n-tiers, est-ce bien ou mal de stocker la logique métier uniquement en base sous forme de procédure stockée ?
Avez-vous des liens web ou une expérience passée pour étayer votre avis ou qui détaille les avantages et inconvénient de ce choix d'architecture ?

Merci d'avance.

Comme d'habitude, il n'y a pas de règle absolue qui va dire "il faut faire comme cela"

Avec SQL Server, j'ai mis 80% de la logique métier dans les procédures stockées.

Avantages :
dans la maintenance : on centralise les rectifications / évolution de procédure.
dans l'exécution de grosses requêtes : les PS sont beaucoup plus performantes à partir de gros volumes (quelques milliers de lignes).

Par ailleurs, l'application cliente s'attend à recevoir toujours les mêmes données.
De sorte que si la structure de la base évolue, c'est le programmeur de procédure stockée
qui fait évoluer sa procédure en même temps que ses tables.

Si le type de client change (par exemple on passe de Java Swing à JSF) la procédure stockée ne change pas.

Inconvénient :
ça multiplie les procédures et si on n'est pas rigoureux dans la codification des noms de proc c'est rapidement le pastis :aie:

On a parfois recours à une PS pour presque rien et dans certains cas (petite quantité de données),
c'est contre-productif car java ferait le traitement mieux qu'une PS.

Perso, je ne mettrais pas 100% de la logique métier dans les PS.
Après, lors du changement de client (qui fini toujours par arriver) il faut pouvoir recenser ce qu'il faut migrer.

Bonjour,

Je pense que tu es au bon endroit pour poster.

Aujourd'hui, et depuis l'avènement du N tiers on recherche les couplages lâches et c'est bien là, la signification du mot Tier que l'on doit traduire par couche :

• couche présentation
• couche service
• couche métiers
• couche persistance

Donc en théorie pas de métier dans la base de données

Tu veux des arguments, en voila :

• les procédures stockées obligent la direction à conserver une compétence en PL/SQL
• si tu récupères d'autres projet sous Sybase ou SQL Server dois avoir des compétences en Transac SQL ou si tu veux migrer tes serveur de données d'oracle vers Postgresql tu devras apprendre encore un autre langage le PL/pgSQL
• tes spécifications sont peut être modélisées en UML. Comment tu fais correspondre tes diagrammes de classes, séquences ... avec tes procédures stockées.
• si en java tu test avec Junit, tu fais comment en PL/SQL
• on découple pour avoir une architecture souple, par exemple pour passer en Web Service. mais il n'y a pas de web service écrit en PL/SQL

En espérant que ca te suffise

A bientôt,

Marc.

Bien que je ne l'ai jamais fait par manque de connaissance, oui, la DB est une bon endroit pour stocker du métier. Après tout, dès que tu met une contrainte de clé étrangère sur une table, c'est de la logique métier, tu as décidé que le métier interdisait des éléments sans parent, des montants négatifs, des heures nulles, etc. Quand tu crée des vues pour te faciliter le travail, même chose, tu ramène du métier pour préciser comment les constuires. Les procédure stockées, cela permet juste d'aller bien plus loin dans la préparation de tes données. Ca n'a rien de choquant et je préfère mille fois mieux avoir un DBA qui prépare les procédures stockées qu'un dev qui rapatrie 10x trop de données.

Citation:

---

Envoyé par heroined

Le seul que j'ai trouvé est : "Attention, si un jour Oracle disparaît, vous perdez tout votre métier !". Il m'a été répondu qu'Oracle détenait Java, et donc si Oracle disparaît, Java aussi. 1 point partout :aie:

---

Franchement, l'argument n'est pas génial. A la limite, tu aurais pu dire "si on veut changer de BDD par exemple MySQL ou SQL server". Tu aurais eu la réponse "bah on veut pas changer de BDD". Et ca revenait au meme.

Non, pour moi, le vrai argument, comme presque toujours en informatique, c'est la maintenance du système. Le problème d'utiliser des procédures stockées est que tu crées un lien fort entre la procédure et les applis qui l'utilisent. Ca veut dire que si demain, tu veux changer ta procédure (nombre/type de parametres, ...), tu vas casser les appli qui l'utilisent. Et comme il n'y a pas de lien direct (cad pas de compilation), tu ne te rendras compte du problème qu'à l’exécution (et en général, ca arrive pas au bon moment :aie: )

Ceci étant dit, je suis d'accord avec les autres que dans certains cas, utiliser des procedures stockées peut etre une bonne solution. Mais il faut avoir conscience que des qu'on a créer une procédure stockée, c'est figé dans le marbre et que la modifier peut avoir des effets de bords difficiles à identifier.

Je stocke la logique métier dans Java. Deux solutions :

• Utiliser la spécification JDBC avec une couche DAO
• Utiliser JPA pour manipuler les données via des objets Java.

Pour moi stocker la logique métier dans des procédures SGBD ne contient que des inconvénients :

• Java n'a pas de coût "spécifiques" comme ceux des SGBD payants (coût par connexion, nombre de processeur etc).
• Utiliser une BD c'est soit utiliser Oracle ou soit SQL Server. Tous les SGBD ne sont pas aussi évolués que Oracle ou SQL Server. Pour les SGBD gratuits, MySQL est complètement à la ramasse avec son implémentation de SQL/PSM, PostgreSQL lui ne gère pas les transactions inter-procédure et ne gère pas suffisamment bien les exceptions.
• Migrer de Java vers autre chose est toujours plus simple que de passer de PL/SQL ou T-SQL vers autre chose.
• Dans les grandes entreprise, un simple développeur a un accès très restreint aux SGBD, il sera dépendant de l'admin DB pour apporter la moindre modification à ses procédures.
• Question de performance, je ne suis pas sûr qu'une procédure stockée retournant plusieurs milliers de tuples soit plus performant qu'un itérateur JDBC.

=> Pour moi stocker la logique métier dans un SGBD c'est tomber dans le même piège et dépendance que COBOL qui consiste à afficher en Java et utiliser COBOL pour aller récupérer des données dans du DB2.

Citation:

---

Bien que je ne l'ai jamais fait par manque de connaissance, oui, la DB est une bon endroit pour stocker du métier. Après tout, dès que tu met une contrainte de clé étrangère sur une table, c'est de la logique métier, tu as décidé que le métier interdisait des éléments sans parent, des montants négatifs, des heures nulles, etc. Quand tu crée des vues pour te faciliter le travail, même chose, tu ramène du métier pour préciser comment les constuires. Les procédure stockées, cela permet juste d'aller bien plus loin dans la préparation de tes données. Ca n'a rien de choquant et je préfère mille fois mieux avoir un DBA qui prépare les procédures stockées qu'un dev qui rapatrie 10x trop de données.

---

Rien n'empêche de créer des contraintes d'intégrités sur une table tout ayant la logique métier Java (on peut effectuer un double contrôle). Un mauvais DB peut lui aussi rapatrier 10x trop de données s'il applique mal sa clause WHERE.


EDIT: Pour ma part j'estime que les procédures stockées c'est bien pour les batchs, pas les applications en temps réel.

Citation:

---

Envoyé par heroined

Malheureusement je n'arrive pas à trouver de raison valable ni d'argument objectif pour défendre ce point de vue.
Le seul que j'ai trouvé est : "Attention, si un jour Oracle disparaît, vous perdez tout votre métier !". Il m'a été répondu qu'Oracle détenait Java, et donc si Oracle disparaît, Java aussi. 1 point partout :aie:

---

Un vrai argument?
"Mon dieu, le prix de la licence d'utilisation Oracle a encore augmenté, on n'a plus les moyens de payer autant. Il faut passer à une base de données moins coûteuse."


Accessoirement, si Oracle disparaît, Java sera encore loin de disparaitre... http://openjdk.java.net/

Citation:

---

Envoyé par eulbobo

Accessoirement, si Oracle disparaît, Java sera encore loin de disparaitre... http://openjdk.java.net/

---

et autre jvm

http://arodrigues.developpez.com/tut...nt-jvm-ibm-j9/

Une entreprise (surtout comme Oracle), ne disparait pas, elle se fait au pire racheter par une autre.

Bonjour,

Je pense que les procedures stockées ne sont plus à la mode.
Neanmoins, ca reste une excelente solution technique que je defends dans mon blog ici

Donc ne jetter pas les proc stockées immédiatement ca peut servir.8-)

Merci beaucoup pour vos réponses!

Ça va beaucoup m'aider dans mon argumentation ;)

Je vois bien qu'il n'y a pas de réponse bien tranchée sur le sujet.

Pour ma part elle est tranchée :p pour les applications temps réel placer la logique métier dans une BD se résume plus ou moins à se limiter à du Oracle et bien sûr rencontrer des difficultés pour gérer les transactions entre les différentes procédures lancées via une requête du client Java, par exemple si tu places ta logique métier dans ta BD, qui va effectuer le commit/rollback ? La dernière procédure exécutée ou bien ton programme Java ?

Comme toujours: démarcation explicite des transactions par l'utilisateur (donc java) selon moi.

Sauf que gérer les transactions c'est du métier, c'est à ce point que je voulais venir :aie:

Citation:

---

Envoyé par tchize_

Comme toujours: démarcation explicite des transactions par l'utilisateur (donc java) selon moi.

---

Je suis plutôt d'accord avec @tchize_

Sans parler des prix des licences et la quasi obligation de faire du Oracle/SQLServer j’avoue ne pas trop comprendre ce refus total des procédures stockées.

Je dis pas qu'il faut tout faire en SQL, mais quand même. Quand tu commit une transaction, prenons l'arrivage d'une commande par exemple, et que sa validation doit aller mettre à jour des tables de budgets et ton stock par exemple. Je trouve ça beaucoup plus propre que ce soit des procédures stockées appelées via le déclenchement d'un trigger qui fasse les modifs, plutôt que de devoir charger tout ça dans ton code Java, alors que au final tu ne t'en sert pas vraiment.

Après ce n'est que mon avis :mouarf:

Les triggers c'est encore un autre cas, il s'agit d'une portion de code qui sera exécutée automatiquement certes mais je ne les considères pas comme de vrais procédures stockées, je prend le cas où l'on souhaiterait une application full BDD (zéro requête SQL dans le code Java). De toute façon il suffit d'essayer, moi je suis sur qu'arrivé à un certain niveau d'avancement ça peut se corser au niveau du développement.

Bah ça reste du code métier :)

Et puis le trigger est là pour faire appel au procédures stockées justement. En plus de pouvoir faire des contrôles avant commit ou diffuser une info après.

Par contre j'ai jamais dit qu'il fallait faire du full BDD non plus. Mais un savant mélange des deux reste à mon sens une bonne approche.

Personnellement comment je vois les choses :

- Utiliser un modèle DAO pour manipuler tes données lorsque tu travailles sur un module (entités/vues) avec une couche de service.
- Se servir des procédures stockées pour tout ce qui touche à la propagation des données dans ta base.

Le tout géré par ton application au travers d'une transaction.

Le fait de gérer ta transaction en Java te permet de garder le contrôle sur tout le processus (gérer les erreurs éventuelles), tout en profitant des avantages offert par la gestions des triggers, des procédures stockées, et des contrôles fait par la base elle même.

Et ça empêche pas non plus d'avoir des contrôle ou du code métier dans ton code Java.

Par contre ça à le "désavantage" de devoir maitriser un langage de plus. Car effectivement si tu fais nimp dans ton code SQL ou quand tu conçois ta base, ce peut vite foutre la merde (ce qui reste vrai en Java aussi tu me diras).

Citation:

---

Mais un savant mélange des deux reste à mon sens une bonne approche

---

Je plussoie.

Perso, je développe seul mes applications Sql Server (avec procédures et triggers) + java.
Cela me fait 2 boîtes à outils. A chaque fois je détermine la solution la plus favorable à l'efficacité.

Maintenant pour des projets d'envergure, je suppose que les équipes "java" et les équipes "DataBase" devraient travailler ensemble non ?