Martin Fowler
写了我最喜欢的关于这个主题的文章，http
://martinfowler.com/articles/evodb.html 。 我选择不按照alumb
和其他人的建议将模式转储置于版本控制之下，因为我想要一种简单的方法来升级我的生产数据库。

对于一个只有一个生产数据库实例的 Web 应用程序，我使用了两种技术：

数据库升级脚本

包含将模式从版本 N 移动到 N+1 所需的 DDL 的序列数据库升级脚本。（这些进入您的版本控制系统。） version_history 表，类似于

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

每次运行与新版本相对应的升级脚本时都会获取一个新条目。

这样可以确保很容易查看存在的数据库模式版本，并且数据库升级脚本只运行一次。同样，这些 不是
数据库转储。相反，每个脚本代表从一个版本移动到下一个版本所需的 更改。 它们是您应用于生产数据库以“升级”它的脚本。

开发人员沙箱同步

1. 用于备份、清理和收缩生产数据库的脚本。每次升级到生产数据库后运行它。
2. 用于在开发人员的工作站上恢复（并在必要时调整）备份的脚本。每个开发人员在每次升级到生产数据库后都会运行此脚本。

一个警告：我的自动化测试是针对一个模式正确但空的数据库运行的，所以这个建议不能完全满足你的需要。