在开发过程中如何管理数据库？答案

【问题标题】：How do you manage databases during development?在开发过程中如何管理数据库？
【发布时间】：2010-06-28 15:14:23
【问题描述】：

我的四人开发团队已经面临这个问题一段时间了：

有时我们需要处理同一组数据。因此，当我们在本地计算机上开发时，开发数据库是远程连接的。

但是，有时我们需要在数据库上运行会踩到其他开发人员数据的操作，即我们破坏关联。为此，本地数据库会很好。

是否有解决此困境的最佳做法？有没有类似“SCM for data”的工具？

以一种奇怪的方式，在 git 存储库中保留 SQL 插入/删除/更新查询的文本文件会很有用，但我认为这可能会很快变得非常慢。

你们是怎么处理这个问题的？

【问题讨论】：

我见过的唯一方法是让 50 多名程序员对数据库进行他们喜欢的任何更改，然后当事情停止工作时向 DB 管理员（真的是你的）抱怨。我不能说我推荐这种方法。
非常有意义:) 这对于一个四人团队来说非常有效。随着我们团队的发展（很有可能），我希望有一个更优雅的解决方案。

标签： database version-control data-integrity data-integration

【解决方案1】：

您可能会发现我的问题How Do You Build Your Database From Source Control 很有用。

从根本上说，有效管理共享资源（如数据库）很难。很难，因为它需要平衡多人的需求，包括其他开发人员、测试人员、项目经理等。 p>

通常，为单个开发人员提供自己的沙盒环境更为有效，他们可以在其中执行开发和单元测试，而不会影响其他开发人员或测试人员。不过，这不是万能的，因为您现在必须提供一种机制，使这些多个独立的环境随着时间的推移彼此保持同步。您需要确保开发人员有合理的方式来获取彼此的更改（数据、模式和代码）。这不一定更容易。一个好的 SCM 实践可以提供帮助，但它仍然需要相当程度的合作和协调才能实现。不仅如此，为每个开发人员提供他们自己的整个环境副本可能会增加存储成本，并增加额外的 DBA 资源来协助管理和监督这些环境。

这里有一些想法供您考虑：

创建一个共享的公共“环境白板”（可以是电子版），开发人员可以在其中轻松查看哪些环境可用以及谁在使用它们。
确定个人或团体拥有数据库资源。他们负责跟踪环境，并帮助解决不同群体（开发人员、测试人员等）的冲突需求。
如果时间和预算允许，请考虑为所有开发人员创建沙盒环境。
如果您还没有这样做，请考虑将开发人员的“游戏区域”与您的集成、测试和验收测试环境分开。
确保对关键数据库对象进行版本控制，尤其是那些经常更改的对象，如触发器、存储过程和视图。如果有人覆盖了其他人的更改，您不希望失去工作。

【讨论】：

【解决方案2】：

我们使用本地开发人员数据库和单个主数据库进行集成测试。我们将创建脚本存储在 SCM 中。一位开发人员负责更新基于“黄金大师”模式的 SQL 脚本。开发人员可以根据需要对其本地数据库进行更改，根据需要从集成数据库中的数据填充，使用导入过程，或使用工具（在我们的例子中为 Red Gate 数据生成器）生成数据。如有必要，开发人员可以清除他们的本地副本，并可以根据需要从创建脚本和集成数据中刷新。通常，数据库仅用于集成测试，我们将它们模拟出来用于单元测试，从而最大限度地减少保持同步的工作量。

【讨论】：

【解决方案3】：

我建议您看看 Scott Allen 对此事的看法。他写了一系列博客，在我看来，这些博客非常棒。 Three Rules for Database Work, The Baseline, Change scripts, Views, stored procs etc, Branching and Merging.

我或多或少地使用这些准则，并进行个人更改并且它们有效。

【讨论】：

【解决方案4】：

在过去，我已经通过几种方式处理过这个问题。

一个是创建和填充数据库的 SQL 脚本存储库。这根本不是一个糟糕的选择，并且可以使所有内容保持同步（即使您不使用此方法，您仍应维护这些脚本，以便您的数据库处于源代码管理中）。

