我有一个很长的地理算法，它从源列计算很多列。尽管从源列计算了很多列（源列位于算法的开头），但算法开头的某些列和算法中间的列可以由工人更新，因此算法部分（或算法）子树）应该从新插入的（由其他工人测量，而不是计算或猜测的数据）参考列重新计算。数据不只是在一个表中，因此有时它也应该重新计算其他表值。
我的问题是什么是最好的选择？
我只需要为列编写触发器，以后可以更改？并且，例如，如果在算法开始时触发A并在算法中间触发B，并且如果工作人员改变了开头，则触发A调用并且应该运行直到它改变字段触发B连接到哪个？并会触发B继续刷新程序？我对此有好感吗？
很抱歉，如果这个问题不太准确，但我没有这方面的经验，而且我没有任何可以帮助我提供建议的同事。 （我在论坛上发现你不能保证触发器会以正确的方式从对方调用，也许会以错误的顺序调用）
答案 0 :(得分：0)
所以，召唤：你有一些业务逻辑在几个部分细分。这些部分产生用户可以覆盖的中间结果。当用户确实覆盖中间结果时，您需要立即重新使用业务逻辑中的后续步骤。
首先，触发器有各种各样的东西，除非他们绝对不得不让人们远离触发器。即：
修改 不知道您的确切情况和要求，几乎不可能就建筑决策提出建议。一如既往，这取决于。我唯一能做的就是指出要考虑的事项。正如我所指出的那样，触发器（任何事务）都应尽可能缩短完成时间。如果您怀疑它需要花费一两秒钟，您可能需要重新考虑使用触发器。
一旦我遇到麻烦，每隔一段时间遇到麻烦就会遇到麻烦。为了解决这个问题，我更改了触发器以将更新后的id插入到新表中，并使存储过程处理由预定作业触发的每5分钟ID。
以上对我来说很好，可能会也可能不适合你。
一个额外的小提示，将OO design paterns应用于您的SQL代码。以后不可避免的重构将不那么痛苦。
答案 1 :(得分：0)
查看示例架构和场景真的很有帮助 - 现在，很难准确。
然而，使用触发器来做这件事通常是个坏主意（好吧，这是个人意见）。
触发器充当副作用。在代码方面，副作用是一件坏事 - 它们很难调试，开发人员很难通过所有场景进行思考，并且很容易创建永不停止的循环（在表A上插入触发器，在表中更新记录） B，表B上的更新触发器触发，在表A中插入记录，在表A上插入触发器等等......）。
触发器也很难调整性能。听起来你正在做一套相当复杂的计算;确保在使用复杂触发器时整个系统的性能是可接受的很难。
您描述的场景，多个进程可以导致计算触发，不同的触发器一起工作，听起来像是可以创建许多不同的触发序列。保证所有这些可能序列中的逻辑听起来可能相当复杂。交易管理可以锁定
相反，我建议使用异步排队系统。每当应用程序更改记录时，它就会弹出队列中的任务，并且异步进程从队列中读取并运行更新数据所需的任何逻辑。这会在发布源数据和更新依赖表之间引入延迟，但调试起来要容易得多，调整性能要容易得多，而且锁定数据库的可能性也大大降低。