Programmation Java - Où dois-SQL-ils être conservés?

Question

Où devrait-JDBC-application conforme de stocker ses instructions SQL et pourquoi?

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

• Codé en dur dans business objects
• Intégré dans SQLJ clauses
• Encapsuler dans des classes séparées, par exemple Objets D'Accès Aux Données
• Les métadonnées (de dissocier l'objet schéma du schéma de données - décrire les mappages entre eux dans les métadonnées)
• Les fichiers externes (par exemple, les Propriétés ou les Fichiers de ressources)
• Procédures Stockées

Quels sont les "Pros" et les "Contre" de chacun?

Devrait le code SQL être considéré comme "code" ou "métadonnées"?

Devrait procédures stockées uniquement être utilisé pour l'optimisation de la performance ou ils sont légitimes abstraction de la structure de base de données?

La performance est un facteur clé de la prise de décision? Ce sujet de l'enfermement?

Ce qui est mieux – couplage lâche ou serré de couplage et pourquoi?

ÉDITÉ: Merci à vous tous pour les réponses – voici un résumé:

Orientée métadonnées c'est à dire Mappings Objet Relationnel (ORM)

Pour:

• Très abstrait - serveur de base de données peut être commutation sans la nécessité de changer le modèle
• Répandue pratiquement une norme
• Réduit la quantité de SQL nécessaires
• Peut stocker SQL dans les fichiers de ressources
• La Performance est (généralement) acceptable
• Les métadonnées de l'approche axée sur la
• (Base de données) fournisseur de l'indépendance

Inconvénients:

• Cache SQL et vrai développeurs intentions
• SQL difficile d'être examinées et modifiées par DBA
• SQL peut-être encore nécessaire pour impair cas
• Pouvez forcer l'utilisation d'une propriété langage de requête par exemple HQL
• Ne se prête pas à une optimisation (abstraction)
• L'absence de l'intégrité référentielle
• Substituts du manque de connaissances SQL ou le manque de soins de code dans la base de données
• Jamais correspondre à la base de données native la performance (même si il est proche)
• Le code du modèle est très serré, couplé avec le modèle de base de données

Codé en dur/encapsulée dans une couche DAO

Pour:

• SQL est conservé dans les objets qui l' les données d'accès (encapsulation)
• SQL est facile à écrire (vitesse de de développement)
• SQL est facile à suivre vers le bas lorsque des changements sont nécessaires,
• La solution la plus Simple (pas de désordre l'architecture)

Inconvénients:

• SQL ne peuvent pas être examinées et modifiées par DBA
• SQL est susceptible de devenir DB spécifiques
• SQL peuvent devenir difficile à maintenir

Procédures Stockées

Pour:

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

Inconvénients:

• SQL est liée à la base de données (le fournisseur lock-in)
• Le code SQL est plus difficile à maintenir

Les fichiers externes (par exemple, les Propriétés ou les fichiers de Ressources)

Pros

• SQL peut être modifié sans avoir besoin de reconstruire l'application
• Découple la logique SQL à partir de la application de la logique métier
• Dépôt Central de toutes les SQL états – facile à entretenir
• Plus facile à comprendre

Inconvénients:

• Le code SQL peuvent devenir des nations unies-maintenable
• Plus difficile de vérifier le code SQL pour la (la syntaxe) des erreurs

Intégré dans SQLJ clauses

Pour:

• Une meilleure vérification de la syntaxe

Inconvénients:

• Liens de trop près à Java
• Une baisse de rendement de JDBC
• Le manque de dynamique des requêtes
• Pas si populaire

Answer 1

D'habitude, plus la demande augmente en termes de taille et/ou la réutilisation, plus le besoin est d'externaliser/abstractize les instructions SQL.

Codé en dur (static final constantes) est la première étape. Stockées dans un fichier (propriétés/fichier xml) est la prochaine étape. Orientée métadonnées (comme le fait par un ORM comme Hibernate/JPA) est la dernière étape.

Codée en dur a l'inconvénient que votre code est susceptible de devenir DB-spécifique et que vous avez besoin de réécrire/reconstruction/redistribuer à chaque changement. L'avantage est que vous l'avez dans 1 endroit.

Stockées dans un fichier a l'inconvénient qu'il peut devenir difficile à maintenir lorsque la demande augmente. L'avantage est que vous n'avez pas besoin de réécrire/reconstruction de l'application, sauf si vous avez besoin d'ajouter une méthode DAO.

Les métadonnées conduit a l'inconvénient que votre modèle de code est très serré, couplé avec le modèle de base de données. Pour chaque changement dans le modèle de base de données, vous aurez besoin de réécrire/reconstruction/redistribuer le code. L'avantage est qu'il est très abstraite et que vous pouvez facilement passer de serveur de base de données sans la nécessité de changer de modèle (mais demandez-vous maintenant: combien de fois une entreprise, passer de serveur de base de données? probablement au moins une fois par 3 ans, n'est-ce pas?).

Je ne vais pas appeler des procédures stockées d'une "bonne" solution pour cela. Ils ont un tout autre but. Même si, votre code devrait être dépend de la base de données / configuration utilisée.

Answer 2

Je ne sais pas si c'est optimal, mais dans mon expérience, ils finissent codé en dur (c'est à dire les littéraux de Chaîne) dans la couche DAO.

