# Java > Gnral Java > Persistance des donnes >  [Mapping O/R] - Pour ou contre les procdures stockes

## spidetra

Salut  tous,
Faut-il, oui ou non, utiliser les procdures stockes et/ou les triggers, avec des outils de Mapping O/R ( Hibernate, Ibatis,.... ). ?

J'ai l'impression que les dveloppements orients objets ne sont pas "fan" de l'utilisation des procdures stocks et triggers dans les bases de donnes relationelles.

Lu dans la prface de la documentation officielle de Hibernate :



> Hibernate n'est probablement pas la meilleure solution pour les
> applications centres sur les donnes qui n'utilisent que les procdures stockes pour implmenter la logique
> mtier dans la base de donnes, il est le plus utile dans les modles mtier orients objets dont la logique mtier
> est implmente dans la couche Java dite intermdiaire.


Ce n'est pas la premire fois que je lis, dans les diffrents tutos, des remarques du style : " Les procdures stockes, faut faire avec....".

Aujourd'hui, je part de zro, avec une base mySQL 5.0. J'ai donc toute libert pour choisir ma stratgie de dveloppement :
- Implmentation de proc stockes et triggers
- Mettre toute l'implmentation dans la couche mtier


Quelle implmentation me conseillez-vous, et pourquoi ?

----------


## lunatix

effectivement, en gnral, on evite de se passer des procedures stockes et plus gnralement, des spcificits des sgbd.

pourquoi :
parce que l'ide du code objet, c'est d'avoir tout le code mtier au meme endroit, et dans un langage simple et facile a relire (java, c'est quand meme plus facile a lire, et a debbugger que du pl-sql par exemple)
et parce que avec hibernate, si tu n'utilises pas de prock stok, ton programme reste multi-base de donnes en changeant que une seule ligne de conf. pratique.

----------


## spidetra

Ok, merci pour la rponse.
Il faut donc que je m'adapte et que je change mes habitudes de programmeur. J'avais plutt l'habitude de bc utiliser les procdures stockes.

Je vais quand mme garder ce qui me permet de maintenir l'intgrit rfrentielle de mon SGBD :
- Contraintes
- Trigger

----------


## lunatix

les contraintes, on a jamais parl de les enlever  :;): 

pour le reste, c'est un choix. Il faut voir ton interet.ce n'est qu'une regle gnrale, mais si tu penses developper 5 fois plus vite en prock qu'en java, si la portabilit de l'application d'une base a l'autre n'a pas d'interet pour toi, faut quand meme reflechir !

----------


## spidetra

> les contraintes, on a jamais parl de les enlever 
> 
> pour le reste, c'est un choix. Il faut voir ton interet.ce n'est qu'une regle gnrale, mais si tu penses developper 5 fois plus vite en prock qu'en java, si la portabilit de l'application d'une base a l'autre n'a pas d'interet pour toi, faut quand meme reflechir !


Je suis en phase d'auto-formation. J'essaye de ne pas prendre trop de mauvaise habitude et de m'adapter aux pratiques courantes du monde Java.
Aujourd'hui, je suis seul et sans contraintes. Demain, je serai dans des quipes Java ( enfin, j'espre ! )

J'irai beaucoup plus vite si je m'imposait pas de travailler avec Spring ( MVC + IoC ) et Hibernate   ::): .
A faire l'effort, autant faire l'effort jusqu'au bout, mme si je galre pas mal 
Merci pour les infos.

----------


## Laurent.B

> effectivement, en gnral, on evite *de se passer* des procedures stockes et plus gnralement, des spcificits des sgbd.


?  :;):

----------


## lunatix

::lol::   j'ai bien foir la  ::): 

on evite d'utiliser bien sur

----------


## ego

Attention quand mme dans le cas de pbs de performance particuliers.
Il peut tre utile de faire des entorses dans ce cas.
Attention  ne pas faire table rase de tout pour choisir une unique techno. La problmatique du stockage des donnes et de l'accs  ces donnes est trop sensible pour que l'on n'y prte pas plus d'attention. Gare aux puristes de l'objet !

----------


## spidetra

> Attention quand mme dans le cas de pbs de performance particuliers.
> ...
>  La problmatique du stockage des donnes et de l'accs  ces donnes est trop sensible pour que l'on n'y prte pas plus d'attention. Gare aux puristes de l'objet !


J'approuve  100%.

J'essaye d'avoir une approche pragmatique, et je suis trs loin d'tre un puriste de l'approche objet  ::lol::  
J'essaye de dvelopper par itration successive. Chaque nouveau cycle doit pouvoir corriger les erreurs de choix du cycle prcdent.

Certains choix sont fortement impactant et seront dur  changer. Le framework Spring fait partie de ses choix sur lequel le droit  l'erreur est minime.

Pour les autres briques, je part du principe que je doit pouvoir r-crire ma brique  l'itration suivante.

J'ai choisit Hibernate surtout pour la documentation abondante en franais. a ne me posera aucun problme dans le futur de r-crire la couche DAO avec Ibatis ou de passer directement par JDBC sans aucune couche de mapping O/R.

J'espre pouvoir pallier les pb de performance d'accs aux donnes inhrent  la conception objet en passant par des systmes de cache.

Si les pb persistent, a ne me posera aucun pb de me remettre  nouveau en cause et de passer par des procdures stockes.

J'ai vraiment la chance de ne pas avoir de contraintes extrieures, pour l'instant.

----------

