I've heard people say you absolutely have to keep your schemas in the database. I'm not sure I agree. This really depends on the system you're working with. If your system is relatively small and the data is not terribly important. And the the speed at which you need to bring another development environment online is crucial.. then yes.. you can benefit from it. However when your schema is useless without the data and the database is extremely large, it becomes virtually impossible to "source control" your database. Sure, you can still keep your DDL code in source control but that's essentially useless. You can't get the data needed without backup/restore.

在大型数据库开发工作中，我发现备份和恢复是首选的回滚选项。当然，你可以在源代码控制中保留过程、视图、函数等，但要保留表。SQL不是必需的。此外，如果您的部署过程是无懈可击的，那么您很可能永远不需要“回滚”您的生产环境。

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

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

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

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

Your project team can have a DBA to whom every developer would forward their create alter, delete, insert/update (for master data) sql statements. DBAs would run those queries and on successfully making the required update would add those statements to a text file or a spreadsheet. Each addition can be labeled as a savepoint. Incase you revert back to a particular savepoint, just do a drop all and run the queries uptil the labelled savepoint. This approach is just a thought... a bit of fine tuning here would work for your development environment.

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

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脚本也与subversion。这是一个很好的实践，您可以在需要时使用默认数据重新创建模式。

是的，我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制，所以我们可以恢复到任何带标签的版本。

我们还有ant任务，可以在需要时重新创建db。

此外，SQL还被标记为与之配套的源代码。