让我们假设应用程序在模型/表示层中具有所有必要的业务规则并且它们工作正常。我的问题是冗余业务规则（即两个日期的跨度不能与任何其他现有跨度重叠）是否应该在像 SQL Server 这样的存储库中使用。
在 SQL Server 中添加强制执行此规则的约束是否有必要/有益？一方面，它可以防止任何人（包括 DBA）在绕过应用程序时无意中破坏业务规则。此外，我们已经通过主键和外键在存储库中拥有一些形式的业务规则。另一方面，重复的规则需要额外的时间来开发和维护。
这个问题跨越了许多不同的技术，所以我故意保持标签通用。
如果您关心您的数据，您会将所需的规则放在那里而不是其他任何地方。数据受到应用程序之外的许多地方的影响。仅将规则放在业务层中是短视的，并且会导致严重的数据完整性问题，而尝试修复可能会很糟糕。有关数据的规则，属于数据库。
您通常会发现在多个地方手动维护业务规则非常困难。
我在一些项目中很好地利用了代码生成，从需求模型中生成了一些类型的规则。例如，我可能有“名字不得超过 50 个字符”的要求。我以结构化方式在 UML 中对该需求建模，然后生成 UI 代码以将输入限制为 50 个字符，业务逻辑强制执行相同的限制（永远不要相信 UI！），以及 DDL/ORM 映射文件以指定列宽数据库。
同样的想法可以扩展到对更复杂的规则进行建模，并在应用程序的每一层生成适当的执行代码。
业务规则还是数据完整性规则？
我的经验（主要是大型企业，我们不是在这里谈论软件公司或业余爱好商店）是您的数据库将比应用程序更持久。并最终让其他应用程序与之交谈。如果没有规则（任何类型的）到位，某个地方的某个人会破坏数据库。
你自己说的......是什么在后门上强制执行业务规则（即 DBA 戳数据）。如果你担心这会发生，那就付出代价。如果不是，则将其关闭，以便其他地方执行的规则不会是多余的。
取决于您的应用程序 - 如果打算与数据库无关，请将逻辑保留在应用程序代码中。否则，业务规则更适合数据库。