我一直在我的应用程序层（模型）和我的数据库层（引发错误的存储过程）中执行业务规则。应该在应用程序层和数据库层执行业务规则，还是只执行其中一个？
我一直在重复我的验证在这两个地方有几个原因：
什么是正确的平衡？
您需要在数据层执行以确保数据完整性。这是你的最后一道防线，那就是数据库的工作，以帮助实施其世界观数据。
也就是说，将垃圾数据与DB进行验证是一种粗糙的技术。通常，这些错误的设计是为了人类可读而不是机器可读的，所以它对于程序处理来自数据库的错误并使其头部或尾部不起作用效率低下。
存储过程是另一回事。早在当时，存储过程就是处理数据层的业务规则的方式等。
但是，今天，随着现代应用服务器环境的发展，它们已经成为一个更好的放置逻辑的地方。他们提供了多种访问和公开数据的方式（网络，Web服务，远程协议，API等）。另外，如果你的规则是CPU很重（可以说大多数不是），那么扩展应用程序服务器比DB服务器更容易。
应用程序服务器中的大量功能给它们提供了超出数据库服务器所能做到的灵活性，因此，曾经推回到数据库的大部分功能都被拔出，数据库服务器被降级为“愚蠢的持久性“。
也就是说，使用Stored Procs等确实存在性能优势，但现在这是一个调整问题，问题变成了“是否值得失去应用程序服务器功能以获得我们通过将其获取到数据库服务器”。
并按照应用服务器，我不只是谈论的Java，.NET，但乃至PHP等
你的业务逻辑可以在任何一个位置坐下，但不应该在这两个。该逻辑不应该被重复，因为很容易在保持同步的同时出错。如果你把它放在模型中，你会希望所有数据访问都通过你的模型，包括批量更新。
会有取舍，以把它在数据库VS应用模型（这里是几个我的头顶部）：
如果规则必须是分配负载无论数据来自何处或如何更新，数据库都应该在哪里执行。记住数据库受直接查询的影响，以进行影响许多记录的更改或执行应用程序通常不会执行的操作。当客户被另一位客户买走时，他们想要修改所有历史数据，将新税率应用于尚未处理的订单，修复一些错误的数据输入，这些问题就像修复一组记录一样。它们也受到其他不使用数据层的应用程序的影响。它们也可能受到通过ETL程序导入的影响，这些程序也无法使用您的数据层。因此，如果必须遵守规则，则必须在数据库中。
如果规则仅针对特定情况下有关此特定输入页面的工作方式，则需要在应用程序中。因此，如果销售经理只能从他的用户界面中完成特定的事情，则可以在应用程序中指定这些内容。
有些东西在两个地方都有帮助。例如，允许用户在与日期字段相关的输入框中输入非日期是愚蠢的。数据库中的数据类型仍然是日期时间数据类型，但最好在发送之前检查一下这些内容。
业务逻辑的强制执行和数据完整性的执行有什么区别？假设我有一个业务规则，最多可以将3个人分配给主管。当我去插入＃4人时，是否因为每个主管人数超过3人的数据完整性错误而失败？还是违反了业务规则？如果在验证之前没有锁定主管记录，那么在执行插入操作时，主管下至多有两个人，应用程序代码如何100％确定该规则不会被破坏？ – 2010-11-18 16:50:29
@Rednerln - 变化率。数据库完整性规则可能被认为比业务规则长得多。你作为一个主管人员的例子，如果我这样做的话，我很难说明如何做一个数据库约束，它必须是基于数据的（基于配置设置的udf）。如果规则发生变化，那么就必须提出这个问题：如何处理违反该原则的数据。通常情况下，您希望数据库规则只能放宽，不能收敛或定性更改。 – 2010-11-18 22:39:13
@Rednerln - 在多种情况下，您希望人们能够使用他们的BI工具或其他任何方式访问您的数据库访问层（也许是视图），并知道他们的假设是有效的，数据库具有凝聚力和完整性周长。 – 2010-11-18 22:41:24