我们经常遇到这种情况：
对于我到目前为止所读到的内容，我注意到我们可以：
GUI是一种很好的方法，因为它是一种简单的方法。 但不是自动化的，我们无法恢复到之前的“版本”。
Subversion我们可以获得不同版本的数据库模式。 但理解和创建一个工作流程非常复杂，工作流程可以包含一方的架构，另一方面的数据。
SQL表方法似乎很难理解我甚至看不到那里的好坏部分。
bash自动化任务似乎是一种非常好的方法，因为如果配置得当，它可以很好地进入部署工作流程。但似乎我们无法控制旧版本的数据库。
说实话，我没有看到在任何颠覆系统下拥有数据库的重要需求，因为希望它不是我们每天都在改变的东西，就像我们应用程序中的其他文件一样。
有了这一切，我倾向于搜索一个bash进程，在部署时可以做两件事：
从生产服务器检索数据。 （因为它将存在最多的更新数据。）
使用本地模式更新远程模式。 （因为它是本地的，我们将首先更改我们的架构。）
答案 0 :(得分：0)
我最喜欢的是Ruby on Rails用于数据库迁移的一般方法。在rails中，您可以创建一个使用特定于域的语言的迁移文件。但是，这个想法是每个迁移都有一个版本号。此外，每次迁移都包括实现和回滚步骤。最后，执行迁移时，将更新标识架构版本的数据库中的本地表，以标识数据库的当前版本。这些迁移文件将被检入源代码管理中。
因此，我建议您执行以下操作：
因此，如果数据库当前是版本14，并且您使用所需的版本17调用主脚本，它将知道执行版本15,16和17的架构更改脚本。如果数据库当前是15并且所需版本为12，它将知道执行版本15,14和13的回滚脚本。
所有这些脚本都应该检查到源代码管理中。