我有一个很长的地理算法，它从源列计算很多列。尽管许多列是根据源列计算的（源列在算法的开头），算法开头的某些列和算法中间的列可以由工作者更新，因此算法部分（或算法子树）应该从新插入的（由其他工作者测量，而不是计算或推测的数据）引用列中重新计算。数据不只是在一个表中，所以有时它也应该重新计算其他表的值。
我的问题是什么是最好的选择？
我只需要为列编写触发器，以后可以更改什么？并且，例如，如果触发器A在算法的开头，触发器B在算法的中间，并且如果工作者改变了开头，则触发器A被调用并且应该运行，直到它改变了触发器B连接到的字段？触发器B会继续刷新程序吗？我想得好吗？
如果这个问题不太准确，我很抱歉，但我没有这样做的经验，也没有任何同事可以帮助我提供建议。（我在论坛上发现，你不能保证触发器会以正确的方式从彼此调用，可能会以错误的顺序调用）
所以，要调用：你有一些业务逻辑被分解为几个部分。这些部分产生用户可以覆盖的中间结果。当用户覆盖中间结果时，您需要立即重新执行业务逻辑中的后续步骤。
首先，触发器有各种各样的gotha，除非万不得已，否则人们会避开触发器
- 触发器总是在事务中捕获，例如，当出现问题时，很难记录错误
- 触发器中有相当多的逻辑会使插入和/或更新速度变慢，此外，您的应用程序需要考虑到这一点，您可能会遇到死锁问题
- 听起来你计划在一个表上有多个触发器，一个在一组字段上触发，另一个在另一组字段中触发。不幸的是，这是不可能的。触发器绑定到一个表。将生成的数据与用户输入的数据分离到单独的表中可能是明智的
- 小心触发器触发其他触发器，在你意识到它们处于无限循环中之前
编辑：由于不知道您的确切情况和需求，很难就架构决策提供建议。一如既往，这取决于情况。我唯一能做的就是给出要考虑的指标。正如我所指出的，触发器（任何交易）都应该尽可能短地完成。如果你怀疑这需要一两秒钟以上的时间，你可能需要重新考虑使用触发器。
有一次，我的触发器遇到了麻烦，每隔一段时间就会出现死锁。为了解决这个问题，我修改了触发器，将更新后的id插入到一个新表中，并让存储过程每5分钟处理一次由计划作业触发的id。
以上内容对我来说很好，对你来说可能也可能不好。
另外一个小技巧是，将OO设计模式应用于SQL代码。以后不可避免的重构将不会那么痛苦。
查看一个示例模式和场景确实会有所帮助——现在，很难做到精确。
然而，对这种事情使用触发器通常是个坏主意（好吧，这是个人意见）。
触发器起到副作用。当涉及到代码时，副作用是一件坏事-它们很难调试，开发人员发现很难仔细考虑所有场景，而且很容易创建永无止境的循环（在表a上插入触发器，在表B中更新记录，在表B上更新触发器，在表格a中插入记录，在表格a上插入触发器等）
触发器的性能也很难调整。听起来你在做一组相当复杂的计算；当使用复杂的触发器时，很难确保整个系统的性能是可接受的。
你描述的场景中，多个进程可能会导致计算启动，不同的触发器一起工作，听起来可能会创建几十个不同的触发器序列。在所有这些可能的序列中保证逻辑听起来可能相当复杂。交易管理可能锁定
相反，我建议使用异步排队系统。每当应用程序更改记录时，它都会在队列中弹出一个任务，异步进程从队列中读取并运行更新数据所需的任何逻辑。这在发布源数据和更新依赖表之间引入了延迟，但它更容易调试，更容易调整性能，锁定数据库的可能性也更小。