我所见过的最佳实践是创建一个构建脚本，在登台服务器上废弃并重新构建数据库。每次迭代都有一个用于数据库更改的文件夹，所有更改都用“Drop…创建“”。这样，您可以通过将构建指向您想要版本的文件夹，随时回滚到较早的版本。

我相信这是用NaNt/CruiseControl完成的。

是的。代码就是代码。我的经验法则是，我需要能够从头构建和部署应用程序，而不需要查看开发或生产机器。

我们正在将所有数据库转移到源代码控制的过程中。我们使用sqlcompare脚本输出数据库(不幸的是，这是一个专业版的特性)，并将结果放到SVN中。

实施的成功将在很大程度上取决于组织的文化和实践。这里的人相信为每个应用程序创建一个数据库。大多数应用程序都使用一组通用的数据库，这也导致了大量的数据库间依赖关系(其中一些是循环的)。由于我们的系统具有数据库间的依赖关系，将数据库模式放到源代码控制中是非常困难的。

祝你好运，你越早尝试，你的问题就会越早解决。

我们对所有dabase创建的对象进行源代码控制。为了让开发人员保持诚实(因为你可以在没有源代码控制的情况下创建对象)，我们的dba定期寻找不在源代码控制中的任何东西，如果他们找到了什么，他们就会丢弃它，而不询问它是否ok。

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

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

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

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