Discussion :

[heroined]

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

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.

[Népomucène]

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

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.

[autran]

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.

[tchize_]

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.

[Gugelhupf]

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.

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.

[hwoarang]

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

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 )

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.

[eulbobo]

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

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/

[plawyx]

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/

[Gugelhupf]

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

[autran]

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.

[heroined]

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.