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

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.

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

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

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

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

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

我总是检查我的数据库结构转储到源代码控制。全数据库转储，但我通常只是压缩和存储。

哇，这么多答案。对于可靠的数据库版本控制，您需要对更改数据库的代码进行版本控制。一些CMS提供配置管理工具，比如Drupal 8中的配置管理工具。以下是一个实用步骤的概述，可以安排您的工作流并确保数据库配置是版本化的，即使是在团队环境中:

数据库本身?没有

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

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

是的。代码就是代码。我的经验法则是，我需要能够从头构建和部署应用程序，而不需要查看开发或生产机器。