数据库业务逻辑 VS 代码? ？

有时业务逻辑在应用程序层上运行太慢。在客户端功耗和带宽更为有限的老系统上尤其如此。

在一些场合，我把“逻辑”放在 sprocs 中，因为 CRUD 可能发生在不止一个地方。通过“逻辑”，我不得不说它不是真正的业务逻辑，而是更多的“完整性逻辑”。这可能是相同的-一些清理可能是必要的，如果某些东西被删除或更新，以某种方式，如果这种删除或更新可能发生在不同的工具，不同的代码基础，这是有意义的把它放在他们都使用的过程。

此外，有时“业务逻辑线”是相当模糊的。以报告为例——它们可能依赖于存储过程或视图，这些存储过程或视图封装了关于模式对业务意味着什么的“智能”。您多久看到一次 CASE 语句或类似的基于列值或其他条件的“做事情”？可以解释为业务逻辑，但它可能确实属于数据库，在那里可以进行优化，等等。

将业务逻辑放入数据库的两个很好的理由是:

• 它保护您的逻辑和数据 的额外申请 可以访问数据库 实现类似的逻辑。
• 数据库设计通常比 应用层，它减少了 当你搬到新的地方时必须做的工作 客户端的技术。

您通常会在数据库层找到业务逻辑，因为进行更改和部署通常会更快。我认为最好的意图往往不是把逻辑放在那里，而是因为部署的容易性，它最终会放在那里。

使用数据库完成工作的主要原因是您只有一个控制点。通常，应用程序开发人员在应用程序的不同部分重用或重写代码片段。即使假设所有这些都以完全相同的方式工作(这是值得怀疑的) ，当业务逻辑发生变化时，应用程序也需要进行审查、重新编码和重新编译。如果业务逻辑只存储在数据库中，则除非参数发生更改，否则不需要这样做。

我倾向于将任何复杂的业务逻辑排除在数据库之外，只是为了维护的目的。如果我在凌晨2点接到一个电话，我宁愿调试我的应用程序代码，而不是尝试逐步通过数据库脚本。

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

如果您的应用程序很难部署，而且您没有应用服务器，那么更改存储过程中的 BL 是部署更改的最有效方法。

我尽量严格地将 DB 中的业务逻辑限制在仅需要执行大量查询和更新才能执行单个应用程序操作的处理器上。有些人可能会争辩说，即使这样也应该在应用程序中，但是如果可以的话，我希望保持 IO 的低调。

数据库对于 CRUD 来说是很棒的，但是如果它们因为逻辑而变得臃肿:

1. 逻辑在哪里变得混乱,
2. 通常，数据库是一个竖井，不能像应用服务器那样水平伸缩。
3. T _ sql/PLsql 本质上是难以阅读和过程化的
4. 你放弃了 OOAD 的所有好处。

在适当的情况下，我们在 DB 层中执行大量处理。有很多操作，你不会想把大数据集拉回到应用层进行分析。对于我们来说，这也是一个更简单的部署——单点部署与在所有安装点上更新应用程序相比。但是，这在很大程度上取决于您的应用程序及其功能; 这里没有一个好的答案。

将业务逻辑限制在应用程序层顶多是目光短浅。经验丰富的专业数据库设计人员很少允许在他们的系统上使用它。数据库需要有约束、触发器和存储过程，以帮助定义来自任何源的数据如何进入数据库。

如果数据库要维护其完整性并确保所有新数据源或数据更改都遵循规则，那么数据库就是放置所需逻辑的地方。把它放在应用程序层是一个等待发生的数据噩梦。数据库不仅仅从一个应用程序获取信息。应用程序中的业务逻辑经常无意中被导入绕过(假设您有一个新客户，他希望将他们的旧历史数据导入到您的系统或大量目标记录中，没有人会通过接口输入100万个可能的目标，这将在导入中发生)通过查询窗口修复一次性问题(比如将所有产品的价格提高10%)的更改也会绕过它。如果应用程序层逻辑应该应用于数据更改，那么它就不会应用于数据更改。现在把它放在应用程序层也是可以的，没有必要向数据库发送坏数据和浪费网络带宽，但是不把它放在数据库中迟早会导致数据问题。

