Liquibase+Corda中调整独立changeSet顺序及拆分XML的弊端咨询

问题1：调整独立changeSet顺序是否会引发未来问题？ #

• 表间依赖冲突风险：如果后续新增的变更默认依赖当前的执行顺序（比如认为table1的所有变更先完成再处理table2），但老环境里table2_v1是在table1_v2之前执行的，一旦出现跨表逻辑依赖这个顺序，就可能出问题。举个例子：如果以后加table2_v2，需要用table1_v2新增的字段初始化数据，新环境按顺序执行没问题，但老环境里table2_v1已经有数据，若这些数据和table1_v2的新结构不兼容，就会触发业务异常。
• 校验和无直接影响：调整changeSet顺序不会导致已执行changeSet的校验和报错——校验和是根据changeSet的内容计算的，只要你没改table1_v1、table2_v1的代码，Liquibase就不会找你麻烦。但要是后续误改了已执行过的changeSet内容，不管顺序怎么调，都会触发校验和错误。
• 新老环境执行差异的坑：新环境是按table1_v1→table1_v2→table2_v1执行，老环境则是先跑table1_v1→table2_v1，再补跑table1_v2。如果table1_v2的变更（比如加唯一约束）和table2_v1已有的数据冲突，老环境执行table1_v2时直接失败，新环境却完全没问题，这种不一致的问题排查起来很头疼。

问题2：按表拆分XML方案的弊端 #

• 跨表变更难处理：遇到涉及多表的变更（比如加跨表外键、批量同步多表数据），这类changeSet没法归到单个表的XML里。要么硬塞到某一个表的文件里（破坏拆分逻辑），要么单独建跨表变更文件，最后结构越搞越乱。
• 变更顺序容易失控：把多个表的XML引入到master.xml时，要是依赖关系没理清楚，很容易搞反顺序。比如table2的变更依赖table1的某个结构，但master.xml先引入了table2.xml，新环境执行时直接先跑table2的变更，直接报错。
• 维护效率下降：表多了之后XML文件也会暴增，找某个字段的修改记录得翻好几个文件，追溯变更历史的时候特别麻烦，不如集中式的changelog文件直观。
• Corda集成的额外复杂度：Corda节点的数据库变更有自己的一套流程，按表拆分XML得额外操心master.xml的引入顺序，要是节点加载changelog的逻辑有特殊要求，拆分后的文件可能引发加载顺序问题，调试起来更费时间。

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