我看过关于FlyWay处理多个数据库的帖子，但它们似乎都是独立的数据库。据我了解，FlyWay每个实例只能处理一个数据库，因此创建/清理数据库模式是完全独立的。
Multiple datasources migrations using Flyway in a Spring Boot application
我们的问题可能源于糟糕的数据库设计，但它就是这样，它不会很快改变。至于后台，这是一个带有MSSql DB的C＃旧学校应用程序，我们目前只是使用FlyWay命令行进行评估。
DB（s）设置如下。
我有一些示例，其中AppDB具有引用其他表的视图/过程/等。还有其他DB访问AppDB的情况（IE ArchiveDB存储过程将从AppDB中提取）。
由于不同数据库之间存在这种依赖关系，FlyWay是否可以按所需顺序处理迁移/清理？例如
如果我有这个脚本顺序
如何更好地处理它呢？
答案 0 :(得分：0)
这可能是一个棘手的问题，尤其是对于具有循环依赖关系的ArchiveDB。
我正在处理的项目上有类似的设置。它们实际上是Oracle数据库中的不同模式，但是我们选择为每个模式保留一个单独的schema_version表（尝试保持信息显示可管理）。我们使用的方法是以依赖关系的主要顺序对我们的目录进行编号，并确保我们按该顺序应用。你的可能是：
10_AppDB
20_AppLogDB
30_AppAuditDB
40_AppArchiveDB
循环依赖关系是一项更多的工作，以确保它们可以正确地应用于干净的环境。幸运的是，我们没有遇到过这种情况，但未来可能会发生变化。我建议的方法是错开部署（使用migrate上的目标选项/属性），以便以必要的顺序创建对象。然后，当在新环境中从头开始创建时，您需要跨所有数据库应用于第一个合并点，然后将所有数据库应用于下一个数据库，依此类推。以你的榜样为基础：
# run flyway -target 2 for all DBs
10_AppDB___/V1__AppDB_Create_table
20_AppLogDB/V2__ArchiveDB_Create_table
# run flyway -target 4 for all DBs
10_AppDB___/V3__AppDB_Create_proc_pointing_to_ArchiveDB
20_AppLogDB/V4__ArchiveDB_Create_proc_pointing_to_AppDb