数据库和DVCS

Question

我最近问了一个关于DVCS是否适合公司环境的问题，这引发了我的另一个问题。

DVCS的优点之一似乎是，您可以轻松地进行分支和尝试新的东西。当我开始考虑数据库更改时，我的问题就开始了。我一直觉得要让DB进入VCS是一件很棘手的事情，听起来就像要用DVCS更难。

那么，使用数据库和DVCS的最佳方法是什么？

编辑：--我已经开始研究Migrator.NET了。人们如何看待这样的项目，以便在特定的版本之间移动，特别是在DVCS中的实验分支？

Answer 1

我认为处理这个问题的最好方法是使用DB模式，而不是数据库本身。在这种情况下，每个开发人员都有自己的数据库可供开发。

以下是一些可用的选项：

在Ruby Rails.

• South for Django中，除了在模型类themselves.

• Visual Studio 2008 Team System Database for .NET中定义的模式之外，您还可以定义模式，并且该工具可以对模式和数据进行区分，以生成在不同版本的数据库之间运行的脚本。

这些可能会给您一些关于如何在版本控制中处理数据库的灵感。当您处理模式时，另一个好处是您可以更容易地实现TDD和持续集成(CI)。您的TDD/CI环境将能够构建数据库的新版本，然后针对新生成的环境运行测试。

Answer 2

对用于管理数据库的所有脚本进行版本化。如果您需要对数据库进行“正在开发”更改，请在您的个人数据库上进行更改，直到您“发布”您的更改为止。

Answer 3

在多开发人员环境中，数据库版本控制始终是最困难的事情。

通常，每个用户都将拥有自己的DB，这是某些DB更改(但不是所有DB更改)的嵌合体。当他们进行更改时，他们将需要提交他们的更改脚本。这真的很尴尬。核心问题似乎源于影响系统许多方面的数据库更改，以及多个表更改相互依赖，以及如何从旧模式迁移到新模式。将数据迁移到新模式通常是不容易的。通常，当数据被复制到新架构时，您希望默认列，而不是默认插入的一般列。这些通常在生产部署问题上已经很困难，并且在开发期间必须管理数据库，因为数据库设计可能处于与主要部署一样的主要变化中，这比您在开发中通常需要做的工作要多得多。可以更好地花费时间来确保您的数据库设计得很好--约束、放弃密钥等等。

由于开发人员更有可能在数据库更改中相互影响，所以我们总是有一个数据库瓶颈--开发人员都是针对同一个开发数据库进行开发的，并进行了“实时”更改。然后对dev数据库进行独立的版本控制。这并不是真正的容易，当人们离地或其他什么。另一种选择是让指定的数据库开发人员协调多个开发人员需要对同一个表进行的更改--这不需要是他们的全部工作，但给您提供了更好的DB设计一致性。或者，您可以协调数据库修订，以便人们更清楚地了解其他人正在做的DB revs，并将他们的更改安排到另一个开发人员可用的DB rev为止。