.net 如何跨多个开发人员管理和捕获数据库更改？

我们有三个开发人员和一个测试人员，他们都在同一个数据库上工作。我们经常更改数据库的模式，每次更改都会给其他人带来连锁反应

是否有针对MS SQL Server 2008的面向.NET的开发的良好实践来管理此问题？我正在考虑类似于Rails迁移的事情，每个开发人员和测试人员都有自己的本地数据库。还是说这太过分了？至少最好有单独的测试和开发数据库，但目前手动保持两个数据库同步可能比我们目前的困境更糟糕

看起来很有希望，有人在类似的环境中成功地使用过它吗？还是有更好的方法

---

我们使用的是SQL Server 2008、VS 2008和.NET 3.5，如果这很重要的话。

我们本身不使用工具，但我们会将所有架构置于源代码控制之下，然后使用脚本从源代码更新或重建数据库。这样，当进行更改时，我们都可以更新并保持同步。这只是每天早上例行程序的一部分，需要大约5分钟，就像同步代码一样。这并不完美，但对我们来说很有用

哦，我忘了添加，如果您对模式进行更改，您还需要负责编写迁移脚本（如果需要）。无论如何，当某些东西投入生产时，这往往是需要的

---

希望有帮助。

我们有脚本从头开始生成DB，这就是源代码管理中的内容。 每个开发人员（其中20人）正在使用脚本在其工作站上生成2个数据库。一个用于“工作”-手动测试，其中包含样本数据（有脚本填充样本数据）。另一个DB为空，用于单元测试（开放事务–执行单元测试–回滚）

在多开发者环境中，单元测试是必需的。 此外，我们总是构建“旧”数据库并对其应用模式更改。每个开发人员都在通过创建升级过程来更改模式（这就是我们同时准备好重建和升级的方式）

---

对于性能测试，我们有“加载器”——C代码来模拟用户并在开发人员工作站上夜间填充数百万条记录。

听起来您需要一个数据库差异工具来创建和存储数据库更改

Visual Studio团队系统（又称“数据都德”）值得研究。它可以跟踪数据库差异并生成更改脚本，这样您就可以在部署之前准备测试/生产环境等。我认为它的功能也可以在开发版中使用（请参见上一链接），在VS2010中会更加明显。请看这篇博文：

---

这与TFS一起，使您能够对SQL文件进行版本控制，并针对数据库运行它们。

我个人认为最好使用单独的数据库。所有针对一个数据库的操作都可能会造成很多痛苦和浪费时间

例如，假设我正在研究一个性能问题，我正在运行一些基准测试来测试数据库中的一些优化—唯一可靠的方法是，如果您与测试保持一致。如果其他人中途对数据库进行了更改，则可能会扭曲您的发现

另外，如果我处于某个事物的中间，而DB发生变化时，我不知道会给我造成错误/意外的行为，我可以花大量的时间去研究它，因为它是由别人做出的改变造成的。

---

相反，我认为最好有自己的开发/测试数据库，每个数据库都可以负责更新。然后有一个持续集成服务器，自动从源代码管理中提取最新的代码，并每x小时构建一次。

一些好链接的好链接：

我在“一个开发数据库”阵营

与传统的OO源代码不同，数据库通常会有支持多个用户特性的表。当多个开发人员要进行类似的更改时，您可以让他们提前解决，或者尝试同步两个构建脚本。构建脚本和迁移的问题在于，大多数情况都很重要。要在数据库中取消允许空值吗？-您需要决定数据应该默认为什么，以及是否应该从其他地方填充数据。需要重构才能将一个表规范化为两个您需要决定如何分配密钥。然后两个用户对同一个表进行更改

这并不是说它不应该受源代码控制，因为它应该

最终，当您有更多的开发人员和更多的沟通渠道时，您将希望您的数据库更改通过开发DBA进行—这允许协调更改并避免团队中沟通渠道的许多问题—它将沟通渠道变成一个星形

此外，如果您将自己的编程限制在显式数据库服务层（如视图和存储过程）上，那么您的应用程序开发人员将很好地抵御数据库更改和重构

---

在开发一段时间后，数据库更改变得非常容易管理，因为对基础基表模式的更改更少（尽管视图和存储过程可能仍然不稳定）。

我一直认为这是我所看到的，而且它往往工作得很好。不同意。开发人员应该在一个数据库上工作，该数据库的记录数与prod大致相同。对于每个开发人员来说，我们的dbs太大，无法在他们的pc上拥有自己的版本。您的里程数可能不同，但我认为这是一个糟糕的做法。@HLGEM-是的，您确实需要一个具有生产规模数据卷的本地数据库。在我的环境中，只需在多个数据库中的一个数据库之间切换，就不需要花费任何成本，这些数据库的数据量最多可达100GB。属于