源控制数据库数据导入策略

Question

所以我得到了一个项目并让数据库团队在数据库的源代码控制上出售（怪异的权利？）无论如何，db已经存在，它是庞大的，并且应用程序非常依赖于数据。在编写SPROC等时，开发人员需要最多三种不同类型的数据。

显然我可以编写数据插入脚本。

但我的问题是你使用什么工具或策略从源代码控制构建数据库并用多个大型数据集填充它？

Answer 1

很高兴看到您将数据库置于源代码管理之下。

我们在源代码控制中有数据库对象，但没有数据（除了一些查找值）。要维护dev上的数据，我们通过恢复最新的prod备份来刷新它，然后重新运行脚本以进行任何数据库更改。如果我们正在做的事情需要特殊数据（比如不在prod或测试登录上的新查找值），我们也有一个脚本，它是源代码控制的一部分，可以同时运行。您不希望编写所有数据的脚本，因为通过脚本重新创建1000万条记录非常耗时（如果您有1000万条记录，您当然不希望开发人员针对具有10个测试记录的数据库进行开发！ ）。恢复prod数据要快得多。

由于我们的所有部署都是通过源代码控制脚本完成的，因此我们不会遇到让人们编写所需内容的问题。希望你也不会。当我们第一次启动时（并且当dev coudl执行自己的部署时），我们必须经历几次并删除任何不在源代码控制中的对象。我们很快就学会了将所有数据库对象放在源代码管理中。

Answer 2

通常，我们只为源代码控制.sql文件，以便（重新）构建架构。

然后我们在源代码控制中放入能够读取生产或集成数据库的脚本，以便提取和填充数据库中由先前.sql执行产生的相关数据集。

我们的想法是使用足够强大的脚本来获取最新数据，以便从数据库中读取它们，该数据库并不总是与正在构建的数据库版本相同。 （实际上，差异从来没有那么大，数据很容易被读取）。

Answer 3

这最好作为两个单独的科目来处理。一方面，您需要一个可靠且一致的数据库模式（表，索引，vies，过程，函数以及查找值和系统所需的任何不变的“静态”数据），并且您希望对其进行版本控制因此，您可以跟踪随时间（以及由谁）发生的更改，并且还可以控制何时将更改应用于哪些数据库实例。此问题的先前帖子已经很好地涵盖了这个主题。

另一方面，您需要使用数据填充数据库，您可以使用该数据库测试和开发新代码。定义和加载此类数据与定义和加载将保留它的结构不同。虽然通过源代码控制来管理数据库定义可能是一个容易解决的问题，但在过去的许多年里，我从未听说过解决数据问题的同样简单（相对简单）的解决方案。问题的方面包括：

• 确保有足够的数据。每个表添加10-20行很容易，但如果您的实时数据库包含数百万行或更多行，则无法预测性能。

• 快速简便的解决方案是获取最新的生产数据库的副本，使用最近的更改进行更新，然后离开。如果开发环境没有SAN来托管您支持的多TB生产数据的副本，这可能会非常棘手

• 同样，SOX和/或HIPAA审核员可能不希望在不太安全的开发服务器上存在额外的潜在机密数据副本（在不太安全的开发人员面前 - 我们是一堆狡猾的， 毕竟）。在将敏感数据提供给开发人员之前，您可能需要对敏感数据进行加扰或随机化...这意味着需要使用临时“加扰器”进程来清理数据。 （也许是所有那些TB的另一个SAN？）

• 在某些情况下，某些部门或其他部门可以为您提供正确，连贯且协调的数据集，以便进行开发 - 这些部分可以弥补所有可能的情况并且他们可以在他们身边进行测试（知道什么进入，他们知道应该出现什么，并且可以检查它）。当然，创建这样一组数据的努力是巨大的，并且令人信服的非IT团队提供这样的数据集可能在政治上是不可能的。但这是一个美好的梦想。

• 当然数据会发生变化。在开发中复制了一个星期，一个月，一个季度之后，最终并且不可避免地会发现生产数据不再“看起来” - 使用模式将发生变化，平均值为重要的价值观会有所不同，所有的日期都会变得陈旧无关......无论如何，你需要重新获得新的数据。

这是一个丑陋的问题，没有我听说过的简单解决方案。一种可能有用的可能性：我记得过去读过的产品可以用来“填充”数据库，并用统计相关的数据组成。您可以指定“此表中的10,000行，此col是标识主键，此tinyint的范围为1-10，具有相同的分布，此varchar的范围为6到30个字符，可能有2％重复”，依此类推。这样的事情可能是非常宝贵的，但这完全取决于你发现自己的环境。

Answer 4

查看Visual Studio Team System，数据库版本 - 2008年与GDR 2下载或2010年。它可以处理模式版本控制，完全集成到源代码控制中，并可以处理测试数据生成（如随机名称等） ）。

我个人喜欢它 - 我使用Management Studio进行开发，然后启动Visual Studio并将更改同步到项目，然后从那里同步到生产。

我将它用于我的开发。我没有编写生产数据的脚本 - 我的maiin数据库现在有大约300gb，我有一个接近5亿行的表。我有一个开发服务器，有时会在需要时加载数据副本。开发人员可以使用最小的数据或开发服务器（这里的人不多）。

初始数据由存储过程或特殊上传/验证脚本维护，这些脚本作为流程的一部分运行并检查查找表等元素。

Answer 5

我过去曾使用过多种策略，但这里有一个有效的方法：

• 创建DDL（数据库创建）脚本并将其检入源代码管理
• 为每个配置创建单独的数据填充脚本（或一组脚本）
• 设置自动构建以为每个配置创建单独的部署包，其中包括相应的脚本

如果您正在处理正在制作的系统并且有无法消除的数据：

• 创建一组单独的“升级/补丁”脚本，用于对模式进行更新（更改表，创建或替换部署目标上已存在的对象的过程等）
• 如果需要，为需要为每个构建填充的任何数据创建“插入”脚本;这些应该是“可重新运行的”（如果补丁部署两次，则不会弄乱数据）

Answer 6

对于包含配置类型数据（非事务性）的表，我们使用Excel。我们在电子表格中插入一个VBA脚本来处理save事件并让它在保存时吐出sql insert语句。业务分析师和客户喜欢Excel，因此这种技术非常适合他们为我们提供预定义的场景供我们测试。我们通常使用Source Control输出.sql文件，以便我们可以使用它来加载自动构建的数据，并将Excel文件放在Team SharePoint站点中。