数据库中的业务逻辑与代码中的区别？

Question

数据库中的业务逻辑与代码中的区别？

databasearchitecturemethodologyn-tier-architecture

77

作为一名软件工程师，我倾向于在应用层编写业务逻辑，而通常只在数据库中依靠CRUD（创建、检索、更新和删除）操作。另一方面，我遇到过一些应用程序（通常是较旧的应用程序），其中大量的业务逻辑是写在存储过程中的，因此有些人更喜欢在数据库层编写业务逻辑。

对于那些已经或喜欢在存储过程中编写业务逻辑的人来说，使用这种方法的原因是什么呢？

- senfo

15

我是一名数据库管理员。数据逻辑应该在数据库中处理。为了完成所需的功能，你操纵数据库结构的方式应该被保留在数据库中。当你将这些操作组合成更大的一系列流程（业务逻辑）时，这些流程可以被合并到应用程序中。 - Guy

IT经理是问题所在。他们误用DBA，期望他们成为系统开发的一部分。DBA只是使用手头的工具。我是一个全栈开发者。我已经清理了多年的“数据逻辑”，并说服我的雇主禁止使用存储过程来处理业务流程，在从数百个查询中提取Excel电子表格工作之后，其中一个过滤了财务数据。处理只属于应用程序，其中界面为用户提供控制和信息。换句话说，SP仅用于数据库工作，而不是用户数据输入。 - RBJ

16个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Austin Salonen · Answer 1

过去我将业务逻辑放在存储过程中的主要原因是数据库中的事务更容易处理。

如果你的应用程序部署困难且没有应用服务器，那么改变存储过程中的业务逻辑是最有效的部署更改的方式。

- Ben · Answer 2

我在一个团队中负责建立和维护一个相当大的金融系统，但是对于与数以万计记录相关的操作逻辑，我找不到将其放入应用程序层的方法。

除了性能问题外，如果出现错误，修正存储过程比调试应用程序、修复、重新编译和部署代码所需的停机时间更短。

- Byron Whitlock · Answer 3

有时业务逻辑在应用层上运行太慢。这在旧系统上尤为明显，因为客户端的功率和带宽更有限。

- Rap · Answer 4

使用数据库进行工作的主要原因是您有一个单一的控制点。通常，应用程序开发人员在应用程序的不同部分重复使用或重写代码片段。即使假设它们完全以相同的方式工作（这值得怀疑），当业务逻辑发生变化时，应用程序需要进行审核、重新编码和重新编译。除非参数发生变化，否则仅在数据库中存储业务逻辑即可避免此类问题。

- Mr. Will · Answer 5

我的偏好是将任何复杂的业务逻辑从数据库中剥离，仅出于维护目的。如果我在凌晨两点接到电话，我宁愿调试我的应用程序代码，也不愿意尝试逐步执行数据库脚本。

- santosh · Answer 6

我认为对于我正在处理的老应用程序（银行业务），其中业务逻辑非常复杂，几乎不可能在应用层执行所有这些业务逻辑。而且，当我们将这些逻辑放在应用层时，这会是一个巨大的性能问题，因为需要从数据库中获取更多的数据，导致资源利用率更高（如果在Java层完成，则需要更多的Java对象）和网络问题，性能也会受到影响。