在源代码管理中管理我的数据库

由于我正在处理一个新的数据库项目（在 VS2008 中），而且我从未从头开始开发数据库，​​因此我立即开始研究如何在源代码管理（在本例中为 Subversion）中管理数据库。

我找到了一些关于SO的信息，包括这篇文章：保持多个环境中的开发数据库同步 https://stackoverflow.com/questions/40957/keeping-development-databases-in-multiple-environments-in-sync. 特别是其中一个答案 https://stackoverflow.com/questions/40957/keeping-development-databases-in-multiple-environments-in-sync/41217#41217指向了一些链接，所有这些链接都有很好的、有用的信息。

我正在读一本系列帖子 http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx作者：K. Scott Allen，描述了他如何管理数据库更改。从我的阅读来看（请原谅我的问题的愚蠢），似乎数据库本身从未被签入存储库。相反，可以构建数据库的脚本以及测试数据（也由脚本填充）被签入存储库。最终，这意味着，当开发人员测试他或她的应用程序时，将运行这些作为构建过程一部分的脚本。这确保了数据库是最新的，但也可以在每个开发人员的计算机上本地运行。

这对我来说很有意义（如果我确实正确地阅读了的话）。但是，如果我遗漏了什么，我将不胜感激纠正或额外指导。另外，我想问的另一个问题是——这是否也意味着我应该NOT签入mdf or ldf从 Visual Studio 创建的文件？

感谢您的任何帮助和额外的见解。一直很赞赏。

这是正确的，您应该签入脚本而不是数据库文件本身。

我不喜欢根据测试数据进行构建，除非数据本身会模仿生产中数据的大小（或者在新数据库的情况下，旨在具有的数据大小）。为什么？因为针对具有 100 条记录的表编写代码并不能告诉您当您有 10,000,000 条记录时它是否会及时运行。我有太多糟糕的设计选择，这些选择是由那些认为小数据集适合开发的人做出的。

在这里，我们不允许开发人员在其设备上拥有单独的数据库（这通常会由于不是连接到 SAN 的服务器而限制数据库的大小），相反，他们必须针对定期刷新的开发数据库进行工作prod（然后运行所有新的开发脚本）以保持数据正确的大小。我认为你的开发数据库环境与产品尽可能匹配是很重要的，包括设备配置、数据库大小等。没有什么比花费很长时间开发一些在产品上根本无法工作或必须在产品上工作的东西更令人沮丧的了。立即删除，因为它使系统速度减慢太多。

现在从我的肥皂盒上跳下来。