如果你的数据库是SQL Server，我们可能有你正在寻找的解决方案。SQL源代码控制1.0现在已经发布了。

http://www.red-gate.com/products/SQL_Source_Control/index.htm

它集成到SSMS中，并提供数据库对象和VCS之间的粘合剂。“脚本输出”是透明的(它在底层使用SQL比较引擎)，这应该使它使用起来如此简单，以至于开发人员不会被阻止采用该过程。

一个可供选择的Visual Studio解决方案是ReadyRoll，它被实现为SSDT数据库项目的子类型。这采用了一种迁移驱动的方法，更适合DevOps团队的自动化需求。

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

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

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

要求开发团队使用SQL数据库源代码控制管理系统并不是防止问题发生的灵丹妙药。就其本身而言，数据库源代码控制引入了额外的开销，因为开发人员需要将他们对对象所做的更改保存在单独的SQL脚本中，打开源代码控制系统客户端，使用客户端签入SQL脚本文件，然后将更改应用到活动数据库。

我可以建议使用SSMS插件ApexSQL源代码控制。它允许开发人员通过向导直接从SSMS轻松地将数据库对象映射到源代码控制系统。该插件支持TFS、Git、Subversion和其他SC系统。它还包括对源控制静态数据的支持。

下载并安装ApexSQL源代码控制后，只需右键单击要进行版本控制的数据库，然后导航到SSMS中的ApexSQL源代码控制子菜单。单击Link database to source control选项，选择源代码控制系统和开发模型。之后，您需要为所选择的源代码控制系统提供登录信息和存储库字符串。

你可以阅读这篇文章了解更多信息:http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

我们使用复制和集群来管理数据库以及备份。我们使用Serena来管理SQL脚本和配置实现。在进行配置更改之前，我们将执行备份，作为更改管理流程的一部分。此备份满足我们的回滚需求。

我认为这完全取决于规模。您是在谈论需要离线备份和灾难恢复的企业应用程序吗?一个运行会计应用程序的小工作组?还是两者之间的任何地方?

A big problem, often overlooked, is that for larger web based systems, it is required to have a transitional period or bucket testing approach to making new releases. This makes it essential to have both rollback and a mechanism for supporting both the old and new schema in the same DB. This requires a scaffolding approach (made populist by the Agile DB folks). In this scenario, lack of process in DB source control can be a total disaster. You need old schema scripts, new schema scripts and a set of intermediate scripts, as well as a tidy up, once the system is fully on the new version (or rolled back).

需要的不是从头开始重新创建模式的脚本，而是一种基于状态的方法，在这种方法中，您只需要脚本将DB从一个版本移动到另一个版本，向前或向后移动到所需的状态。您的DB变成了一系列状态脚本，可以轻松地对其进行源代码控制，并与源代码的其余部分一起标记。