存储过程中的所有业务逻辑

Posted 2023-02-24

【中文标题】存储过程中的所有业务逻辑

【英文标题】：All business logic in stored procedure

【发布时间】：2015-06-30 10:03:36

【问题描述】：

我的项目使用 N 层架构和通用框架：

表示层：JSF 2.0 + Primefaces 业务逻辑层：用于管理事务的 Spring 数据访问层：Spring Data + JPA 用于安全和用户管理的 Spring security 用于与外部系统集成的 Spring 集成

对于几乎所有的业务逻辑，我们都使用 Java 代码并驻留在业务层中，但我的客户要求我们将所有业务逻辑移入数据库并使用存储过程（数据库是 Oracle）。

如果将业务逻辑移至数据库，如下所示，我试图说服我的客户并给出一些劣势和优势：

缺点：

存储过程不是编程语言，它应该用于管理数据而不是编写逻辑代码 存储过程使逻辑变得复杂。使用存储过程可能难以实现一种逻辑，但如果使用 Java 等编程语言则非常容易 难以调试或单元测试 难以处理异常 难以维护、更新 存储过程无法与外部系统集成 当 ORM 框架对 CRUD 非常有用时，请花很多精力为每个表编写 CRUD 设计文档难以清晰 更多错误 减缓开发过程 数据库服务器将过载 数据库应该用于处理数据而不是用于流程逻辑 升级或添加新的数据库服务器既困难又昂贵，但使用应用服务器更容易且更便宜 打破 N 层架构和 ORM 框架

使用存储过程时：

性能

：使用数据库处理批处理数据或长时间处理（作为报告...）

我的客户还说：他们想使用商店来修复项目而不重新部署。我解释说，当改变业务逻辑时，可能我们需要改变输入、输出和用户界面，那么我们仍然需要重新部署，我们应该把业务逻辑从数据库中拿出来。但他们拒绝了。

【问题讨论】：

如果您要使用存储过程，我认为不需要更改用户界面。

有些时候，改变逻辑需要改变UI。

这个问题是有缺陷的，因为它没有将面向写入的业务逻辑与面向读取的业务逻辑分开。我在存储过程中阅读支持和反对逻辑的论点越多，关于 CQRS 和不变性等内容的阅读越多，我就越发现优化写入和读取需要不同类别的业务逻辑。你在问什么，写和读逻辑的两个类别还是只有一个？您似乎理解了我同意的想法，即将数据量大、基于集合的操作放入存储过程中，例如用于报告或大规模操作。

【参考方案1】：

如果您使用 ORACLE DB，那么永远不要试图低估存储过程的力量。我曾在许多非常繁重的应用程序中工作，是的，它们有 JAVA 层，但是在 JAVA 层根本不可能使用业务逻辑处理大量数据。所以我们将大部分数据处理逻辑移到了存储过程中，它就像任何东西一样摇摆不定。

举个例子，你想在前端显示一个逻辑报告，你确定它只有几个 Kbs，你知道生成这个报告你调用 DB 并以 MB 为单位获取记录并在 JAVA 中执行业务逻辑，是吗？快点？？

我是 java 人，但仍然支持存储过程，因为即使你可以在其中编写有用的业务逻辑，你也可以做很多事情。

存储过程也适用于 DB 层，因此它总是比 JAVA 快。根据我的观点，您在 JAVA 业务层中的复杂 DB 相关查询只需移动到存储过程并使用 java 检索所需的输出并显示前端也一样。

此外，我想把存储过程的最佳优点。

它更快，因为多个 SQL 查询等可以在一次“往返”数据库中执行

使用来自多个应用程序的存储过程很简单

一个地方比多个地方更容易维护

数据库快速且经过优化，可以很好地扩展。

可以从多种不同的框架和语言调用相同的过程。

逻辑与特定应用程序中的实现分离。

当数据库保持不变时，可以减少更改应用程序的返工。

【讨论】：

我同意你的看法，当处理大量数据和报告等功能时，我们将使用 store。但我的客户要求提供所有业务逻辑，而不是某些逻辑需要性能。

这似乎是使用存储过程的最佳论据，对于数据量大的集合级操作，这些操作通常是读取操作，而不是写入操作。