大家好，目前遇到一个问题，我想请教一下大家，就是比如我有 A B C D 四张表，存在部分数据依赖关系，比如 A 表的某个字段，依赖 B 表的某些字段，一旦 B 表做了修改，A 表也得重新更新，同理 B 表会依赖 C 表，C 表会依赖 D 表
目前公司代码中，每一个表的 ORM 都有对应 save 方法的 前置和后置方法，然后现在用法就是比如 B 表修改了数据，因为 A 表依赖 B 表中的数据，所以 B 表修改数据之后 A 表要同步更新，就会将这部分代码写在 B 表的 save 前置或者后置方法，但是这样当相互关联依赖的表如果很多的话，感觉代码逻辑的可读性就很差，尤其是在这些前置后置方法里面，又写了非常多的业务逻辑判断，就不知道怎么去优化代码结构
因为我个人理解是这些 orm 中比如 save 前置或者后置方法，个人感觉的话，这部分方法里面写的代码内容，最好不要涉及到太多的逻辑判断，只写一些通用的，请问大家有什么建议吗？
就比如说之前同事遗留的代码，订单主表 A 表，和订单明细表 B 表，B 表的模型里面 save 的后置方法就写了非常多的条件判断，根据不同逻辑执行不同的 A 表的数据以及状态修改，个人感觉就很奇怪，但是又不知道怎么去优化,
仔细思考了下，感觉奇怪的原因主要是这种写法，B 表模型里面 save 的后置方法，会在 B 表所有的修改操作之后都会去触发，这样尽管里面写了很多逻辑判断，并不是无脑全部执行，但是以后扩展部分业务逻辑，这个位置的代码难免会有没有考虑到的情况，而且也会继续在这里面新增逻辑判断和处理代码，就感觉这里面的代码会越来越多，越来越难维护,非常感谢大家能指导我一下

提供收费指导

你这个所谓的依赖关系说的不是很清楚，所以无法行设计模式上给你建议。如果从sql角度去想，多个表更新，你可以考虑update join结构的语句，或者把复杂的更新逻辑判断写在stored procedure里面。完全写在before/after这种方法里肯定会造成逻辑混乱。

没有限制，可以用数据库触发器来做，不用写一堆代码来维护。