可以使用触发器在数据库中强制执行诸如“一个父对象最多有 2 个子对象”之类的规则。但是，如果该规则已在域层中实施，那么复制该规则是否是一个好主意。
在哪些情况下重复此类规则是合理的？有没有其他方法可以避免这种重复？这不是数据完整性规则吗？
谢谢
StackUnderflow
问问题
185 次
7 回答
3
在数据库外部的代码中几乎不可能正确地做到这一点。任何查看是否已经存在 2 条记录并且如果不存在则允许添加新记录的代码都可能被同一父节点上同时运行的 2 个线程所欺骗。除非您实际上锁定数据库表或以某种方式序列化子添加过程，否则两者都会导致真正缺乏可伸缩性。
您没有提到 RDBMS，因此很难为您提供解决方案。
编辑：
我同意那些说触发器远非干净的人的观点。但它们并不是在数据库中强制执行规则的唯一方法。这就是为什么我说在不了解您的 RDBMS 的情况下，不可能提出任何数据库解决方案，甚至是可能不需要触发器的解决方案。
此外，您不需要触发器，因为您的中间层从不执行 DML，它只是调用封装您的 CRUD 的数据库过程或包。对？！
于 2009-02-11T19:32:05.523 回答
2
我认为系统的每一层都应该强制执行其设计能够处理的最大数量的约束。剩下的交给别人处理。我认为数据库约束和 javascript 约束在某种程度上属于同一类别；在保持合理清洁的同时，您可以利用可用的手段尽其所能。
触发器远远超出了我认为相当干净的范围，所以我会让业务逻辑处理这个问题。有许多数据完整性规则超出了您期望 SQL 数据库处理的范围。
于 2009-02-11T19:25:48.063 回答
1
这取决于。
如果对数据库的所有写入都由单个应用程序或服务完成，那么在应用程序/服务的业务层中实现此类业务规则是合理的。特别是如果您认为规则将来可能会改变。
但是在许多现实世界的场景中，尤其是在遗留系统中，您可能有多个编写者，并且在数据库中实现这些规则的额外复杂性可能是值得的。
所有的设计都是权衡。
于 2009-02-11T20:12:20.553 回答
1
我会要求它在触发器中的数据库中。这是因为数据库可能会受到 GUI 以外的其他因素的影响，并且在数据库级别未强制执行的这种性质的规则会导致数据完整性问题。
于 2009-02-11T20:16:10.437 回答
0
通常我会将这个逻辑排除在数据库层之外。在我看来，这听起来更像是一条业务规则，应该存在于业务层中。如果这条规则永远改变会发生什么？您想在哪里和多少个地方更新它？通常，除了通过您的业务层之外，没有任何东西可以访问数据库，因此可以不在业务层之外的任何其他地方实现它。此外，触发器很混乱，很难维护，最重要的是，以后很难调试。
无论如何，恕我直言。
于 2009-02-11T19:20:16.987 回答
0
恕我直言，触发器通常是“坏事”，但除此之外，在插入数据库表的级别执行业务规则并没有让我觉得是一个很好的“关注点分离”
于 2009-02-11T19:22:51.083 回答
0
我会尽量避免将这种类型的“业务验证逻辑”放在您的数据库层中。最终，随着应用程序的成熟，您需要对数据进行比触发器提供的更多的控制和处理。
如果您的应用程序有业务层，我将只有 SQL 强制关系，而不是规则。
于 2009-02-11T19:25:39.843 回答