我们使用DBGhost来管理SQL数据库。然后，您将脚本放在版本控制中构建一个新数据库，它将构建一个新数据库，或者将任何现有数据库升级到版本控制中的模式。这样，您就不必担心创建更改脚本(尽管您仍然可以这样做，例如，如果您想更改列的数据类型并需要转换数据)。

我建议使用比较工具为您的数据库临时设计一个版本控制系统。两个好的替代方案是xSQL模式比较和xSQL数据比较。

现在，如果您的目标是只对数据库的模式进行版本控制，那么您可以简单地使用xSQL schema Compare来生成模式的xSQL快照，并在版本控制中添加这些文件。然后，要恢复或更新到特定版本，只需将数据库的当前版本与目标版本的快照进行比较。

Also, if you want to have the data under version control as well, you can use xSQL Data Compare to generate change scripts for you database and add the .sql files in your version control. You could then execute these scripts to revert / update to any version you want. Keep in mind that for the 'revert' functionality you need to generate change scripts that, when executed, will make Version 3 the same as Version 2 and for the 'update' functionality, you need to generate change scripts that do the opposite.

最后，通过一些基本的批处理编程技能，您可以使用命令行版本的xSQL Schema Compare和xSQL Data Compare来自动化整个过程

免责声明:我隶属于xSQL。

我们刚刚开始使用Team Foundation Server。如果你的数据库是中等大小的，那么visual studio有一些很好的项目集成，内置比较、数据比较、数据库重构工具、数据库测试框架，甚至数据生成工具。

但是，该模型并不适合非常大的或第三方数据库(加密对象)。我们所做的就是只存储我们定制的对象。Visual Studio / Team基础服务器在这方面工作得很好。

TFS数据库主拱。博客

MS TFS网站

我们不存储数据库模式，而是存储对数据库的更改。我们所做的是存储模式更改，以便为数据库的任何版本构建更改脚本，并将其应用于客户的数据库。我写了一个数据库实用程序，它与我们的主应用程序一起分发，它可以读取脚本，并知道需要应用哪些更新。它还具有足够的智能，可以根据需要刷新视图和存储过程。

Red Gate的SQL Compare产品不仅允许您进行对象级比较，并从中生成更改脚本，还允许您将数据库对象导出到按对象类型组织的文件夹层次结构中，其中一个[objectname]。这些目录中每个对象的SQL创建脚本。对象类型层次结构是这样的:

\功能 \安全 \安全\角色 \ \安全模式 \安全\用户 \存储过程 \表

如果在进行更改后将脚本转储到相同的根目录，则可以使用此目录更新SVN repo，并单独保存每个对象的运行历史记录。

使用更改脚本将数据库脚本保存到版本控制中是一种好方法，这样您就可以升级您拥有的任何一个数据库。此外，您可能希望保存不同版本的模式，这样就可以创建完整的数据库，而不必应用所有的更改脚本。处理脚本应该是自动化的，这样您就不必做手工工作了。

我认为为每个开发者提供一个独立的数据库，而不是使用一个共享的数据库是很重要的。这样，开发人员就可以独立于其他开发人员创建测试用例和开发阶段。

自动化工具应该具有处理数据库元数据的方法，这些元数据可以告诉您哪些数据库处于何种开发状态，哪些表包含版本可控数据等等。