7

我一直在我的应用程序层（模型）和数据库层（引发错误的存储过程）中执行业务规则。

出于以下几个原因，我一直在这两个地方重复我的验证：

  1. 如果在检查应用程序代码和检查数据库之间的条件发生变化，则数据库中的业务规则检查将节省时间。数据库还允许我以比在我的应用程序代码中更简单的方式锁定各种记录，所以在这里这样做似乎很自然。
  2. 如果我们必须直接对数据库进行一些批量数据插入/更新，如果我通过执行业务规则验证的存储过程/函数路由所有这些操作，即使我缺少如果我通过应用程序进行单输入，我会得到保护。
  3. 虽然仅在数据库中执行这些操作会对实际数据产生相同的影响，但在首先努力验证它是否符合约束和业务规则之前将数据扔到数据库中似乎是不合适的。

什么是正确的平衡？

4

3 回答 3

6

您需要在数据层强制执行以确保数据完整性。这是您的最后一道防线，也是 DB 的工作，以帮助实施其数据的世界观。

也就是说，将垃圾数据扔到数据库中进行验证是一种粗略的技术。通常，错误被设计为人类可读而不是机器可读，因此程序处理来自数据库的错误并从中产生正面或反面的效率很低。

存储过程是另一回事。过去，存储过程是处理数据层等业务规则的方式。

但是今天，随着现代应用程序服务器环境的出现，它们通常已成为放置这种逻辑的更好地方。它们提供多种访问和公开数据的方式（Web、Web 服务、远程协议、API 等）。此外，如果您的规则占用大量 CPU（可以说大多数不是），那么扩展应用服务器比扩展数据库服务器更容易。

应用服务器中的大量功能为它们提供了超出数据库服务器所能做的灵活性，因此曾经被推回数据库的大部分内容都被撤出，而数据库服务器则被降级为“愚蠢的持久性”。

也就是说，使用存储过程等肯定有性能优势，但现在这是一个调整问题，问题变成“为了我们通过将其放入数据库服务器而获得的收益而失去应用服务器功能是否值得”。

通过应用服务器，我不是简单地谈论 Java，而是 .NET 甚至 PHP 等。

于 2010-11-18T16:39:37.337 回答
3

如果无论数据来自何处或如何更新，都必须始终执行该规则，那么数据库就是它需要的位置。请记住，数据库会受到直接查询的影响，以进行影响许多记录的更改或执行应用程序通常不会执行的操作。例如，当客户被另一位客户收购并且他们想要更改所有历史数据时修复一组记录，对尚未处理的订单应用新税率，修复一些错误的数据输入。它们有时也会受到不使用您的数据层的其他应用程序的影响。它们也可能受到通过 ETL 程序运行的导入的影响，这些程序也无法使用您的数据层。因此，如果必须在所有情况下都遵循该规则，则它必须在数据库中。

如果规则仅适用于有关此特定输入页面如何工作的特殊情况，则它需要在应用程序中。因此，如果销售经理只能通过其用户界面执行特定的操作，则可以在应用程序中指定这些操作。

在这两个地方做一些事情是有帮助的。例如，允许用户在与日期字段相关的输入框中输入非日期是愚蠢的。数据库中的数据类型应该仍然是 datetime 数据类型，但最好在发送之前检查其中的一些内容。

于 2010-11-18T22:33:55.150 回答
2

您的业​​务逻辑可以位于任一位置，但不应同时位于这两个位置。不应该重复逻辑，因为试图保持两者同步很容易出错。如果您将其放入模型中，您将希望所有数据访问都通过您的模型，包括批量更新。

将其放入数据库与应用程序模型之间需要权衡取舍（这是我的一些想法）：

  • 数据库可能比应用程序更难维护和更新
  • 如果它在应用程序层中，则更容易分配负载
  • 多个不同的数据库可能需要拆分业务规则（这可能是不可能的）
于 2010-11-18T16:41:22.220 回答