是的……我们的数据库是在ERwin中设计的，每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上，我们的工程文档也是如此)。

必须阅读将数据库置于版本控制之下。查看K. Scott Allen的系列帖子。

When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.

我们对数据库周围的一切进行版本和源代码控制:

DDL(创建和更改) DML(参考数据、代码等) 数据模型更改(使用ERwin或ER/Studio) 数据库配置更改(权限、安全对象、常规配置更改)

我们使用Change Manager和一些自定义脚本来完成所有这些自动化作业。我们有变更管理器监视这些变更，并在变更完成时通知变更。

“简短版本:将您的生产数据库转储到git存储库中，以实现即时备份解决方案。”

是的……我们的数据库是在ERwin中设计的，每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上，我们的工程文档也是如此)。

A big problem, often overlooked, is that for larger web based systems, it is required to have a transitional period or bucket testing approach to making new releases. This makes it essential to have both rollback and a mechanism for supporting both the old and new schema in the same DB. This requires a scaffolding approach (made populist by the Agile DB folks). In this scenario, lack of process in DB source control can be a total disaster. You need old schema scripts, new schema scripts and a set of intermediate scripts, as well as a tidy up, once the system is fully on the new version (or rolled back).

需要的不是从头开始重新创建模式的脚本，而是一种基于状态的方法，在这种方法中，您只需要脚本将DB从一个版本移动到另一个版本，向前或向后移动到所需的状态。您的DB变成了一系列状态脚本，可以轻松地对其进行源代码控制，并与源代码的其余部分一起标记。