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

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

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

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

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

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

I agree with many of the posting concerning ruby's ActiveRecord migrations - they are an elegant way to manage the database in small incremental files that everyone can share. With that said, I've recently implemented a project using VisualStudio's Database Project, and it's kinda made me a believer. Short story - you create a database project, import all (if any) existing database objects into it (tables/views/triggers/keys/users/etc). That import results in a "Create" script per object. To manage the database you alter the create script and then on deploy VS compares the target database to the state of the database residing in your project and apply the proper alter statements.

这真的有点神奇，我必须承认，这是VS团队做的更好的事情之一。到目前为止，我真的很感动。

当然，您可以在自己选择的版本控制系统中管理整个数据库项目。

数据库本身?没有

创建它们的脚本，包括静态数据插入、存储过程等;当然可以。它们是文本文件，它们包含在项目中，像其他东西一样签入和签出。

当然，在理想情况下，您的数据库管理工具可以做到这一点;但你必须遵守纪律。

我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的，但这是一项非常繁重的任务。

你会想要限制修改的数量，因为它真的会在一段时间后消耗磁盘空间!

仅供参考，几天前Dana也提出了这个问题…源代码控制中的存储过程/DB模式