我们正在将所有数据库转移到源代码控制的过程中。我们使用sqlcompare脚本输出数据库(不幸的是，这是一个专业版的特性)，并将结果放到SVN中。

实施的成功将在很大程度上取决于组织的文化和实践。这里的人相信为每个应用程序创建一个数据库。大多数应用程序都使用一组通用的数据库，这也导致了大量的数据库间依赖关系(其中一些是循环的)。由于我们的系统具有数据库间的依赖关系，将数据库模式放到源代码控制中是非常困难的。

祝你好运，你越早尝试，你的问题就会越早解决。

我们对所有dabase创建的对象进行源代码控制。为了让开发人员保持诚实(因为你可以在没有源代码控制的情况下创建对象)，我们的dba定期寻找不在源代码控制中的任何东西，如果他们找到了什么，他们就会丢弃它，而不询问它是否ok。

要求开发团队使用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/

作为一种规则，我们将所有的对象代码(存储过程、视图、触发器、函数等)都保存在源代码控制中，因为这些对象都是代码，而且几乎所有其他答案都同意，代码属于某种形式的版本控制系统。

As for CREATE, DROP, ALTER statements, etc. (DDL), we developed and use BuildMaster to manage the deployment of these scripts such that they can be run once and only once against a target database (whether they fail or not). The general idea is that developers will upload change scripts into the system and when it comes time for deployment, only the change scripts that haven't been run against the target environment's database will be run (this is managed very similarly to Autocracy's answer). The reason for this separation of script types lies in that once you manipulate a table's structure, add an index, etc., you effectively cannot undo that without writing a brand new script, or restoring the database - as opposed to the object code where you can simply drop a view or stored procedure then recreate it.

例如，当您将生产数据库恢复到集成环境中时，可以看到一些好处，系统会自动准确地知道哪些脚本没有运行，并将更改新恢复的数据库的表结构，使其与开发相关。

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

是的……我们的数据库是在ERwin中设计的，每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上，我们的工程文档也是如此)。