数据库触发器使用 - 最佳实践

Question

简要背景：

我目前维护着一个有15年历史的库存管理系统。为了提供单个物品和工具包的现有实时数量（可能嵌套到第N级），当请求页面时，库存被动态分配给订单（分配优先级由收到的日期和日期决定）预期）。根据系统中的订单数量，更具体地说，这些订单中有多少订单包含嵌套套件，性能可能会成为一个问题。

问题：

我们目前正在使用SOA原则设计新的库存管理系统。我们希望在每次插入，更新和删除之后更新可能影响项目分配数据的分配表，而不是动态分配库存。关于是否应该通过DB中的触发器或C＃订单服务更新分配表存在争议。

• 哪种方法最符合SOA原则？
• 哪种方法会更高效？
• 这是否正确使用了触发器？
• 这两种方法是否被社会普遍接受为“正确的做事方式”？

提前感谢您的时间！

Answer 1

我认为HLGEM，Jimbo，Joel Brown的其他3个答案都是正确的。

回答每个具体问题

哪种方法最符合SOA原则？

要么取决于您的架构的其余部分。你有多少其他系统？其他系统是否需要直接访问数据库，还是通过此服务访问数据库？

哪种方法更具效果？

无论如何都没有真正的区别。

这是否正确使用了触发器？

是

社区普遍接受这两种方法作为“做事的正确方法”吗？

社区似乎没有因这种决定而分裂，应该逐案进行评估。

Answer 2

我认为这归结于旧的宗教战争，即是否在TSQL中存在任何业务逻辑（存储过程或触发器）。有些人喜欢尽可能多地将逻辑引入数据库层，而其他人则认为这是你能做的最糟糕的事情。

看看this question对各种利弊的冗长辩论。无论你认为最引人注目的是你应该采取的方式。

Answer 3

触发器是唯一可以保证数据保持同步的解决方案。您无法保证在应用程序外部不会更改值（例如修复某些大数据问题），因此触发器是唯一正确的解决方案。

Answer 4

如果插入，更新和删除是由存储过程执行的，那么分配表也应该在这些存储过程中更新 - 这将是理想的解决方案。

否则，如果应用程序正在执行insert，update和delete，那么触发器将执行您所需的操作 - 但请记住，应始终避免触发器，如果​​必须让它们保持尽可能简单，这是因为触发器很快就会很难调试。