我们有一个数据库，其中存储来自外部系统的标识符等。现在标识符改变了（系统改变了方案），数据库需要更新。可以做到——我有一个映射，所以我可以生成足够多的 SQL 来让它工作，最后需要像这样完成。
问题是 - 这是 Flyway Java 迁移的用例吗？我倾向于认为情况并非如此，但我真的不能说为什么，这是一种直觉。但是，外部系统的模式没有版本化，至少我们没有，所以我觉得它根本不适合 Flyway 迁移；我认为它应该只在 Flyway 之外执行一次。
任何有更多经验的人可以提供帮助，解释为什么或为什么不？
【问题讨论】：
标签： flyway
这主要是基于意见，但在我看来，这就像用蒸汽锤敲碎坚果一样。 Flyway 对于定期迁移和案例来说是一个非常有用的工具，然后有许多数据库，您必须从头开始重新创建或定期更新它们，而不是一次性使用。
为什么在你的项目中包含一些比较大的框架，花一些时间让它工作，并且只使用一次？此外，Flyway 需要在您的数据库中存在一些额外的表来存储有关当前版本和应用迁移的内部信息。不要想，这才是你真正想要的东西。
对于我来说，我认为如果你只需要做一次这个任务并且可以在没有 Flyway 的情况下完成，那么就这样做吧。
【讨论】：
我认为，当我们决定是否为我们的数据迁移编写 Flyway 脚本时，我们应该问自己的一个问题是“从头开始创建这个数据库时是否有必要这样做？”
Flyway 使用版本控制系统，因此在您的情况下，在建立新环境时将值从旧版本翻转到新版本是否有意义？多次修改呢？如果您正在创建新环境，存储旧值并按顺序应用它们是否有意义？
如果您回答“否”，那么 flyway 可能不是要走的路。 Flyway 更适用于 schema 更改，其中更改了数据库结构并将数据转换为新结构。如果您只是更改配置值，我相信 flyway 可能不是您最好的选择，因为没有必要存储对这些配置值的所有更改。
【讨论】：