将所有这些都保存在数据库中的另一个原因是，用户可能犯下欺诈行为。如果将所有逻辑放在应用程序层中，则必须授予用户直接访问表的权限。如果您将所有逻辑封装在存储进程中，那么它们只能做存储进程允许的事情，而不能做其他任何事情。我不会考虑允许用户以任何方式访问存储财务记录或个人信息(例如健康记录)的数据库，因为我不会允许任何人(除了几个 dbas)以任何形式或形式直接访问生产记录。欺诈行为比许多开发人员意识到的还要多，而且几乎没有人在设计中考虑到这种可能性。

如果需要导入大量数据，那么通过数据访问层可能会减慢爬网的导入速度，因为它没有利用数据库设计用于处理的基于集的操作。

您对“业务逻辑”这个术语的使用相当模糊。

它可以被解释为意味着包括对数据的约束的强制执行(又名“业务规则”)。执行这些明确属于数据库管理，句号。

它也可以被解释为包括“如果一个新客户来了，我们会在一周内给他发一封欢迎信。”试图在数据层中推送这样的内容可能是一个很大的错误。在这种情况下，“创建新的欢迎信”的驱动程序可能应该是也触发新客户行插入的应用程序。想象一下，每一个新的数据库行插入触发一个新的欢迎信，然后突然我们接管另一家公司，我们必须整合该公司的客户在我们自己的数据库... 哎哟。

我认为，特别是对于我工作的老的应用程序(银行业务) ，其中业务逻辑是巨大的，几乎不可能在应用程序层执行所有这些业务逻辑，而且当我们把这些逻辑放在应用程序层的数据库获取的数量更多，导致更多的资源利用率(更多的 java 对象，如果它在 java 层完成)和网络问题，忘记性能是一个巨大的性能打击。

我在一家金融类型的公司工作，这家公司的某些规则由各州执行，这些规则及其计算方法几乎每天都会发生变化，如果不是每周都会发生变化的话。在这种情况下，将处理计算的逻辑部分移动到数据库更有意义; 在数据库中可以测试和应用变更，而不必重新编译和重新分发应用程序，这不可能在不干扰业务的情况下每天进行。存储过程经过测试、批准、应用，而最终用户对此一无所知。 随着向基于 Web 的应用程序的转移，将逻辑转移到数据库的依赖性减少了，但仍然存在。即使是网络应用程序(取决于语言)也必须编译并发布到网站上，这可能会导致停机。

尽可能地将业务逻辑保持在 最具可测试性和可调试性环境中。在其他人现有的答案中存储数据库中的业务逻辑有一些合理的原因，但这些原因几乎总是远远超过这一点。

我想说，如果“业务逻辑”意味着应用程序流、用户控制、定时操作和一般的“做业务的东西”，那么它应该在应用程序层。但是，如果这意味着确保无论你如何挖掘数据，它总是有意义的，是一个明智的，非自我冲突的整体，那么执行这些规则的检查将进入数据库，绝对没有问题。总有许多方法可以将数据推入数据库，并在数据库存在时对其进行操作。并非所有这些方法都内置了“业务逻辑”。你会发现一个 SQL 会话到数据库通过一个 DOS 窗口的支持呼叫在凌晨3点是非常开放的，例如它允许什么！如果数据库中没有逻辑来确保所有数据更改都有意义，那么可以肯定的是，随着时间的推移，数据将变得非常、非常糟糕。由于一个系统的价值取决于它所持有的数据，因此它的投资回报率要低得多。

我所在的团队负责构建和维护一个相当大的财务系统，我发现没有办法将逻辑放入应用程序层，以便采取影响数十万条记录或从中获得约束的行动。

除了性能问题之外，如果出现错误，纠正存储过程要比调试应用程序、修复、重新编译、重新部署代码和延长停机时间快得多