3

我正在努力在我们公司继续使用存储过程。有几个人说它们不好，我们不应该使用它们。我们在 i 系列上使用 DB2。

请帮助我的论点，以使存储过程在我的公司中保持活力。

4

6 回答 6

10

你不会喜欢这样的，我可能会被否决而被遗忘，但我和你的其他人在一起。

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

我更喜欢把所有东西都放在一个地方，这样当我需要编辑代码时，我可以去一个地方并在那里进行更改。

如果您想了解有关远离存储过程的论点的更多详细信息，请查看这篇 CodingHorror 文章：

编码恐怖：谁需要存储过程？

...而且我刚刚注意到这篇文章是 2004 年的。我必须相信从那时起数据库已经变得更好了，这意味着今天的情况会比当时更加真实。

于 2010-04-06T13:40:19.593 回答
2

通过 JDBC 做任何事情本质上意味着您在您和数据库之间插入了一个网络层。总而言之，这意味着数据更加“远程”并且更慢地到达您身边。存储过程可以直接对数据库内的数据进行操作，由此产生的速度差异可能会让您大吃一惊。

请注意，您可以使用包括 Java 在内的任何 IBM i 语言编写存储过程，以防涉及到编程技能。此外，您可以访问 FULL 机器，而不仅仅是一些数据库内部。在这里，AS/400 与任何其他数据库产品大不相同，以至于其他数据库的经验——在我看来——并不适用。

我会推荐 Midrange 邮件列表，因为它们拥有我所知道的最集中的 AS/400 编程技能。

于 2010-04-06T13:49:59.450 回答
2

这是 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 逻辑中提取所有内容的地方相比，迁移到这个勇敢的新世界更容易。

于 2010-04-06T16:05:05.837 回答
1

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

但是，这只是我。

于 2010-04-06T13:53:40.410 回答
1

我是一名长期的 Java 开发人员，最近遇到了几个大量使用存储过程的项目，这些项目对我来说存储过程的使用非常糟糕。

话虽如此，但我不愿意笼统地声明存储过程作为系统设计选项是不好的，因为它实际上取决于所讨论的项目以及特定存储过程试图完成的任务。

我的偏好是避免对简单的 CRUD 操作使用任何类型的存储过程（让存储过程处理这些操作对某些人来说可能听起来很可笑，但我遇到了几个这样做的系统）——这最终导致了很多必须在 Java 端编写（并测试和维护）代码来管理我观察到的这些过程调用。最好只使用 Hibernate（或其他一些 ORM 库）来处理这些类型的操作......如果没有其他原因，它往往会减少需要维护的代码量。在尝试重构或对系统进行任何重大更改时，它也可能导致问题，因为您不仅需要关注类/表的更改，还需要处理处理 CRUD 操作的存储过程。

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

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

于 2010-04-06T14:40:00.130 回答
1

好的，我会支持存储过程。

首先，如果您专门使用它们，它们会使重构数据库变得更加简单，因为您可以使用存储在数据库中的依赖项来找出更改会影响什么（无论如何，在 SQL Server 中，不能代表其他数据库）。

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

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

如果您有复杂的逻辑，那么您不必通过网络将所有这些都发送到数据库服务器，从而节省一些性能。可能看起来不是一个很大的收获，但如果复杂的查询每天运行数千次，它可以加起来。

安全性也极其重要。如果不使用存储过程，则必须在表或视图级别设置权限。这为内部欺诈打开了数据库。是的，参数化查询降低了 sql 注入的风险，但这并不是您需要防范的唯一威胁。如果您有个人或财务数据并且您不使用存储的过程（以及没有动态 SQl 的过程）并将您的用户限制为只能通过过程执行操作，那么您的系统将面临内部员工的极大危险，他们可以窃取数据或绕过内部控制来窃取资金。阅读会计准则中的内部控制，了解为什么这是一个问题。

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

最后，由于您已经为您的应用程序存储了过程，完全摆脱它们是一种引入新错误的方法，因为您必须生成新代码。

于 2010-04-06T15:29:24.947 回答