目前，我们公司通过手动创建，分发和运行必要的SQL脚本来处理所有数据库架构更改。显然，这会导致问题，因为各种机器偶尔和稀疏地更新。
我正在研究更现代的方法来处理这个问题，Flyway现在是主要的候选者（尽管我们仍然愿意使用Liquibase，如果可以为它做出令人信服的论证）。
正常流程很简单，工作方式与广告一样简单，但我们不知道如何正确处理冲突的迁移脚本。例如，不同个人分支（A和B）上的2个开发人员将相同的列添加到不同迁移（MigrationA和MigrationB）中的表中。分支B上的dev意识到MigrationB在他已经在他的数据库上运行之后不是必需的。不幸的是，此时损坏已经完成，并且已经将条目写入数据库B中的schema_version表。由于Flyway不支持回滚，在这种情况下适当的响应是什么？
从历史上看，我们尽可能避免丢弃/重建我们的数据库，但是一旦你使用Flyway，这种心态是否已经过时了？我们是否应该彻底创建DeveloperData脚本以便我们可以在出现这些问题时随时删除我们的数据库？在我开始告诉同事我们需要开始丢弃我们的数据库之前，我想确保我以正确的方式接近这个。
感谢您提供任何特定于输入的答案或更多关于人们如何成功切换到Flyway的一般解释/示例。
答案 0 :(得分：0)
你是对的。
DEV数据库可以而且应该被视为一次性的，而Flyway完全支持它。它允许您通过眨眼确定性地重新创建它们。这对于您在上面描述的场景以及许多其他场景（例如设置新的测试环境和加入新开发人员）都非常重要。