我的四个人的开发团队已经面临这个问题一段时间了：
有时我们需要处理同一组数据。因此，当我们在本地计算机上开发时，开发数据库是远程连接的。
但是，有时我们需要在数据库上运行会踩到其他开发人员数据的操作，即我们打破关联。为此，本地数据库会很好。
是否有解决此困境的最佳实践？有没有类似“SCM for data”工具的东西？
以一种奇怪的方式，在 git 存储库中保留一个 SQL 插入/删除/更新查询的文本文件会很有用，但我认为这可能会很快变得非常慢。
你们如何处理这个问题？
问问题
1634 次
10 回答
10
您可能会发现我的问题How Do You Build Your Database From Source Control很有用。
从根本上说，有效管理共享资源（如数据库）是很困难的。这很难，因为它需要平衡多人的需求，包括其他开发人员、测试人员、项目经理等。
通常，为单个开发人员提供自己的沙盒环境更有效，他们可以在其中执行开发和单元测试，而不会影响其他开发人员或测试人员。不过，这并不是万能的，因为您现在必须提供一种机制，使这些多个独立的环境随着时间的推移彼此保持同步。您需要确保开发人员有一种合理的方式来获取彼此的更改（数据、模式和代码）。这不一定更容易。良好的 SCM 实践会有所帮助，但仍需要相当程度的合作和协调才能实现。不仅如此，为每个开发人员提供他们自己的整个环境的副本会增加存储成本，并增加额外的 DBA 资源来协助管理和监督这些环境。
这里有一些想法供您考虑：
- 创建一个共享的公共“环境白板”（可以是电子版），开发人员可以在其中轻松查看哪些环境可用以及谁在使用它们。
- 确定拥有数据库资源的个人或团体。他们负责跟踪环境，并帮助解决不同群体（开发人员、测试人员等）的冲突需求。
- 如果时间和预算允许，请考虑为所有开发人员创建沙盒环境。
- 如果您还没有这样做，请考虑将开发人员的“游戏区域”与您的集成、测试和验收测试环境分开。
- 确保您对关键数据库对象进行版本控制——尤其是那些经常更改的对象，如触发器、存储过程和视图。如果有人覆盖了其他人的更改，您不希望失去工作。
于 2010-06-28T15:26:11.217 回答
5
我们使用本地开发人员数据库和单个主数据库进行集成测试。我们将创建脚本存储在 SCM 中。一位开发人员负责更新基于“黄金大师”模式的 SQL 脚本。开发人员可以根据需要对其本地数据库进行更改，根据需要从集成数据库中的数据填充，使用导入过程或使用工具（在我们的示例中为 Red Gate 数据生成器）生成数据。如有必要，开发人员可以清除他们的本地副本，并可以根据需要从创建脚本和集成数据中刷新。通常，数据库仅用于集成测试，我们将它们模拟出来以进行单元测试，从而最大限度地减少保持同步的工作量。
于 2010-06-28T15:22:40.647 回答
3
我建议你看看 Scott Allen 对这个问题的看法。他写了一系列博客，在我看来，这些博客非常棒。 数据库工作的三个规则， 基线， 更改脚本， 视图，存储过程等， 分支和合并。
我或多或少地使用这些准则，并进行个人更改并且它们起作用。
于 2010-06-28T23:38:13.093 回答
0
过去，我用几种方法处理过这个问题。
一种是创建和填充数据库的 SQL 脚本存储库。这根本不是一个糟糕的选择，并且可以使所有内容保持同步（即使您不使用此方法，您仍应维护这些脚本，以便您的数据库处于源代码管理中）。
另一个（我更喜欢）是在没有人连接的服务器上拥有一个“干净”开发数据库的单个实例。当开发人员需要刷新他们的开发数据库时，他们会运行一个 SSIS 包，将“干净”的数据库复制到他们的开发副本中。然后，我们可以根据需要修改我们的开发数据库，而不会影响其他开发人员。
于 2010-06-28T15:17:46.980 回答
0
我们有一个数据库维护工具，我们使用它来创建/更新我们的表和我们的过程。我们有一个服务器，它有一个填充了数据的最新数据库。
我们保留我们可以选择使用的本地数据库，但是当我们需要返回“基线”时，我们会从服务器获取“主”的备份并在本地恢复它。
如果/当我们添加列/表/过程时，我们会更新保存在源代码管理中的 dbMaintenance 工具。
有时，它很痛苦，但它运作得相当好。
于 2010-06-28T15:19:15.383 回答
0
如果您使用诸如 nHibernate 之类的 ORM，请创建一个脚本，在您的开发人员的本地开发数据库中生成模式和数据。
在开发过程中改进该脚本以包含典型数据。
部署前在暂存数据库上进行测试。
我们为最终用户将生产数据库复制到 UAT 数据库。开发人员无法访问该数据库。
删除所有表、重新创建它们并注入测试数据只需不到几秒钟的时间。
如果您使用的是生成模式的 ORM，则不必维护创建脚本。
于 2010-06-28T15:22:04.547 回答
0
以前，我开发了一个与数据仓库相关的产品，如果需要，可以安装在客户站点上。因此，该软件知道如何进行“安装”（主要是创建所需的数据库模式和静态数据，如货币/国家代码等）。
因为我们在代码本身中有这些信息，并且因为我们有可插入的 SQL 适配器，所以让这段代码与内存数据库（我们使用 HSQL）一起工作是微不足道的。因此，我们针对“真实”本地服务器（Oracle 或 SQL Server）进行了大部分实际开发工作和性能测试，但针对特定于进程的内存数据库进行了所有单元测试和其他自动化任务。
在这方面我们非常幸运，如果集中静态数据发生变化，我们需要将其包含在安装说明的升级部分中，因此默认情况下它存储在 SCM 存储库中，由开发人员和作为其正常工作流程的一部分安装。回想起来，这与您提出的 DB 更改日志想法非常相似，只是更加形式化并且围绕它具有特定于域的抽象层。
这个方案效果很好，因为任何人都可以在几分钟内用最新的静态数据构建一个完全工作的数据库，而不会踩到其他人的脚趾。如果您不需要安装/升级功能，我不能说是否值得，但我还是会考虑它，因为它使数据库依赖完全无痛。
于 2010-06-28T15:26:22.357 回答
0
这种方法怎么样：
为“干净的数据库”维护一个单独的存储库。repo 将是一个带有表创建/插入等的 sql 文件。
使用 Rails（我确信可以适用于任何 git repo），将“clean db”作为应用程序中的子模块进行维护。编写一个脚本（也许是 rake 任务），使用 SQL 语句查询本地开发数据库。
要清理本地数据库（并替换为新数据）：
git submodule init
git submodule update
然后
rake dev_db:update ......... (or something like that!)
于 2010-06-28T16:11:29.720 回答
0
我做了两件事之一。在这两种情况下，处理可能与其他人冲突的代码的开发人员在本地运行自己的数据库，或者在开发数据库服务器上获取单独的实例。
与@tvanfosson 推荐的类似，您保留一组可以从头开始构建数据库的 SQL 脚本，或者
根据我们使用的数据类型，所有开发人员数据库都会定期被生产数据的副本或按比例缩小/去标识化的生产副本覆盖。
于 2010-06-28T16:16:59.370 回答
0
我同意 LBushkin 在他的回答中所说的所有内容。如果您使用的是 SQL Server，我们在 Red Gate 提供了一个解决方案，可以让您轻松地在多个开发环境之间共享更改。
http://www.red-gate.com/products/sql_source_control/index.htm
如果存在存储问题，让您的 DBA 难以支持多个开发环境，Red Gate 有一个解决方案。使用 Red Gate 的 HyperBac 技术，您可以为每个开发人员创建虚拟数据库。这些看似与普通数据库完全相同，但在后台，不同数据库之间正在共享公共数据。这允许开发人员拥有自己的数据库，而不会占用 SQL Server 上不切实际的存储空间。
于 2010-07-03T11:14:57.287 回答