数据库和DVCS

Question

我最近问了一个关于DVCS适合企业环境的问题，这引发了另一个问题。

DVCS的优势之一似乎是您可以轻松地分支并尝试新事物。当我开始考虑数据库更改时，我的问题开始了。我总是发现将数据库放入VCS很难，而且听起来DVCS会更难。

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

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

Answer 1

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

以下是一些可用选项：

• 迁移 Ruby on Rails中的框架。
Django的
• South ，以及模型类本身定义的模式。
• 适用于.NET的Visual Studio 2008团队系统数据库版：您可以定义架构，并且该工具可以对架构和数据执行差异，以生成在不同版本的数据库之间运行的脚本。

这些可能会为您提供一些如何处理将数据库置于版本控制中的灵感。处理模式时带来的另一个好处是，您可以更轻松地实现TDD和持续集成（CI）。您的TDD / CI环境将能够构建新版本的数据库，然后针对新生成的环境运行测试。

Answer 2

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

Answer 3

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

通常每个用户都有自己的数据库，这是一些但不是所有数据库更改的嵌入式数据。当他们进行更改时，他们需要提交更改脚本。这真的很尴尬。核心问题似乎源于影响系统许多方面的数据库更改以及多个表更改彼此依赖 - 以及如何从旧架构迁移到新架构。将数据迁移到新模式通常非常重要。通常，您希望在将数据复制到新架构时默认列，但是默认情况下默认为INSERT的列。这些通常在生产部署问题上已经很困难，并且在开发期间必须管理数据库时，数据库设计可能处于主要变化中，因为主要部署比通常需要在开发中进行的工作要多得多。花在确保数据库设计良好的时间上可以更好地花费时间 - 约束，外键等等。

因为开发人员更有可能在数据库更改的情况下相互踩踏，所以我们总是有一个数据库阻塞点 - 开发人员都是针对SAME开发数据库开发的，并且他们的更改是“实时”的。然后dev数据库独立地进行版本控制。当人们在异地或其他地方时，这并不容易。另一种方法是让指定的数据库开发人员协调几个开发人员对同一个表所需的更改 - 这不需要是他们的整个工作，而是为您提供更好的数据库设计一致性。或者，您可以协调数据库修订，以便人们更加了解其他人正在进行的数据库转换，并将更改时间等待，直到其他开发人员可以获得数据库转换。

Answer 4

不以二进制形式将数据库放入VCS的最佳方法。周期。

如果您有数据库的文本表示，并且您有特殊的合并工具来解决在不同分支中更改数据库时的冲突 - 那么您可以开始考虑版本化数据库。否则它将是屁股中的持续痛苦。