我们目前有混合数据和模式迁移，这些迁移是在应用程序启动之前由应用程序的 ORM 运行的。在我们的例子中，数据迁移是我们操作数据时的一种迁移，例如在不同列之间移动数据、修复数据格式问题、修复一些错误的数据或在极少数情况下在不同服务数据库之间移动数据。它们通常很简单（一些创建/更新语句），但在某些情况下，我们利用编程语言和一些逻辑来计算最终状态。 我正在寻找的是使数据库模式声明式，并在有人更改存储库中的数据库模式文件时应用模式迁移。这可以通过使用一些工具来实现，例如 atlasgo.io，您可以在其中定义并生成模式文件通过计算状态文件和实际数据库之间的差异来进行版本化模式迁移。
因此，如果我应用这种方法，我们的架构和数据迁移就会变得分开。我计划首先使用架构迁移工具运行架构迁移，然后才使用相同的 ORM 方法运行数据迁移。但看起来这会给我们带来一些麻烦。想象一下，如果我们一段时间没有在某些环境上交付代码，并且有一些数据和模式迁移可供运行。因为我首先运行架构迁移 - 数据迁移很有可能失败，因为他们可能期望某些架构可能已经更改。所以模式和数据迁移的顺序非常重要。
你对如何在你的项目中运行这些东西有什么建议吗？
数据迁移应针对开发数据迁移时的最新架构修订进行设计。
当然，不能保证数据迁移适用于任何较旧或较新的架构修订版。你对此无能为力。在事后转换任何任意数据迁移以适应模式的任何后续修订几乎是不可能的（在某些情况下可能是可能的，但一般情况下不可能）。
因此得出这样的结论：数据迁移和模式迁移必须按时间顺序应用。也就是说，一个迁移队列，包括数据和模式。这样，数据迁移就可以应用于模式的正确修订。
以后的架构迁移也可能会影响数据（例如
ALTER TABLE...DROP COLUMN您的数据库通常有一个小表来存储当前修订版本。我见过这张桌子叫做
schema_versionschema_version我也见过很多开发人员应用了一些迁移但忘记更新的情况
schema_version对此没有自动解决方案，它涉及阅读迁移代码，然后检查数据和架构的当前状态以查看已应用的内容，然后人工开发自定义步骤来修复错误。