另一个（我更喜欢）是在没有人连接的服务器上拥有一个“干净”开发数据库的单个实例。当开发人员需要刷新他们的开发数据库时，他们会运行一个 SSIS 包，将“干净”的数据库复制到他们的开发副本中。然后，我们可以根据需要修改我们的开发数据库，而不会影响其他开发人员。

【讨论】：

【解决方案5】：

我们有一个数据库维护工具，我们使用它来创建/更新我们的表和我们的过程。我们有一个服务器，它有一个填充了数据的最新数据库。

我们保留了我们可以选择使用的本地数据库，但是当我们需要返回“基线”时，我们会从服务器获取“主”的备份并在本地恢复。

如果/当我们添加列/表/过程时，我们会更新保存在源代码控制中的 dbMaintenance 工具。

有时，这很痛苦，但效果相当好。

【讨论】：

【解决方案6】：

如果您使用诸如 nHibernate 之类的 ORM，请创建一个脚本，在您的开发人员的 LOCAL 开发数据库中生成架构和数据。

在开发过程中改进该脚本以包含典型数据。

在部署前在暂存数据库上进行测试。

我们为最终用户将生产数据库复制到 UAT 数据库。开发人员无法访问该数据库。

只需几秒钟即可删除所有表、重新创建它们并注入测试数据。

如果您使用的是生成架构的 ORM，则不必维护创建脚本。

【讨论】：

【解决方案7】：

以前，我开发了一个与数据仓库相关的产品，如果需要，我可以将其安装在客户站点上。因此，该软件知道如何进行“安装”（主要是创建所需的数据库模式和静态数据，如货币/国家代码等）。

因为我们在代码本身中有这些信息，并且因为我们有可插入的 SQL 适配器，所以让这个代码与内存数据库（我们使用 HSQL）一起工作是微不足道的。因此，我们针对“真实”本地服务器（Oracle 或 SQL Server）进行了大部分实际开发工作和性能测试，但针对特定进程的内存数据库进行了所有单元测试和其他自动化任务。

在这方面我们很幸运，如果集中静态数据发生变化，我们需要将其包含在安装说明的升级部分中，因此默认情况下它存储在 SCM 存储库中，由开发人员并作为其正常工作流程的一部分进行安装。回想起来，这与您提出的 DB 更改日志想法非常相似，只是更加形式化并且围绕它具有特定于域的抽象层。

这个方案效果很好，因为任何人都可以在几分钟内用最新的静态数据构建一个完全正常工作的数据库，而不会踩到其他人的脚趾。如果您不需要安装/升级功能，我不能说它是否值得，但我还是会考虑它，因为它使数据库依赖完全无痛。

【讨论】：

【解决方案8】：

这种方法怎么样：

为“干净的数据库”维护一个单独的存储库。 repo 将是一个带有表创建/插入等的 sql 文件。

使用 Rails（我确信可以适用于任何 git repo），将“干净的数据库”作为应用程序中的子模块进行维护。编写一个脚本（也许是 rake 任务），使用 SQL 语句查询本地开发数据库。

清理本地数据库（并替换为新数据）：

git submodule init
git submodule update

然后

rake dev_db:update ......... (or something like that!)

【讨论】：

【解决方案9】：

我做了两件事之一。在这两种情况下，处理可能与其他人冲突的代码的开发人员在本地运行自己的数据库，或者在开发数据库服务器上获取单独的实例。

类似于@tvanfosson 的建议，您保留一组可以从头开始构建数据库的 SQL 脚本，或
根据我们使用的数据类型，所有开发人员数据库都会定期被生产数据的副本或按比例缩小/去标识化的生产副本覆盖。

【讨论】：

【解决方案10】：

我同意 LBushkin 在回答中所说的所有内容。如果您使用的是 SQL Server，我们在 Red Gate 提供了一个解决方案，可以让您轻松地在多个开发环境之间共享更改。

http://www.red-gate.com/products/sql_source_control/index.htm

如果存在使您的 DBA 难以支持多个开发环境的存储问题，Red Gate 有一个解决方案。使用 Red Gate 的 HyperBac 技术，您可以为每个开发人员创建虚拟数据库。这些看起来和普通数据库完全一样，但在后台，不同数据库之间共享公共数据。这允许开发人员拥有自己的数据库，而不会占用 SQL Server 上不切实际的存储空间。

【讨论】：