logo标签列表

如何管理和捕获多个开发人员对数据库的更改？

.netsql-serverdatabasedatabase-designversion-control
13
我们有三位开发人员和一名测试人员，他们都在同一个数据库上工作。我们经常更改数据库的模式，每次更改都会给其他人带来不少麻烦。
对于针对 MS SQL Server 2008 的 .NET 导向开发，是否有良好的做法来管理这个问题？我想到了类似于 Rails 迁移的方法，让每个开发人员和测试人员都拥有自己的本地数据库。或者这是过度设计了吗？至少拥有独立的测试和开发数据库会很好，但目前手动保持两个数据库同步可能比我们目前的困境更糟糕。 LiquiBase 看起来很有前途，有没有人在类似的环境中成功使用它？还是有更好的方法？
如果需要的话，我们使用 SQL Server 2008、VS 2008 和 .NET 3.5。
7个回答
4
我们有脚本可以从零开始生成数据库，这就是存放在源代码控制中的内容。每个开发人员（共20人）都使用脚本在他们的工作站上生成2个数据库。一个用于“工作”——手动测试，其中包含样本数据（有脚本可用于填充样本数据）。另一个数据库为空，在单元测试中使用（开启事务——进行单元测试——回滚）。
在多开发人员环境中，单元测试是强制性的。此外，我们总是构建“旧”数据库并对其应用模式更改。每个开发人员都通过创建升级程序来更改模式（这是我们同时具备重建和升级准备的方式）。
为了进行性能测试，我们有“加载器”——C#代码来模拟用户，并在开发人员的工作站上一夜之间填充数百万条记录。
3
我们没有使用特定的工具，但是我们将所有的架构都放在源代码控制下，并编写了一个脚本来从源代码更新或重建数据库。这样当有更改时，我们可以更新并保持同步。这已经成为日常早晨例行事项的一部分，就像同步你的代码一样，只需要大约5分钟时间。虽然不完美，但对我们来说起作用。
哦，我忘了补充一点，如果您对架构进行更改，则必须负责编写迁移脚本（如果需要）。通常在进入生产环境时都需要这样做。
希望这能帮到您。
这是我一直见过的做法，而且通常效果很好。 - Justin Ethier
1

值得一提的是，Visual Studio Team System Database Edition（又称“Data Dude”）非常值得关注。它可以跟踪数据库差异，并生成更改脚本，以便在部署之前准备测试/生产环境等。我认为它的功能也可以在开发版中使用（请参见上面的链接），并且在VS 2010中将更加可见。请查看这篇博客文章：First Experience with Visual Studio 2008 Database Edition, I love it!!!

除此之外，还有TFS，使您能够对SQL文件进行版本控制，并针对数据库运行它们。

1
1
我属于“一个开发数据库”的阵营。
与传统的OO源代码不同，数据库通常会有支持多个用户特性的表。当多个开发人员要进行类似更改时，你可以让他们提前解决问题或尝试同步两个构建脚本。构建脚本和迁移的问题在于大多数情况都非常棘手。想要在数据库中禁止NULL吗？你需要决定数据应该默认为什么以及是否应该从其他地方填充数据。需要重构将一个表规范化成两个吗？你需要决定如何分配键。然后两个用户对同一张表进行更改…
这并不是说它不应该在源代码控制下，因为它应该。
最终，随着越来越多的开发人员和通信渠道，你会想要你的数据库更改通过一个开发DBA进行 - 这允许更改协调，并避免了团队中通信渠道的许多问题 - 将通信渠道变成了一个星形。此外，如果你限制自己针对显式数据库服务层编程，比如视图和存储过程，那么你的应用程序开发人员将会很好地隔离数据库更改和重构。

在开发一段时间后，数据库的更改变得相当可控，因为基础表结构的更改较少（虽然视图和存储过程可能仍然不稳定）。

0
0

我个人认为最好使用独立的数据库。所有人都在一个数据库上操作可能会导致很多问题和浪费时间。

例如，假设我正在研究性能问题，并且正在运行一些基准测试来测试数据库的一些优化 - 唯一可靠的方法是保持测试的一致性。如果其他人在中途更改了数据库，那么这可能会扭曲您的结果。

此外，如果我正在进行某项工作，而数据库在我不知情的情况下发生了变化，导致出现错误/意外行为，我可能需要花费大量时间才能找到原因。

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

1
不同意。开发人员应该针对一个数据库进行工作，该数据库的记录数量与生产环境大致相同。我们的数据库太大了，每个开发者都在自己的电脑上拥有自己的版本是不可行的。您的情况可能有所不同，但我认为这是一种不良做法。 - HLGEM
@HLGEM - 是的，您需要有一个本地数据库可用，其中包含生产规模的数据量。在我的环境中，切换到具有不同数据量的多个数据库之一是不需要任何费用的，最高可达数百GB。当然，针对如此大的数据库运行行为测试可能会有些痛苦，并且只会不必要地延长测试持续时间。此外，如果所有开发人员同时针对同一数据库运行测试，则会发生冲突并导致测试失败。我认为，对于测试人员来说，针对开发数据库运行测试是非常糟糕的做法。 - AdaTheDev
1
@AdaTheDev：这假设开发人员拥有PROD规模的硬件，但对于更大的网站/应用程序来说并非如此。我们的主数据库有8GB的RAM和8个核心，这只是一个中等大小的PROD DB。我发现使用比例相当的数据大小的集成DB效果很好。检入的代码通过CI构建。针对集成DB的自动化测试监控性能下降。 - Eric J.
1
@Eric J：你的回答和AdaTheDevs原始回答有什么不同，还是你只是在确认他的回答？ - AutomatedTester
@AdaTheDevm 开发人员需要像测试人员一样对他们的查询运行测试。有许多编写性能不佳的 SQL 的方法，直到在生产数据量上运行它才会被注意到。开发人员应该运行这个测试，如果等到测试人员才发现这个问题，那就太晚了。如果多个开发人员运行测试时出现冲突和测试失败，那么当代码进入生产并拥有大量用户时，就会出现冲突和失败。数据库需要为并发使用而设计。 - HLGEM
显示剩余7条评论
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接