我们有三名开发人员和一名测试员，他们都在同一个数据库上工作。我们经常更改数据库的架构，每次我们这样做都会对其他人产生头痛的连锁反应。
是否有针对 MS SQL Server 2008 的面向 .NET 的开发的良好实践来管理此问题？我正在考虑类似于 Rails Migrations 的东西，每个开发人员和测试人员都有自己的本地数据库。还是那是矫枉过正？拥有单独的测试和开发数据库至少会很好，但目前手动保持两个数据库同步可能比我们目前的困境更糟糕。
LiquiBase 看起来很有希望，有没有人在类似的环境中成功使用过它？还是有更好的方法？
如果这很重要的话，我们正在使用 SQL Server 2008、VS 2008 和 .NET 3.5。
【问题讨论】：
标签： .net sql-server database database-design version-control
我们有脚本可以从头开始生成数据库，这就是源代码控制中的内容。 每个开发人员（其中 20 人）都使用脚本在他们的工作站上生成 2 个数据库。一种用于“工作”——使用其中的样本数据进行手动测试（有填充样本数据的脚本）。另一个 DB 是空的，用于单元测试（打开事务 - 进行单元测试 - 回滚）。
在多开发人员环境中必须进行单元测试。 此外，我们总是构建“旧”数据库并对其应用架构更改。每个开发人员都在通过创建升级过程来更改架构（这就是我们同时准备好重建和升级的方式）。
对于性能测试，我们有“加载器”——C# 代码来模拟用户并在开发人员工作站上一夜之间填充数百万条记录。
【讨论】：
我们本身不使用工具，但我们确实将我们的所有架构保持在源代码控制之下，然后有一个脚本可以从源代码更新或重建数据库。这样，当进行更改时，我们都可以更新并保持同步。这只是每天早上例行程序的一部分，大约需要 5 分钟，就像同步您的代码一样。这并不完美，但对我们有用。
哦，我忘了补充，如果您对架构进行了更改，您还需要负责编写迁移脚本（如果需要）。无论如何，当某些东西投入生产时，这往往是需要的。
希望对您有所帮助。
【讨论】：
Visual Studio Team System Database Edition（又名“Data Dude”）值得研究。它可以跟踪数据库差异并生成更改脚本，因此您可以在部署之前准备测试/生产环境等。我认为它的功能在开发版（参见上一个链接）中也可用，并且在 VS 2010 中将更加明显。看看这篇博文：First Experience with Visual Studio 2008 Database Edition, I love it!!!
这与 TFS 一起使您能够对 SQL 文件进行版本控制并针对数据库运行它们。
【讨论】：
我属于“单一开发数据库”阵营。
与传统的 OO 源代码不同，数据库通常会有支持多用户功能的表。当多个开发人员要进行类似的更改时，您可以让他们提前解决或尝试同步两个构建脚本。构建脚本和迁移的问题在于大多数情况都不是微不足道的。想要在数据库中禁止 NULL 吗？ - 您需要决定数据应默认为什么以及是否应从其他地方填充数据。需要重构以将表标准化为两个？ - 您需要决定如何分配键。然后两个用户对同一个表进行更改...
这并不是说它不应该受到源代码控制，因为它应该。
最终，随着您拥有更多的开发人员和更多的沟通渠道，您将希望您的数据库更改通过开发 DBA 进行 - 这样可以协调更改并避免团队中沟通渠道的许多问题 - 它把沟通渠道变成明星。
此外，如果您将自己的编程限制在视图和存储过程等显式数据库服务层，您的应用程序开发人员将会很好地隔离数据库更改和重构。
经过一段时间的开发，数据库更改变得非常易于管理，因为对底层基表架构的更改较少（尽管视图和存储过程可能保持不稳定）。
【讨论】：
【讨论】：
我个人认为最好有单独的数据库。所有针对一个数据库的工作都可能导致很多痛苦和浪费时间。
例如，假设我正在调查一个性能问题，并且我正在运行一些基准测试来测试数据库的一些优化 - 可靠地做到这一点的唯一方法是，如果你与你的测试保持一致。如果其他人在中途对数据库进行了更改，那可能会歪曲您的发现。
另外，如果我正在处理某事并且数据库发生更改而我不知道会导致错误/意外行为，我可能会花费 x 时间来解决问题，然后才能发现这是由于其他人所做的更改制作。
相反，我认为拥有自己的开发/测试数据库要好得多，每个人都可以负责更新这些数据库。然后有一个持续集成服务器，它会自动从源代码控制中提取最新代码并每隔 x 小时构建一次。
【讨论】：