Question

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

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

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

有解决这种困境的最佳做法吗？有没有像“SCM for data”工具那样的东西？

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

你们怎么处理这个？

Answer 1

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

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

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

以下是您可以考虑的一些想法：

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

Answer 2

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

Answer 3

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

我或多或少地使用这些指南，个人更改并且有效。

Answer 4

在过去，我已经采取了以下几种方式。

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

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

Answer 5

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

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

如果/当我们添加列/表/ proc时，我们更新保存在源代码管理中的dbMaintenance工具。

有时，这是一种痛苦，但效果相当好。

Answer 6

如果您使用ORM（如nHibernate），请创建一个生成架构和模式的脚本。开发人员的LOCAL开发数据库中的数据。

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

在部署之前在临时数据库上进行测试。

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

删除所有表，再次创建表并注入测试数据只需不到几秒钟。

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

Answer 7

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

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

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

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

Answer 8

这种方法怎么样：

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

使用Rails（我确信可以适用于任何git repo），将“clean db”维护为应用程序中的子模块。编写一个脚本（可能是rake任务），用SQL语句查询本地dev db。

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

git submodule init
git submodule update

然后

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

Answer 9

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

与@tvanfosson推荐的类似，您保留了一组可以从头开始构建数据库的SQL脚本，或
在定义良好的定期基础上，所有开发人员数据库都会被生产数据副本或缩小/取消标识的生产副本覆盖，具体取决于我们使用的数据类型。

Answer 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上不切实际的存储空间。

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

10 个答案: