Discussion :

[spidetra]

Salut à tous,
Faut-il, oui ou non, utiliser les procédures stockées et/ou les triggers, avec des outils de Mapping O/R ( Hibernate, Ibatis,.... ). ?

J'ai l'impression que les développements orientés objets ne sont pas "fan" de l'utilisation des procédures stockés et triggers dans les bases de données relationelles.

Lu dans la préface de la documentation officielle de Hibernate :

Hibernate n'est probablement pas la meilleure solution pour les
applications centrées sur les données qui n'utilisent que les procédures stockées pour implémenter la logique
métier dans la base de données, il est le plus utile dans les modèles métier orientés objets dont la logique métier
est implémentée dans la couche Java dite intermédiaire.

Ce n'est pas la première fois que je lis, dans les différents tutos, des remarques du style : " Les procédures stockées, faut faire avec....".

Aujourd'hui, je part de zéro, avec une base mySQL 5.0. J'ai donc toute liberté pour choisir ma stratégie de développement :
- Implémentation de proc stockées et triggers
- Mettre toute l'implémentation dans la couche métier


Quelle implémentation me conseillez-vous, et pourquoi ?

[lunatix]

effectivement, en général, on evite de se passer des procedures stockées et plus généralement, des spécificités des sgbd.

pourquoi :
parce que l'idée du code objet, c'est d'avoir tout le code métier 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 données en changeant que une seule ligne de conf. pratique.

[spidetra]

Ok, merci pour la réponse.
Il faut donc que je m'adapte et que je change mes habitudes de programmeur. J'avais plutôt l'habitude de bc utiliser les procédures stockées.

Je vais quand même garder ce qui me permet de maintenir l'intégrité référentielle 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 générale, 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 générale, 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'espère ! )

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, même si je galère pas mal
Merci pour les infos.

[Laurent.B]

effectivement, en général, on evite de se passer des procedures stockées et plus généralement, des spécificités des sgbd.

?

[lunatix]

j'ai bien foiré la

on evite d'utiliser bien sur

[ego]

Attention quand même 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 problématique du stockage des données et de l'accès à ces données est trop sensible pour que l'on n'y prête pas plus d'attention. Gare aux puristes de l'objet !

[spidetra]

Attention quand même dans le cas de pbs de performance particuliers.
...
La problématique du stockage des données et de l'accès à ces données est trop sensible pour que l'on n'y prête pas plus d'attention. Gare aux puristes de l'objet !

J'approuve à 100%.

J'essaye d'avoir une approche pragmatique, et je suis très loin d'être un puriste de l'approche objet
J'essaye de développer par itération successive. Chaque nouveau cycle doit pouvoir corriger les erreurs de choix du cycle précédent.

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'itération suivante.

J'ai choisit Hibernate surtout pour la documentation abondante en français. ça ne me posera aucun problème 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'espère pouvoir pallier les pb de performance d'accès aux données inhérent à la conception objet en passant par des systèmes de cache.

Si les pb persistent, ça ne me posera aucun pb de me remettre à nouveau en cause et de passer par des procédures stockées.

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