我们有三个开发人员和一个测试人员都在针对同一个数据库工作。我们经常更改数据库的模式，每次我们这样做都会对其他人产生令人头疼的涟漪效应。
针对面向.NET的开发是否有针对MS SQL Server 2008进行管理的良好实践？我正在考虑类似于Rails迁移的东西，每个开发人员和测试人员都有自己的本地数据库。或者那有点矫枉过正？拥有单独的测试和开发数据库至少会很好，但目前手动保持两个数据库同步可能比我们目前的困境更糟糕。
LiquiBase似乎很有希望，有没有人在类似的环境中成功使用它？或者有更好的方法吗？
如果重要的话，我们正在使用SQL Server 2008，VS 2008和.NET 3.5。
答案 0 :(得分：4)
我们有从头开始生成DB的脚本，这就是源代码控制中的内容。 每个开发人员（其中20人）使用脚本在他们的工作站上生成2个数据库。一个用于“工作” - 手动测试中包含样本数据（有用于填充样本数据的脚本）。另一个DB为空并用于单元测试（打开事务 - 执行单元测试 - 回滚）。
单个测试在多开发人员环境中是必需的。 此外，我们始终构建“旧”数据库并对其应用架构更改。每个开发人员都通过创建升级过程来更改模式（这是我们同时重建和升级的方法）。
对于性能测试，我们有“加载器” - 用于模拟用户的C＃代码，并在开发人员工作站上填充数百万条记录。
答案 1 :(得分：3)
我们本身不使用工具，但我们确实将所有模式保留在源代码控制之下，然后使用一个脚本来更新或重建源数据库。这样，当进行更改时，我们都可以更新并保持同步。这只是每日早晨例行程序的一部分，大约需要5分钟，就像同步代码一样。这并不完美，但它对我们有用。
哦，如果您对架构进行更改，我忘了添加，如果需要，您还负责编写迁移脚本。当某些东西投入生产时，这往往是需要的。
希望有所帮助。
答案 2 :(得分：1)
Visual Studio Team System Database Edition（又名“Data Dude”）值得研究。它可以跟踪数据库差异并生成更改的脚本，以便您可以在部署之前准备测试/产品环境等。我认为其功能也可以在开发版中看到（请参阅上一个链接），并且在VS 2010中将更加明显。看一下这篇博文：First Experience with Visual Studio 2008 Database Edition, I love it!!!
与TFS一起，您可以对SQL文件进行版本控制并针对数据库运行它们。
答案 3 :(得分：1)
答案 4 :(得分：1)
我在“一个开发数据库”阵营。
与传统的OO源代码不同，数据库通常会有支持多个用户功能的表。当多个开发人员要进行类似的更改时，您可以让他们提前解决或尝试同步两个构建脚本。构建脚本和迁移的问题在于大多数情况都是非平凡的。想要禁止DB中的NULL吗？ - 您需要确定应该默认哪些数据以及是否应该从其他地方填充数据。需要重构将表规范化为两个？ - 您需要决定如何分配密钥。然后让两个用户对同一个表进行更改......
这并不是说它不应该受源代码控制，因为它应该。
最终，由于您拥有更多的开发人员和更多的沟通渠道，您将希望通过开发DBA进行数据库更改 - 这样可以协调更改并避免团队中通信渠道的许多问题 - 它将通信渠道变成一颗星。
此外，如果您限制自己根据视图和存储过程等显式数据库服务层进行编程，那么您的应用程序开发人员将完全避免数据库更改和重构。
在开发一段时间后，数据库更改变得非常易于管理，因为对底层基表模式的更改较少（尽管视图和存储过程可能仍然不稳定）。
答案 5 :(得分：0)
答案 6 :(得分：0)
我个人认为最好有单独的数据库。所有针对一个数据库的工作都会造成很多痛苦和浪费时间。
例如，假设我正在研究性能问题，并且我正在运行一些基准测试来测试数据库上的一些优化 - 唯一可靠的方法是，如果您与测试一致。如果其他人在中途对DB进行了更改，那可能会影响您的发现。
另外，如果我处于中间状态并且数据库发生变化而我不知道会给我造成错误/意外行为，我可能会花费大量时间才能找到它，因为其他人已经发生了变化制成。
相反，我认为拥有自己的开发/测试数据库会更好，每个数据库都可以负责更新。然后有一个Continuous Integration服务器，它自动从源代码控制中提取最新的代码，并每x小时构建一次。