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

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

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

我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。

然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。

Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。

我们有一个shell脚本工作台，它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。

这些脚本在需要时与应用程序代码合并到发布分支中。

我们有一个记录脚本及其状态的表。 在部署工具的每次安装中，每个脚本都按顺序执行，并记录在此表中。

虽然这个问题有很多很好的答案，但大多数答案都不包括市场上的创新变化，特别是商业工具。

下面是一个简短的数据库版本控制工具列表，我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)

红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此，版本控制存储库是否与应用程序使用的数据库同步是没有问题的。

我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论

查看使用源代码控制管理数据库更改的LiquiBase。

在我们的业务中，我们使用数据库更改脚本。运行脚本时，它的名称存储在数据库中，并且不会再次运行，除非删除该行。脚本是基于日期、时间和代码分支命名的，因此可以控制执行。

在脚本在实际环境中运行之前，已经完成了大量的测试，所以一般来说，“oopsies”只发生在开发数据库上。