Faut-il supprimer des procédures stockées et les appels de base de données de l'exécution de programmes Java

Question

Je me bats pour garder l'utilisation des procédures stockées dans notre société. Il y a peu de gens qui disent qu'ils sont mauvais et nous ne devrions pas les utiliser. Nous utilisons DB2 sur la série i.

S'il vous plaît aider à mon argument pour maintenir les procédures stockées en vie dans mon entreprise.

Answer 1

OK, je viendrai en faveur des procs stockées.

Tout d'abord si vous les utilisez exclusivement, ils font refactoring la base de données beaucoup plus simple que vous pouvez utiliser les dépendances stockées dans la base de données pour savoir ce qui serait affecté par un changement (bien dans SQL Server de toute façon, ne peut pas parler pour les autres datbases).

En second lieu, si vous avez besoin de changer simplement la requête, ils sont beaucoup plus simples à déployer.

Ils sont également plus faciles à régler les performances car ils peuvent facilement être appelés sans tirer l'application.

Si vous avez une logique complexe, alors vous sauver un peu de performance par ne pas avoir à envoyer tout ce que sur le réseau au serveur de base de données. Peut ne pas sembler un gros gain, mais si la requête complexe est exécuté des milliers de fois par jour, il peut ajouter.

La sécurité est également extrêmement important. Si vous n'utilisez pas les procédures stockées, vous devez définir des droits au niveau de la table ou la vue. Cela ouvre la base de données interne fraude. Oui, les requêtes paramétrées réduisent le risque d'injection sql, mais ce n'est pas la seule menace dont vous avez besoin pour se prémunir contre. Si vous avez des données personnelles ou financières et ne pas utiliser procs stockées (et ceux avec NO instructions SQL dynamiques) et limiter vos utilisateurs à ne pas pouvoir faire les choses à travers les procs, votre système est en danger extrême des employés internes qui peuvent voler données ou contourner les contrôles internes pour voler de l'argent. En savoir plus sur les contrôles internes dans les normes comptables pour voir pourquoi cela est un problème.

ORM ont aussi tendance à écrire juste carrément mauvais code SQL en particulier si la requête est complexe. De plus que les gens commencent à les utiliser au lieu de procs stockées, j'ai trouvé que les gens qui ont jamais utilisé une procs stockées ont une moins bonne compréhension de la façon d'obtenir des données sur la base de données et obtenir fréquemment des données erronées. L'utilisation d'un ORM est très bien si vous comprenez déjà SQL et peut déterminer quand réécrire le code généré automatiquement en quelque chose qui fonctionne mieux. Mais trop d'utilisateurs n'ont pas la compétence à écrire du code complexe, car ils n'ont jamais appris les bases.

Enfin, puisque vous avez déjà enregistré procs pour votre application, se débarrasser d'eux est tout à fait un moyen d'introduire de nouveaux bogues becasue vous deviez générer un nouveau code.

Answer 2

Tu ne vas pas aimer ça, et je vais probablement faire downvoted dans l'oubli, mais je suis avec le reste de votre comapny.

Procédures stockées utilisées pour offrir de nombreux avantages (sécurité, performance, etc.), mais avec des requêtes paramétrées et une meilleure optimisation des requêtes, procédures stockées ajouter simplement une autre couche de frais généraux à votre demande et vous donner un autre endroit que vous devez mettre à jour / modifier code.

Je préfère garder tout en un seul endroit de sorte que lorsque je dois modifier le code, je peux aller à un endroit et y faire mes changements.

Si vous voulez plus de détails sur les arguments pour se éloigner de Prcoedures stockées, consultez cet article CodingHorror:

Coding Horror: Qui a besoin Stored procédures Quoi qu'il en soit

... et je viens de remarquer que l'article est de 2004. Je dois croire que les bases de données se sont améliorées depuis lors, ce qui signifie que cela sonne encore plus vrai aujourd'hui qu'il a fait ensuite.

Answer 3

Faire tout sur JDBC signifie essentiellement que vous insérez une couche réseau entre vous et la base de données. Dans l'ensemble cela signifie que les données sont plus « éloigné » et venir à vous plus lent. Les procédures stockées peuvent travailler directement sur les données contenues dans la base de données, et la différence résultant de la vitesse peut vous étonneront.

S'il vous plaît noter que vous pouvez écrire des procédures stockées dans un IBM i langage Java, y compris, dans le cas où il est question de compétences de programmations. En outre, vous avez accès à la machine COMPLET, pas seulement quelques bases de données internes. Ici, l'AS / 400 est si très différent de tout autre produit de base de données, que les expériences d'autres bases de données simplement - dans my opinion -. Ne pas appliquer

Je recommande les listes de diffusion de milieu de gamme car ils ont la plus grande concentration de compétences en programmation AS / 400, je connais.

Answer 4

Ceci est l'une de ces questions Marmite. si vous êtes avant tout un programmeur de base de données, vous pensez que les procédures stockées devraient être largement utilisés. Si vous êtes un programmeur d'application - dire un Java ou un codeur .Net - les chances sont que vous allez dire qu'ils doivent être évités complètement.

