Programmation Java - Où les instructions SQL doivent-elles être stockées? [fermé]

Où une application compatible JDBC doit-elle stocker ses instructions SQL et pourquoi?

Jusqu'à présent, j'ai réussi à identifier ces options:

• Codé en dur dans les objets métier
• Intégré dans les clauses SQLJ
• Encapsuler dans des classes séparées, par exemple les objets d'accès aux données
• Basé sur les métadonnées (découpler le schéma d'objet du schéma de données - décrire les mappages entre eux dans les métadonnées)
• Fichiers externes (par exemple, fichiers de propriétés ou de ressources)
• Procédures stockées

Quels sont les «avantages» et les «inconvénients» pour chacun?

Le code SQL doit-il être considéré comme «code» ou «métadonnées»?

Les procédures stockées doivent-elles être utilisées uniquement pour l'optimisation des performances ou sont-elles une abstraction légitime de la structure de la base de données?

La performance est-elle un facteur clé dans la décision? Qu'en est-il du verrouillage des fournisseurs ?

Qu'est-ce qui est mieux - couplage desserré ou couplage serré et pourquoi?

EDITED: Merci à tous pour les réponses - voici un résumé:

Mappages relationnels d'objets (ORM) basés sur les métadonnées

Avantages:

• Très abstrait - le serveur de base de données peut être commuté sans qu'il soit nécessaire de changer de modèle
• Large diffusion - pratiquement une norme
• Réduit la quantité de SQL nécessaire
• Peut stocker SQL dans des fichiers de ressources
• La performance est (généralement) acceptable
• Approche axée sur les métadonnées
• (Base de données) Indépendance des fournisseurs

Les inconvénients:

• Cache les intentions de SQL et des véritables développeurs
• SQL difficile à réviser / modifier par DBA
• SQL peut encore être nécessaire pour les cas impairs
• Peut forcer l'utilisation d'un langage de requête propriétaire, par exemple HQL
• Ne se prête pas à l'optimisation (abstraction)
• Peut manquer d'intégrité référentielle
• Remplace le manque de connaissances SQL ou le manque de soin du code dans la base de données
• Ne correspond jamais aux performances de la base de données native (même si elles s'en rapprochent)
• Le code du modèle est très étroitement associé au modèle de base de données

Codé en dur / encapsulé dans la couche DAO

Avantages:

• SQL est conservé dans les objets qui accèdent aux données (encapsulation)
• SQL est facile à écrire (vitesse de développement)
• SQL est facile à localiser lorsque des modifications sont nécessaires
• Solution simple (pas d'architecture désordonnée)

Les inconvénients:

• SQL ne peut pas être révisé / modifié par DBA
• SQL est susceptible de devenir spécifique à la base de données
• SQL peut devenir difficile à maintenir

Procédures stockées

Avantages:

• SQL conservé dans la base de données (proche des données)
• SQL est analysé, compilé et optimisé par le SGBD
• SQL est facile à réviser / modifier pour DBA
• Réduit le trafic réseau
• Une sécurité accrue

Les inconvénients:

• SQL est lié à la base de données (verrouillage du fournisseur)
• Le code SQL est plus difficile à maintenir

Fichiers externes (par exemple, fichiers de propriétés ou de ressources)

Avantages

• SQL peut être modifié sans avoir besoin de reconstruire l'application
• Découple la logique SQL de la logique métier de l'application
• Référentiel central de toutes les instructions SQL - plus facile à maintenir
• Plus facile à comprendre

Les inconvénients:

• Le code SQL peut devenir non maintenable
• Plus difficile de vérifier le code SQL pour les erreurs (de syntaxe)

Intégré dans les clauses SQLJ

Avantages:

• Meilleure vérification de la syntaxe

Les inconvénients:

• Est trop lié à Java
• Performances inférieures à JDBC
• Manque de requêtes dynamiques
• Pas si populaire

Habituellement, plus l'application se développe en termes de taille et / ou de réutilisabilité, plus il est nécessaire d'externaliser / abstraire les instructions SQL.

Le codage en dur (sous forme de constantes finales statiques) est la première étape. L'étape suivante est stockée dans un fichier (propriétés / fichier xml). Les métadonnées (comme cela est fait par un ORM comme Hibernate / JPA) est la dernière étape.

Le codage en dur présente l'inconvénient que votre code est susceptible de devenir spécifique à la base de données et que vous devez réécrire / reconstruire / redistribuer à chaque modification. L'avantage est que vous l'avez en un seul endroit.

Le stockage dans un fichier présente l'inconvénient qu'il peut devenir impossible à maintenir lorsque l'application se développe. L'avantage est que vous n'avez pas besoin de réécrire / reconstruire l'application, sauf si vous devez ajouter une méthode DAO supplémentaire.

Les métadonnées ont l'inconvénient que le code de votre modèle est très étroitement associé au modèle de base de données. Pour chaque changement dans le modèle de base de données, vous devrez réécrire / reconstruire / redistribuer le code. L'avantage est qu'il est très abstrait et que vous pouvez facilement passer du serveur DB sans avoir à changer de modèle (mais demandez-vous maintenant: à quelle fréquence une entreprise passerait-elle du serveur DB? Probablement au moins une fois tous les 3 ans, n'est-ce pas? t-il?).

Je n'appellerai pas les procédures stockées une «bonne» solution pour cela. Ils ont un but entièrement différent. Même si, votre code dépendrait de la base de données / configuration utilisée.

Je ne sais pas si c'est optimal, mais d'après mon expérience, ils finissent par être codés en dur (c'est-à-dire les littéraux de chaîne) dans la couche DAO.

Je ne pense pas que quiconque vous donnera la ventilation pour / contre que vous voulez, car c'est une question assez vaste. Alors, voici ce que j'ai utilisé dans le passé et ce que j'utiliserai à l'avenir.

J'utilise pour utiliser SQL codé en dur dans la DAL. Je pensais que c'était bien jusqu'à ce que les DBA aient envie de jouer avec le SQL. Ensuite, vous devez le déterrer, le formater et le transmettre aux DBA. Qui en rira et remplacera tout. Mais sans les jolis points d'interrogation, ou les points d'interrogation dans le mauvais ordre et laissez-vous le coller dans le code Java.

Nous avons également utilisé un ORM, et bien que cela soit idéal pour les développeurs, nos administrateurs de base de données l'ont détesté car il n'y a pas de SQL dont ils puissent rire. Nous avons également utilisé un ORM étrange (un ORM personnalisé d'un fournisseur tiers) qui avait l'habitude de tuer la base de données. J'ai utilisé JPA depuis et c'était génial, mais obtenir quelque chose de compliqué en l'utilisant au-delà des DBA est une bataille ascendante.

Nous utilisons maintenant des procédures stockées (avec l'instruction call codée en dur). Maintenant, la première chose dont tout le monde se plaindra est que vous êtes lié à la base de données. Vous êtes. Cependant, à quelle fréquence avez-vous changé de base de données? Je sais pertinemment que nous ne pouvions tout simplement même pas essayer, la quantité d'autres codes en dépendant, ainsi que le recyclage de nos DBA et la migration des données. Ce serait une opération très coûteuse. Cependant, si dans votre monde, changer les DB en un clin d'œil est nécessaire, les SP sont probablement hors service.

À l'avenir, j'aimerais utiliser des procédures stockées avec des outils de génération de code pour créer des classes Java à partir de packages Oracle.

Edit 2013-01-31 : Quelques années et DBA plus tard et nous utilisons maintenant Hibernate, en passant à SQL (procs stockés dans la base de données) uniquement lorsque cela est absolument nécessaire. Je pense que c'est la meilleure solution. 99% des fois, les bases de données n'ont pas à se soucier du SQL, et les 1% qu'elles le font se trouvent dans un endroit avec lequel elles sont déjà à l'aise.

En utilisant un ORM (tel que la mise en veille prolongée), vous n'aurez, espérons-le, aucune instruction SQL à craindre. Les performances sont généralement acceptables et vous bénéficiez également de l'indépendance du fournisseur.

Le code SQL doit-il être considéré comme «code» ou «métadonnées»?

Code.

Les procédures stockées doivent-elles être utilisées uniquement pour l'optimisation des performances ou sont-elles une abstraction légitime de la structure de la base de données?

Les procédures stockées permettent la réutilisation, y compris à l'intérieur d'autres procédures stockées. Cela signifie que vous pouvez effectuer un voyage vers la base de données et lui faire exécuter les instructions de support - le moins de trafic est idéal. ORM ou sproc, le temps passé sur le fil allant au db & back est quelque chose que vous ne pouvez pas récupérer.

ORM ne se prête pas à l'optimisation en raison de son abstraction. IME, ORM signifie également un manque d'intégrité référentielle - rendre une base de données difficile à rapporter. Ce qui a été économisé en complexité a maintenant augmenté pour pouvoir extraire les données de manière viable.

La performance est-elle un facteur clé dans la décision? Qu'en est-il du verrouillage des fournisseurs?

Non, la simplicité l'est. Le verrouillage du fournisseur se produit également avec la base de données - SQL est relativement standardisé, mais il existe encore des moyens spécifiques au fournisseur de faire les choses.

La peur du verrouillage des fournisseurs dans le monde Java est intéressante.

J'espère que vous n'avez pas payé 50000 $ par processeur pour Oracle Enterprise, et que vous n'avez ensuite utilisé que le plus petit dénominateur commun pour passer à Mysql d'une minute à l'autre. Comme tout bon DBA vous le dira, il existe des différences subtiles entre les différentes bases de données de grands noms, en particulier en ce qui concerne les modèles de verrouillage et la façon dont ils parviennent à la cohérence.

Donc, ne prenez pas de décision sur la façon d'implémenter vos appels SQL uniquement sur la base du principe SQL indépendant du fournisseur - ayez une vraie raison (commerciale) de le faire.

SQL inside Stored Procedures est optimisé par le système de base de données et compilé pour la vitesse - c'est sa maison naturelle. SQL est compris par le système de base de données, analysé par le système de base de données. Gardez votre SQL dans la base de données si vous le pouvez; enveloppez-le dans des procédures ou des fonctions stockées ou dans toutes les unités de logique fournies par le système de base de données, et faites-y des appels simples en utilisant l'un des outils que vous ou quelqu'un d'autre avez mentionnés.

Pourquoi stocker le code SQL du système de base de données en dehors de la base de données? Souvent pour la vitesse de développement. Pourquoi utiliser le mappage ORM? - Certains disent que le mappage ORM offre une compatibilité entre différents systèmes de base de données; Cependant, il est rare dans le monde réel qu'une application s'éloigne de la plate-forme de base de données lorsqu'elle a été construite, en particulier lorsqu'elle commence à utiliser des fonctionnalités avancées telles que la réplication, et pour les rares occasions où le système de base de données est remplacé, un certain travail est justifié . Je crois que l'un des inconvénients d'ORM est souvent le substitut au manque de connaissances SQL ou au manque de soin pour coder dans la base de données. De plus, ORM ne correspondra jamais aux performances de la base de données native, même s'il s'en rapproche.

Je suis d'accord pour conserver le code SQL dans la base de données et lui faire des appels simples via n'importe quelle API ou interface que vous souhaitez utiliser. Abstenez-vous également du point auquel vos appels de base de données sont effectués en plaçant ces appels derrière une classe abstraite ou une interface OO (exprimée par des méthodes), donc si jamais vous échangez dans un nouveau type de source de données, il sera transparent pour la couche métier. .

La seule question que vous posez et qui a une réponse définitive est "Est-ce du code SQL ou des métadonnées?" C'est très certainement du code et en tant que tel, il doit être conservé dans une sorte de contrôle du code source et disposer d'un système permettant de facilement mettre à jour la dernière version et de revenir en arrière si les choses tournent mal.

J'ai vu trois façons de faire du SQL dans une application et chacune a ses avantages et ses inconvénients. Il n'y a pas de meilleur moyen, mais la meilleure chose à faire est de choisir celui qui fonctionne bien avec votre application et de s'y tenir.

• ORM - cela réduit la quantité de SQL que vous devez écrire et gère beaucoup de détails pour vous. Vous aurez besoin de faire du SQL personnalisé. Assurez-vous que vous disposez d'un ORM qui gère cela avec élégance.
• Objets d'accès aux données - conservez le SQL dans les objets qui accèdent aux données. Cela encapsule votre base de données et fait en sorte que le reste de votre application n'ait pas besoin de connaître la structure de base de données sous-jacente, juste l'interface avec ces objets.
• Procédures stockées - cela conserve tout votre SQL dans votre base de données et permet à vos DBA de savoir facilement ce qui se passe. Tout ce que vous avez à faire est que votre code appelle les procs stockés

Il se trouve que nous utilisons le mappeur SQL iBatis, qui est plus proche du métal que les ORM comme Hibernate. Dans iBatis, vous mettez les instructions SQL dans des fichiers de ressources (XML), qui doivent se trouver dans le chemin de classe.

Votre liste d'approches semble assez complète si vous ajoutez l'option ORM de @ ocdecio. Je dirais que l'utilisation d'un ORM et l'utilisation d'un mappeur SQL et de fichiers de ressources sont les deux meilleures approches. Je m'éloignerais de SQLJ, qui n'a pas été largement adopté et vous lie trop étroitement à Java. Éloignez-vous également des procédures stockées, car elles vous lient à un fournisseur de base de données spécifique (les normes sont presque inexistantes pour les procédures stockées).

Comme la plupart d'entre nous, j'ai vu tout le gammut mais nous devons considérer SQL comme un langage de première classe. J'ai même vu SQL stocké dans la base de données qui est extrait puis exécuté de nouveau.

Les systèmes les plus performants que j'ai vus utilisent des procédures, des fonctions et des vues stockées.

Les processus stockés conservent le texte SQL dans la base de données et permettent un changement relativement immédiat par ceux qui DÉPLOYENT et PERSONNALISENT (ce qui nécessite beaucoup de conception appropriée pour le prendre en charge).

Toutes les projections doivent se faire via des vues et des sélections simples pour les mêmes raisons, toute la logique de projection doit être contenue dans la vue.

Je suggère d'utiliser des DAO avec une disposition d'usine. Ainsi, les exemples d'objets dont vous avez besoin seraient:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

Ce style superpose l'interaction des données, vous ne devriez donc avoir à changer qu'une couche de code si vous changez de base de données ou passez aux technologies ORM.

Il n'y a pas vraiment de différence substantielle entre ces trois:

1. Codé en dur dans les objets métier
2. Intégré dans les clauses SQLJ
3. Encapsuler dans des classes séparées, par exemple les objets d'accès aux données

Je suppose que vous allez intégrer du code SQL sous forme de chaîne directement dans votre code Java. Alors que 1 et 3 utiliseront probablement JDBC directement (ou un outil comme Apache DbUtils ), 2 ajoute une technologie de préprocesseur à la pile, générant le code JDBC approprié avant la compilation.

Donc, essentiellement, si ces solutions impliquent l'intégration de SQL, vous pouvez également utiliser l'une de ces technologies:

• API JPA Criteria , modélisant JPQL en tant que langage interne spécifique à un domaine en Java
• jOOQ , modéliser SQL en tant que langage interne spécifique au domaine en Java

Il peut également y avoir d'autres outils pour vous aider à intégrer SQL dans Java d'une manière plus sécurisée que via SQLJ ou via une concaténation de chaînes réelle.

D'après mon expérience, le codage en dur des instructions SQL dans les objets DAO est ce qui est largement utilisé, cependant, je pense que cela devrait être la méthode la moins préférée. La meilleure pratique devrait être de stocker les instructions SQL dans un fichier de propriétés. Et obtenez les instructions de l'objet DAO via une interface vers les fichiers de propriétés, par exemple java.util.Properties . Les instructions sql peuvent être entrecoupées de '?' Pour passer des paramètres, via une approche de déclaration préparée .

Une telle approche permet de découpler la logique SQL de la logique métier de l'application. Cela rend disponible un référentiel central de toutes les instructions SQL, ce qui facilite la modification, éliminant le besoin de rechercher des instructions de base de données dans la logique de l'application.

Les miens se retrouvent dans des ensembles de ressources. Je sais que ce n'est pas normal, mais c'est le plus facile pour moi et quiconque «autre que moi» à maintenir. C'est simple et logique.

Je suis en fait curieux de voir si quelqu'un utilise également mon approche.

En tant que rexem écrit, les instructions SQL sont du code - elles doivent être traitées comme du code, non externalisées (sauf si vous avez une bonne raison) mais placées avec du code qui traite les données SQL de / vers ces instructions. Les ORM / iBatis du framework d'aujourd'hui offrent de nombreuses simplifications pour le développement JDBC au jour le jour.

Vous trouverez quelques réponses à votre question dans cette question :) Le problème de stockage de vos instructions SQL dépend du roi de votre application. Quels sont vos besoins? Haute sécurité, facilité d'écriture de code ou de maintenance, multiplateforme ou verrouillage fournisseur? La prochaine question avez-vous besoin d'un framework SQL ou ORM pur sera bonne?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Solution la plus simple (P), difficile à maintenir (C)

* Embedded in SQLJ clauses

Meilleure vérification de la syntaxe (P), manque de requêtes dynamiques (C), performances inférieures à JDBC (C), pas si populaire (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

Ce doit être un cas particulier, vous devez faire cela (C) ou si vous voulez dire ORM (P);)

* External files (e.g. Properties or Resource files)

Facile à maintenir (P) mais plus difficile à vérifier pour les erreurs (C)

* Stored Procedures

Haute sécurité (P), code difficile à gérer un problème de verrouillage du fournisseur (C)