是否为此方案使用触发器最佳解决方案

Question

一个大的SQL事务数据库有超过100个表（它会增长）。其中一个叫做订单。然后，还有另一个表 WorkLoad ，它派生自Order和许多其他连接表，其中包含所有活动订单的列表。每次创建订单记录时，如果它满足某些条件，它应立即插入WorkLoad表。最后，还有第三个表 WorkLoadAggregation ，它显示按日期和商店分组的聚合数据，它完全由WorkLoad表构建。 WorkLoadAggregation还应显示实时数据，这意味着如果在WorkLoad表中插入记录，则还应更新匹配的日期/商店聚合。

我的想法是通过跟踪触发器来处理这个问题：

1. 当记录插入订单表时，触发调用将记录插入WorkLoad表的存储过程
2. 删除订单记录时，触发器会从WorkLoad表中删除记录
3. 当订单记录更新以不符合WorkLoad条件的方式时，触发器会从WorkLoad表中删除记录
4. 当在WorkLoad 表中插入/删除/更新记录时，触发调用存储过程以更新WorkLoadAggregation表中匹配的日期/商店聚合记录

我没有在如此大的事务dbs和这种频繁的调用中使用过多的触发器。这种方法有什么不好的吗？我最关心的是使用“链式触发器”，这意味着一个表上的触发器会激活另一个表上的触发器。我一直在阅读一些文章，其中指出开发人员在使用触发器时应该非常谨慎。还有更好的解决方案吗？我应该考虑任何NoSQL解决方案吗？

数据库托管在SQL Server 2012上。

注意：在案例5中，被调用的存储过程包含CTE（有人建议使用索引视图）

Answer 1

提供更具体的意见有点困难，但基于问题空间的呈现。我不推荐这种解决方案，因为很难有效地测试，我可以看到这会导致高负载时的问题。此外，很难量化总影响，因为我不确定读取负载的外观以及有多少其他进程可能需要这些表中的信息。

根据您对问题的描述以及您询问NoSQL方法的事实，我认为最终的一致性并不是很重要，因此我建议使用更多的EventDriven架构。请记住，这可能意味着重写您当前的实现，但肯定会允许更好的域分解和扩展。