Discussion :

[Potaw]

Salut

Je suis en train de développer une application Java/Struts sur du Oracle.
Pour faire des requêtes (select, insert, update), il vaut mieux utiliser :

1. des procédures stockées
2. des Prepared statement
3. (Hibenarte)

Je mets Hibernate à part parce qu'il n'est pas prévu qu'on utilise ce framework, mais c'est plus pour ma culture personnelle.

Merci de me donner vos avis/remarques sur ces différentes moyens pour effectuer des requêtes.

Potaw

[ep31]

Cela dépend vraiment des cas mais je dirais :
- utilisation de procédures stockées pour des lancements en batch de procédures longues/complexes
- utilisation de requêtes SQL pour les insertion/récupération/suppression d'informations "simples" en jdbc classique, Hibernate, iBatis, JPA selon la culture de l'entreprise et des recommandations des architectes.

[Potaw]

Ok, merci pour ta réponse.
C'est vrai aussi que la maintenance est plus aisé lorsqu'on est JDBC classique...

Merci

[tchize_]

les procédure stockées sont a éviter si possible, elle posent des problèmes lors des mises à jour de ton application. Il est simple de mettre à jour un preparedStatement jdbc, moins de mettre à jour un structure de table ou des procédures stockées

[Népomucène]

Les procédures stockées sont à utiliser si on décide de séparer :
- le rôle du développeur Java (le "javaiste")
- le rôle du développeur de procédure Oracle, Sql server ou autres (le "procéduriste").

Dans ce cas, les deux développeurs se mettent d'accord sur ce que doivent faire les procédures (action sur les données ou restitution de données).
Ensuite, chacun est tenu de respecter son contrat à savoir :
- le "javaiste" fournit toujours les bons paramètres aux procédures qu'il utilise indépendamment de la structure de son programme.
- le "procéduriste" fournit toujours le résultat attendu même si la structure de la base a changé.

Avantage :
- le "javaiste" ne se soucie pas du tout de la structure de la base
- le "procéduriste" peut faire tranquillement évoluer sa base à condition de toujours fournir le résultat attendu.

Inconvénient :
le jour où le programme client nécessite des données supplémentaires,
il faut réunir à nouveau les deux programmeurs pour refaire un tour.
Mais il en profiteront pour boire un coup, dire du mal des utilisateurs, dégoiser sur les spécifications,
vilipender le projet et finalement se raconter des histoires de blondes

[tchize_]

les procédure stockées sont finalement utilise si tu exploite une base de donnée existante sur laquelle t'as a priori pas de droits de modification. A partir du moment ou la database ne vit que pour ton programme (ce qui est le cas la plus général) il est plus facile de laisser ton programme gérer sa structure de données. Si demain t'as besoin de données en plus, tu change tes requetes dans ton programme, tu rajoute un alter table éventuel, et quand tout marche, tout ce que t'as a faire pour le client, c'est d'installer la mise a jour. Quand la db et le code sont séparé, la mise a jour c'est hachement plus long

[OButterlin]

Personnellement, j'évite au maximum les procédures stockées.
Elles ont certes des avantages et temps de réponse sur des traitements complexes nécessitant des requêtes multiples à la base mais en contre partie, on perd la lisibilité de l'application. La portabilité peut également en prendre un coup dans la mesure où on utilise des spécificités (et Oracle en a beaucoup)...

Un PreparedStatement permet de faire à peu près n'importe quoi de façon correcte, donc, à privilégier (à mon sens)...

Hibernate (ou un autre ORM) est évidement un excellent choix, mais il y a un temps d'apprentissage non négligeable (mais ça reste la Rolls )

Bref, un point de vue de plus...

A+

[Potaw]

Merci pour toutes vos réponses, mais je ne m'attendais pas à ça... je pensais avoir des avis plus mitigés mais bon, je vais donc partir sur des Procédures Stockées alors

Pour Hibernate, je vais m'y mettre en solo avant de l'utiliser au boulot !!!

Encore merci,
@+