数据库层的业务逻辑答案

【问题标题】：business logic in database layer数据库层的业务逻辑
【发布时间】：2011-10-23 17:46:08
【问题描述】：

我不想再问“数据库中的业务逻辑与代码中的业务逻辑”这个经典问题，但我需要一些具体的理由来说服年长的开发团队相信代码中的业务逻辑更好，因为它更易于维护，最重要的是.我曾经在数据库中有很多业务逻辑，因为我相信它是单点访问。维护很容易，如果我是唯一一个进行更改的人。以我的经验，当项目变得更大更复杂时，问题就出现了。 DB Stored Procs 的源代码控制没有新 IDE 的那么先进，编辑器也没有。代码中的业务逻辑可以比在数据库中更好地扩展，这是我在最近的经验中发现的。

所以，只是搜索一下 stackoverflow，我发现它的尊敬的成员完全相反的理念：

https://stackoverflow.com/search?q=business+logic+in+database

我知道对于任何情况都没有绝对的，但是对于一个给定的 asp.net 解决方案，它将使用 sql server 或 oracle，对于一个不是特别高流量的站点，我为什么要将逻辑放在数据库中？

【问题讨论】：

标签： sql-server database oracle business-logic

【解决方案1】：

取决于你所说的业务。

数据库应该做预期的事情。

如果数据的消费者和提供者期望数据库做出某些保证，那么它需要在数据库中完成。

有些人不在他们的数据库中使用参照完整性，而是期望系统的其他部分来管理它。有些人直接访问数据库中的表。

我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象一样。它需要保护其边界，隐藏其实现细节并提供完整性保证，从低级完整性到一定级别，这可能被视为“业务”。

执行此操作的好方法是引用完整性、存储过程、触发器（必要时）、视图、隐藏基表等。

【讨论】：

感谢您的回答 - 不过，当我指的是业务逻辑时，我更多地指的是非常具体的业务逻辑，例如“该员工是否允许为该部门增加费用”......参考完整性和触发器可以帮助我保护孤立数据并保留外键，但它不会帮助我进行我提到的检查。这样的东西应该在哪里？
@Cade 我完全同意你的看法，除了如果你隐藏太多或做太多 Views 和 Sprocs 很容易变得几乎无法管理。我见过重构案例，其中视图之上有视图，并且用于管理几乎所有内容的存储过程。好的设计可能会阻止很多这种情况，这就是发明 3 层和 n 层架构的原因。尽量避免很多此类问题。
@M.R.您关于员工和部门的案例很可能是数据库之外的案例。另一方面，如果多个应用程序可能正在执行插入操作（例如来自 SSIS 包的订单，带有 Web 前端和 Windows 服务），那么您很可能希望数据库强制执行它 - 或强制所有用户通过某种应用服务器或网络服务。
@Jesus Ramos 让任何应用程序都能够查看表会阻止您重构数据库，并且也难以管理暴露给应用程序的数据库表面积，因为您必须搜索更多不仅仅是 proc 的消费者，而是在任何应用程序中提到的所有表。就像您说的那样，减少所有应用程序都需要通过的表面积（如 Web 服务或应用程序服务器）的层可以提供帮助。另一方面，数据库可以在中小型场景中同样出色地执行该层，并且移动部件更少。
@Cade 在某些情况下确实如此。视图非常适合这种封装，并且它不添加任何业务逻辑（有时）。我看到的问题是，当您使用具有验证逻辑的 sprocs（最大罪魁祸首）时，可以在将数据发送到数据库之前轻松检查这些内容

【解决方案2】：

数据库做数据的事情，为什么要权衡已经受到很大打击的东西才能给你数据。这是性能问题和代码问题。维护业务逻辑代码比将其全部存储在数据库中要容易得多。 Sprocs、Views 和 Functions 只能走这么远，直到你有 Views of Views with sprocs 来填补这个烂摊子。有了业务逻辑，你就可以分离你的担忧。如果您有一个导致计算错误的错误，则检查业务逻辑代码比进入数据库查看是否有人在存储过程中搞砸了更容易。这是高度自以为是的，在某些情况下，将一些逻辑放入数据库中是可以的，但我对此的想法是它是一个数据库而不是一个逻辑库，把东西放在它们所属的地方。

P.S：这篇文章可能会引起一些热议，它是高度固执己见的，除了性能数据之外，这两者都没有真正的证据，它成为你正在使用的一个案例。

编辑：凯德提到的一些我忘记的东西。参照完整性。无论如何，请在您的数据库中保持正确的数据完整性，在 DELETE CASCADE、支票等方面没有孤立记录。

【讨论】：

是的，我知道 :)。当 DB 的执行速度比框架快得多时，整个“数据库中的业务逻辑”是一种较旧的哲学（或者我是这么认为的）。今天的框架更好、更快、更灵活、更可扩展，所以我不认为这种理念占了上风。但我对 stackoverflow 的搜索似乎表明并非如此......
@M.R.我自己对此有点震惊。我已经在许多地方进行了性能测试，我一直在努力阻止这种做法，因为它使数据库陷入困境，无法在那里执行很多逻辑。 .NET 框架（现在非常流行）非常快，PHP 也非常快，后者非常常用于 DB 后端。没有理由真正将更多工作转储到数据库中（至少我是这么认为的）。
我还要指出，许多“开发人员”实际上并不擅长编写 SQL。因此，他们放入数据库的“逻辑”可能表现不佳，他们将此归咎于数据库而不是他们使用的技术。触发器的过度使用、游标的几乎所有使用、由于对可搜索性的误解导致的低效查询以及基本的索引策略都在这里发挥了作用。
@Cade 很多人主要在数据端玩，你对一些开发人员和他们的 SQL 技能是绝对正确的。这就是为什么让 DBA 将所有 SQL 都写在 DB 上然后使用它的原因如此诱人。
@Jesus Ramos 只要 DBA 有系统架构经验。对于让开发人员正确地工作，他们通常会持封闭态度。

【解决方案3】：

我曾在一个大型项目中遇到过数据库逻辑问题。这是由作为 DBA 专家的主要经理的决定引起的。他说应用程序应该是轻量级的，它应该对数据库方案、连接表等一无所知，并且无论如何存储的 Procs 的执行速度要比来自客户端的事务范围和查询快得多。另一方面，我们在数据库对象映射（存储产品或基于视图的视图基于其他视图等）方面存在太多错误。无法理解我们的数据发生了什么，因为单击的每个按钮都称为一个巨大的存储过程，其中包含 70-90-120 个参数并更新了几个 (10-15) 表。我们无法查询简单的选择请求，因此我们必须为此编译一个视图或在代码中存储 Proc 和类，仅用于一个简单的连接:-(当然，当表或视图定义发生更改时，您应该重新编译所有其他基于 dB 的对象在其他地方的编辑对象上，您将获得运行时异常。所以我认为数据库中的逻辑是一种可怕的方式。当然，如果性能或安全问题需要，你可以将一些代码存储在存储过程中，但你不应该在数据库中开发所有东西）逻辑应该是灵活的、可测试的和可维护的，你不能使用数据库来达到这一点存储逻辑）

【讨论】：