RedGate软件提供了一些很棒的工具，可以帮助你对数据库进行版本化。确保让开发者为开发工作构建自己的独立本地数据库，而不是依赖于“开发服务器”，因为“开发服务器”有时可能停机，有时也可能不停机。

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

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

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

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团队做的更好的事情之一。到目前为止，我真的很感动。

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

我已经在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。它鼓励使用迁移脚本。在每个版本中，我们将更改脚本合并到一个文件中，以简化理解，并允许dba“支持”更改。

我使用SchemaBank来版本控制我所有的数据库模式更改:

从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。

我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。

顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。

一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。

任何数据库接口代码都应该进入版本控制(存储过程、函数等)。

对于结构和数据，这是一个判断。我个人对我的数据库保持一个干净的结构模板，但由于它们的大小，不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的，即使对于只有历史记录也是如此。