我们坚持使用变更脚本和主数据定义脚本。这些代码与任何其他源代码一起签入CVS。PL/SQL(我们是Oracle商店)在CVS中也是源代码控制的。变更脚本是可重复的，并且可以传递给团队中的每个人。基本上，仅仅因为它是一个数据库，就没有理由不对它进行编码并使用源代码控制系统来跟踪更改。

我们坚持使用变更脚本和主数据定义脚本。这些代码与任何其他源代码一起签入CVS。PL/SQL(我们是Oracle商店)在CVS中也是源代码控制的。变更脚本是可重复的，并且可以传递给团队中的每个人。基本上，仅仅因为它是一个数据库，就没有理由不对它进行编码并使用源代码控制系统来跟踪更改。

我使用ActiveRecord Migrations。这个Ruby gem可以在Rails项目之外使用，并且有适配器可以处理您遇到的大多数数据库。我的建议:如果你能够在Postgres上运行你的项目，你就会得到事务性的模式迁移。这意味着如果迁移只应用了一半，您不会最终得到一个损坏的数据库。

这对我来说也一直是一个很大的烦恼——似乎对开发数据库进行快速更改，保存它(忘记保存更改脚本)太容易了，然后你就卡在那里了。您可以撤消刚才所做的并重新做它以创建更改脚本，当然，如果您愿意的话，也可以从头开始编写它，尽管这将花费大量的时间来编写脚本。

A tool that I have used in the past that has helped with this some is SQL Delta. It will show you the differences between two databases (SQL server/Oracle I believe) and generate all the change scripts necessary to migrate A->B. Another nice thing it does is show all the differences between database content between the production (or test) DB and your development DB. Since more and more apps store configuration and state that is crucial to their execution in database tables, it can be a real pain to have change scripts that remove, add, and alter the proper rows. SQL Delta shows the rows in the database just like they would look in a Diff tool - changed, added, deleted.

一个很好的工具。以下是链接: http://www.sqldelta.com/

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

我总是检查我的数据库结构转储到源代码控制。全数据库转储，但我通常只是压缩和存储。