我们应该删除存储过程并从Java程序运行数据库调用

Posted 2021-04-09

我正在努力保持在我们公司中使用存储过程。有些人说它们不好，我们不应该使用它们。我们正在i系列上使用DB2。

请在我的论点中提供帮助，以使存储过程在公司中保持有效。

答案

好的，我会赞成存储过程。

首先，如果您仅使用它们，它们将使数据库的重构变得更加简单，因为您可以使用存储在数据库中的依赖关系来找出将受到更改影响的内容（无论如何，在SQL Server中，不能代表其他数据库） ）。

其次，如果您只需要更改查询，则它们的部署要简单得多。

它们也更容易进行性能调整，因为可以在不启动应用程序的情况下轻松调用它们。

如果逻辑复杂，则不必通过网络将所有内容发送到数据库服务器，从而节省了性能。看起来似乎没有什么大的好处，但是如果复杂的查询每天运行数千次，则可以累加。

安全性也非常重要。如果不使用存储过程，则必须在表或视图级别设置权限。这将打开数据库进行内部欺诈。是的，参数化查询减少了sql注入的风险，但这不是您需要防范的唯一威胁。如果您拥有个人或财务数据，并且不使用存储的proc（以及没有动态SQl的proc），并且将用户限制为只能通过proc进行操作，则内​​部员工可能会窃取您的系统，从而给系统带来极大的危险数据或绕过内部控制以窃取金钱。了解会计准则中的内部控制，以了解为什么会出现此问题。

ORM还倾向于编写完全错误的SQL代码，尤其是在查询复杂的情况下。此外，随着人们开始使用它们而不是存储过程，我发现从未使用过存储过程的人们对如何从数据库中获取数据并经常获取错误数据的理解较差。如果您已经了解SQL，并且可以确定何时将自动生成的代码重写为效果更好的代码，则可以使用ORM。但是太多的用户没有编写复杂代码的技能，因为他们从未学习过基础知识。

最后，由于您已经为应用程序存储了proc，因此完全删除它们是引入新bug的一种方法，因为您必须生成新代码。

另一答案

您不会喜欢这个，我可能会被淘汰，但我与您的其余成员在一起。

存储过程曾经提供许多好处（安全性，性能等），但是通过参数化查询和更好的查询优化，存储过程实际上只会给应用程序增加另一层开销，并为您提供更新/修改代码的另一个地方。

我更喜欢将所有内容都放在一个位置，这样当我需要编辑代码时，我可以转到一个地方并在那里进行更改。

如果您想了解有关离开存储的过程的参数的更多详细信息，请参阅这篇CodingHorror文章：

Coding Horror: Who Needs Stored Procedures Anyway?

...我只是注意到这篇文章是2004年写的。我必须相信，自那时以来数据库已经变得越来越好，这意味着今天的情况比那时更加真实。

另一答案

实质上，通过JDBC执行所有操作意味着您正在数据库和数据库之间插入网络层。总而言之，这意味着数据更加“远程”，并且显示速度较慢。存储过程可以直接在数据库内部的数据上运行，因此速度上的差异可能会令您惊讶。

[请注意，如果这是编程技能的问题，则可以用任何IBM i语言（包括Java）编写存储过程。另外，您不仅可以访问某些数据库内部信息，还可以访问FULL计算机。在这里，AS / 400与任何其他数据库产品都有很大的不同，以至于在[[my看来，其他数据库的经验都不适用。

我建议中型邮件列表，因为它们最了解AS / 400编程技能。

另一答案

这是Marmite的问题之一。如果您主要是数据库程序员，您将认为应该广泛使用存储过程。如果您是应用程序程序员（例如Java或.Net编码器），那么您可能会说应该完全避免使用它们。

并不能满足应用程序程序员想要编写自己的SQL语句的要求。不，如今，他们倾向于抽象化繁琐的ORM服务背后的所有内容。这些不比存储过程更容易理解，但是可以在同一IDE中使用，因此它们需要较少的上下文切换。

有两点有利于存储过程。首先是了解PL / SQL的人可能熟悉Oracle数据库（T-SQL和SQL Server等），因此倾向于为该数据库编写更好的程序（定义为利用平台的优势的程序）。功能，并适合其功能）。

第二件事是数据仍然存在。应用程序开发人员喜欢谈论“数据库独立性”，但真正重要的是

应用程序独立性。前端来来去去，但数据模型会永远存在。在过去的十年中，Java应用程序被编写为Applet，Servlet，JSP，Tiles和Faces，并带有javascript，Groovy，AJAX和JSON的附加组件，它们通过手动JDBC，EJB（v1,2， 3），TopLink，Hibernate和IBatis ...如果我错过了一些，请原谅我。与每次都要重写业务逻辑的应用程序相比，其UI是一层存储过程外表的应用程序更容易升级到最新的应用程序。而且它们的性能也会更好。

但是，从长远来看，与数据库直接交互的应用程序可能会消失。一切都将与服务总线进行通信，这将决定从何处获取数据。当然，通过精心设计的存储过程API公开数据库的商店可能会比进入那些必须从其ORM逻辑中提取所有内容的地方更容易进入这个勇敢的新世界。

另一答案

[当您有一组分层的应用程序时，它们很有用。例如，具有提供原子操作（碰巧是存储过程）的Web服务的单个核心DB，以及使用这些WS的ESB或一组应用程序。在单应用程序/单数据库的情况下，其想法是将代码保留在其他地方建议的位置。

但是，那只是我。

另一答案

我是一个长期的Java开发人员，最近遇到了几个项目，这些项目大量使用了存储过程，这对我来说确实是个坏习惯。

话虽如此，我不愿作一个笼统的声明，将存储过程作为系统设计选项是不好的，因为实际上这取决于所讨论的项目以及特定的存储过程将要完成什么。

我的偏好是避免对简单的CRUD操作使用任何类型的存储过程（对于某些存储过程来处理这些操作，这听起来有些可笑，但是我遇到了一些这样做的系统）–最终导致根据我的观察，必须在Java端编写（测试和维护）大量代码来管理这些过程调用。最好只使用Hibernate（或其他ORM库）来处理这些类型的操作……如果出于其他原因，它只会减少需要维护的代码量。当您尝试重构系统或对系统进行任何重大更改时，它也会引起问题，因为您不仅不必担心类/表的更改，还需要处理CRUD操作的存储过程。如果开发人员无法自己更改数据库，或者存在一些正式的过程来协调系统两部分之间的更改，那么这种情况可能会进一步加剧。

另一方面，具有要求与Java代码进行有限交互的存储过程（基本上，您只是触发了带有几个参数的调用），并且以半自治方式运行也不是一件糟糕的事情。我遇到过几种情况（尤其是在我们将数据迁移或导入到系统中的情况），使用存储过程比编写一堆Java代码来处理功能要好得多。

我想这里的真正答案是，您应该检查系统中每个存储过程当前正在做什么，并逐案评估它们，以确定在Java或Java中处理该操作是否更容易。数据库。有些可能在Java中很好地工作（通过ORM库或实际的手写代码），有些则没有。在这两种情况下，目标始终应该是确保每个人都可以理解该系统，并且易于维护，而不仅仅是存储过程本身是好是坏。

另一答案

Midrange Solutions