Non que cela répond aux programmeurs d'applications veulent écrire leurs propres instructions SQL. Non, ces jours-ci, ils ont tendance à vouloir faire abstraction de tout derrière les services ORM alambiquées. Ce ne sont pas faciles à comprendre que les procédures stockées mais sont disponibles dans le même IDE, ils nécessitent moins le changement de contexte.

Il y a deux grandes choses en faveur des procédures stockées. La première est que les gens qui connaissent PL / SQL sont susceptibles de se familiariser avec les bases de données Oracle (T-SQL et SQL Server, etc.), et ainsi auront tendance à écrire de meilleurs programmes pour cette base de données (définis comme des programmes qui profitent de ce la plate-forme caractéristiques et sont montés sur la fonctionnalité) que ceux qui ne le font pas.

La deuxième chose est que les données persiste. Les développeurs d'applications sont friands de parler de l ' « indépendance de base de données », mais ce qui compte vraiment est l'indépendance de l'application . -end avant d'aller et venir, mais le modèle de données dure à toujours. Au cours des dix dernières années, les applications Java ont été écrits comme Applets, Servlets, JSP, tuiles et visages, avec des add-ons en JavaScript, Groovy, AJAX et JSON, la connexion à la base de données via JDBC roulées à la main, EJB (v1,2, 3), TopLink, Mise en veille prolongée et ibatis ... pardonnez-moi si je l'ai raté quelques-uns. Les applications dont l'interface utilisateur est une peau sur une couche de procédures stockées sont plus faciles à mettre à niveau les plus récentes et plus que les applications où la logique métier doit être réécrite à chaque fois. Et ils fonctionnent mieux aussi.

Cependant, dans les applications à long terme qui interagissent directement avec la base de données vont probablement mourir loin. Tout va parler au bus de service, et qui décidera de l'endroit où pour obtenir les données. Bien sûr, les magasins où la base de données est exposée à travers une API bien conçu des procédures stockées peuvent trouver plus facile de passer à ce nouveau monde que les lieux qui vont devoir extraire tout de leur logique ORM.

Answer 5

Ils sont utiles lorsque vous avez un ensemble d'applications en couches. Par exemple, un seul DB de base avec les services Web offrant les opérations atomiques (qui se trouvent être des procédures stockées) et un ou ESB un ensemble d'applications qui consomment les PTL. Dans une seule app / db cas unique, l'idée est de garder le code dans un endroit que d'autres ont suggéré.

Mais bien, c'est juste moi.

Answer 6

Je suis un développeur Java de longue date qui a récemment rencontré plusieurs projets qui ont fait un usage intensif des procédures stockées qui ont mis l'utilisation des procédures stockées dans une lumière vraiment mauvais pour moi.

Cela dit, je suis réticent à faire une déclaration générale que les procédures stockées sont mauvaises comme une option de conception du système, parce que vraiment cela dépend du projet en question et quelles sont les procédures stockées particulières tentent d'accomplir.

Ma préférence est d'éviter tout type de procédure stockée pour les opérations CRUD simple (il peut sembler risible à certains d'avoir des procédures stockées gérer ces opérations, mais je l'ai rencontré plusieurs systèmes qui ont été faire) - Cela finit par résultat dans beaucoup de code devant être écrit (et testé et maintenu) du côté Java pour gérer ces appels de procédure de ce que j'ai observé. Il est préférable d'utiliser simplement Hibernate (ou une autre bibliothèque ORM) pour gérer ce genre d'opérations ... si pour aucune autre raison que cela tend à réduire la quantité de code devant être maintenu. Il peut aussi causer des problèmes lorsque vous essayez de factoriser ou apporter des modifications importantes au système, comme vous n'êtes pas seulement d'avoir à vous préoccuper des changements de classe / de table, mais les procédures stockées qui gèrent ops CRUD ainsi. Et cela peut être aggravé davantage si vous êtes dans une situation où les développeurs ne peuvent pas apporter des modifications à la base de données eux-mêmes, ou il y a un processus formel en place pour coordonner les changements entre les deux parties du système.

D'autre part, ayant des procédures stockées qui nécessitent une interaction limitée avec le code Java (en gros, vous le feu juste à côté d'un appel à l'un avec quelques arguments), et exécuter de façon semi-autonome n'est pas une chose terrible soit . Je l'ai rencontré quelques situations (en particulier lorsque nous migraient ou l'importation de données dans un système) où l'aide d'une procédure stockée était une route beaucoup mieux que d'écrire un tas de code Java pour gérer la fonctionnalité.

Je suppose que la vraie réponse ici serait que vous devriez examiner ce que chaque procédure de magasin dans le système est en train de faire et de les évaluer au cas par cas pour déterminer si peut-être il est plus facile de gérer l'opération en Java ou la base de données. Certains peuvent fonctionner très bien mieux en Java (soit par la bibliothèque ORM, ou un code écrit à la main réelle), certains ne peuvent pas. Dans les deux cas, l'objectif doit toujours être de vous assurer que le système est compréhensible et facile à entretenir pour tout le monde, non seulement si les procédures stockées sont bonnes ou mauvaises en soi.