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

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

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

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

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

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

我有一切必要的重新创建我的数据库从裸露的金属，减去数据本身。我相信有很多方法可以做到这一点，但我所有的脚本等都存储在subversion中，我们可以通过将所有这些从subversion中取出并运行安装程序来重建DB结构等。

是的，当然。每当有更改时，我们生成PostgreSQL模式的转储并签入。它已经救了我们很多次，而我才上任几个月。

我通常为我所做的每一个更改构建一个SQL脚本，另一个用于恢复这些更改，并将这些脚本置于版本控制之下。

这样我们就可以根据需要创建一个新的最新数据库，并且可以轻松地在不同版本之间切换。每次我们发布版本时，我们都会把脚本放在一起(需要一些手工工作，但实际上很少困难)，所以我们也有一组可以在版本之间转换的脚本。

是的，在你说之前，这与Rails和其他东西非常相似，但它似乎工作得很好，所以我毫不犹豫地承认我无耻地提出了这个想法:)

My team versions our database schema as C# classes with the rest of our code. We have a homegrown C# program (<500 lines of code) that reflects the classes and creates SQL commands to build, drop and update the database. After creating the database we run sqlmetal to generate a linq mapping, which is then compiled in another project that is used to generate test data. The whole things works really well because data access is checked at compile time. We like it because the schema is stored in a .cs file which is easy to track compare in trac/svn.

是的，我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制，所以我们可以恢复到任何带标签的版本。

我们还有ant任务，可以在需要时重新创建db。

此外，SQL还被标记为与之配套的源代码。