Answer 3

Je ne pense pas que quiconque vous donnera le pro/con briser que vous voulez tant que c'est une grande question. Au lieu donc voici ce que j'ai utilisé dans le passé, et ce que je vais utiliser à l'avenir.

J'utilise à l'utilisation de SQL codé en dur dans le DAL. Je pensais que c'était bien jusqu'à ce que les Administrateurs de base de données a voulu jouer avec le SQL. Ensuite, vous avez à creuser, le format et le feu aux Administrateurs de bases de données. Qui va se moquer de lui et de le remplacer tous. Mais sans la belle d'un point d'interrogation ou le point d'interrogation dans le mauvais ordre et vous laisse le soin de le recoller dans le code Java.

Nous avons également utilisé un ORM, et tout ce qui est excellent pour les développeurs de nos Administrateurs de bases de données détesté, comme il n'y a pas de SQL, pour eux, pour en rire. Nous avons également utilisé un étrange ORM (un programme personnalisé à partir de la 3ème partie fournisseur) qui avait l'habitude de tuer la base de données. J'ai utilisé de la JPA depuis et a été grande, mais rien de compliqué à l'aide de ce passé, les Administrateurs de bases de données est une bataille colline.

Nous allons maintenant utiliser des Procédures Stockées (avec l'instruction d'appel codé en dur). Maintenant, la première chose que tout le monde va se plaindre, c'est que vous êtes attaché à la base de données. Vous êtes. Cependant combien de fois avez-vous changé de base de données? Je sais pour un fait que nous ne pourrions tout simplement pas même essayer, le montant des autres code dépend plus de recyclage de nos Administrateurs de bases de données, plus la migration des données. Ce serait une opération très coûteuse. Cependant, si dans votre monde change DBs à une baisse d'un chapeau est nécessaire SPs sont susceptibles.

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

Edit 2013-01-31: il y A quelques années et les Administrateurs de bases de données plus tard et nous avons maintenant utiliser Hibernate, va SQL (stockées procs dans la DB) uniquement lorsque cela est absolument nécessaire. Je pense que c'est la meilleure solution. 99% du temps de la DBs n'avez pas besoin de vous soucier de SQL, et le 1% ils le font, il est dans un endroit où ils sont déjà à l'aise avec.

Answer 4

À l'aide d'un ORM (tels que la mise en veille), vous nous l'espérons aura pas d' instructions SQL à s'inquiéter. La Performance est généralement acceptable et vous obtenez un vendeur de l'indépendance.

Answer 5

La peur de l'enfermement dans le monde java est intéressant.

J'espère que vous n'avez pas payé $50000 pr CPU pour Oracle Enterprise, et alors seulement utilisé le plus petit dénominateur commun afin de passer à Mysql d'une minute. Comme tout bon DBA vais vous dire, il y a des différences subtiles entre les différents grands noms de bases de données, notamment à l'égard de verrouillage des modèles et comment ils la cohérence.

Alors, n'oubliez pas de prendre une décision sur la façon de mettre en œuvre vos appels SQL uniquement basé sur le principe du vendeur agnostique SQL - ont un réel (entreprise) raison de le faire.