仅供参考，几天前Dana也提出了这个问题…源代码控制中的存储过程/DB模式

数据库本身?没有

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

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

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

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

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

任何数据库接口代码都应该进入版本控制(存储过程、函数等)。

对于结构和数据，这是一个判断。我个人对我的数据库保持一个干净的结构模板，但由于它们的大小，不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的，即使对于只有历史记录也是如此。

我通过编写脚本输出所有对象(表定义、索引、存储过程等)来源控制数据库模式。但是，至于数据本身，只需依赖定期备份。这确保了所有的结构更改都被正确的修订历史记录捕获，但不会在每次数据更改时给数据库带来负担。

My team versions our database schema as C# classes with the rest of our code. We have a homegrown C# program (<500 lines of code) that reflects the classes and creates SQL commands to build, drop and update the database. After creating the database we run sqlmetal to generate a linq mapping, which is then compiled in another project that is used to generate test data. The whole things works really well because data access is checked at compile time. We like it because the schema is stored in a .cs file which is easy to track compare in trac/svn.