何时优先采用应用代码同步非规范化列而非触发器？以SO为例

• 触发器的调试与排查成本极高：触发器是数据库层面的隐式逻辑，一旦投票数出现不一致，很难追踪是哪条触发器执行出了问题——尤其是高并发场景下，过渡表的操作日志散落在数据库底层，排查难度远大于应用层的清晰日志。SO流量极大，出问题后快速定位修复是核心需求，应用层逻辑的日志能直接关联到具体请求和操作，排查效率高得多。
• 触发器存在性能瓶颈：高并发下，每一次投票操作都会触发触发器同步更新posts表，相当于一次投票要写两次数据库（votes表+posts表）。而应用层可以做灵活优化：比如批量攒更新请求定时刷库、用缓存先扛住实时展示后台异步同步，甚至根据流量动态调整同步策略，这些都能大幅降低数据库的写压力，触发器根本做不到这种灵活的性能调优。
• 业务逻辑扩展性差：投票逻辑不是一成不变的——比如后续加投票取消、不同等级用户投票权重区分、防刷机制等。如果用触发器，每次修改逻辑都要动数据库层面的代码，还要考虑兼容性，甚至可能需要锁表；而应用层代码可以在不影响数据库的情况下快速迭代，还能和用户积分、系统通知等其他业务逻辑无缝联动，灵活性远超触发器。
• 无法适配分布式架构：SO的架构是分布式的，多个服务可能都涉及投票操作。触发器只能在单个数据库实例生效，后续如果做分库分表，触发器的同步逻辑会直接失效。而应用层可以通过分布式事务、消息队列等方案，在分布式场景下保证数据一致性，扩展性更强。
• 数据一致性的可控性不足：触发器是强同步的，一旦votes表写入成功，posts表必须立刻更新，否则整个事务会失败。但实际场景中，投票数的轻微延迟用户完全可以接受，应用层可以采用最终一致性方案——比如用消息队列异步更新，就算中间出问题，也能重新消费消息补更，不会影响用户的投票操作；而触发器一旦同步失败，用户的投票直接失败，体验更差。

内容的提问来源于stack exchange，提问作者sh03