我们有一个数据库，其中存储了来自外部系统的标识符。现在标识符已更改（系统更改了方案），并且数据库需要更新。它可以完成 - 我有一个映射，所以我可以生成足够的SQL来使它工作，最后这将需要这样做。Flyway Java迁移是这个用例的合适工具吗？
问题是 - 这是用于Flyway Java迁移的用例吗？我倾向于认为情况并非如此，但我无法真正说出原因，这是一种直觉。但是，外部系统的模式没有版本化，至少不是我们的，所以我觉得它根本不适合Flyway迁移;我认为它应该在Flyway之外执行一次。
任何有更多经验的人都可以帮忙，解释为什么或为什么不？
它主要是基于意见的，但在我看来，因为它与使用蒸汽锤来破解坚果一样。对于定期迁移而言，Flyway是一个非常有用的工具，对于这种情况，还有很多数据库，您必须定期重新创建或更新，而不是一次性使用。
在您的项目中包含一些相对较大的框架，花费一些时间使其工作并仅使用一次的原因是什么？此外，Flyway需要在数据库中存在一些额外的表格，以存储关于当前版本和应用迁移的内部信息。不要以为，那是你真正想要的。
就我而言，我认为，如果你做这个任务了一次，并且可以不用迁飞，然后就去做这样。
我想一个问题，我们应该问自己，当我们确定是否写一个剧本迁飞为我们的数据迁移是“从头开始创建该数据库时这个必要吗？”
迁飞使用版本控制系统，使你的情况，这将是有意义的从旧版本翻转值到新版本站在了一个新的环境时？怎么样多重修改？如果您正在创建新的环境，是否有意义地存储旧值并将它们顺序应用？
如果您回答“否”，那么flyway可能不是您要走的路。 Flyway更好地用于架构更改，其中数据库的结构发生更改并且数据转换为新结构。如果您只是更改配置值，我认为flyway可能不是您最好的选择，因为没有必要存储对这些配置值的所有更改。
我们已经在使用Flyway，并有少量的迁移，所以这不是我们是否应该使用它的问题。问题是这个用例是否是Flyway应该使用的东西。在此迁移中，不会更改架构，只是在外部系统中的架构发生更改后要更改的数据。 – wujek
我现在看到并假设你也必须在你的问题中指定这个。但是，无论如何，我仍然认为如果这是一次迁移，而迁移必须应用于唯一的一个数据库实例并且只有一次迁移，那么它不是Flyway的用例。此外，它不影响模式。 – Stanislav