一个大型SQL事务数据库有100多个表（而且还会增长）。其中之一称为订单。然后，还有另一个从 Order 派生的表工作负载和许多其他连接表，其中包含所有活动订单的列表。每次创建订单记录时，如果它满足某些条件，则应立即将其插入到工作负载表中。最后，还有第三个表WorkLoadAggregation，它显示按日期和商店分组的聚合数据，它完全是从WorkLoad表构建的。工作负载聚合还应显示实时数据，这意味着如果在工作负载表中插入记录，则还应更新匹配的日期/商店聚合。
我的想法是通过以下触发器来处理这个问题：
- 在 Order 表中插入记录
- 时，触发器调用将记录插入到工作负载表中的存储过程
- 删除订单记录时，触发器会从工作负载表中删除记录
- 当订单记录以不符合工作负载条件的方式更新时，触发器将从工作负载表中删除记录 在工作负载表中插入/删除/更新记录
- 时，触发调用存储过程，以更新工作负载聚合表中的匹配日期/商店聚合记录
大的事务数据库和如此频繁的调用中使用过多触发器。这种方法有什么不好吗？我最担心的是"链式触发器"的使用，这意味着一个表上的触发器会激活另一个表上的触发器。我一直在阅读一些文章，其中指出开发人员在使用触发器时应该非常谨慎。有没有更好的解决方案？我应该考虑任何NoSQL解决方案吗？
数据库托管在 SQL Server 2012 上。
注意：在案例 5 中，调用的存储过程包含 CTE（如果有人建议使用索引视图）
提供更具体的意见有点困难，但基于问题空间的呈现。 我不推荐这个解决方案，因为它很难有效测试，而且我可以看到这会导致高负载时出现问题。 此外，很难量化总影响，因为我不确定读取负载会是什么样子，以及有多少其他进程可能需要从这些表中获取信息。
根据你如何描述这个问题，以及你询问NoSQL方法的事实，我认为最终的一致性不是一个大问题，所以我会推荐一个更事件驱动的架构。 请记住，这可能意味着对当前实现的重大重写，但肯定会允许更好的域分解和扩展。