数据库刷新

在Callaway Golf工作时,我们有一个自动构建,可以从基线完全刷新数据库。这个基线几乎每天都会更新(从生产开始)。我们有一个设置脚本(DTS)可以为我们做到这一点。因此,如果有一些新的和有趣的信息,我们可以很容易地做几次,一周一次,等等。这里的关键是执行任务的自动化。如果很容易做到,那么何时完成实际上只取决于任务的执行如何影响生产数据库、网络的负载以及完成任务所需的时间。当然,这可以设置为一个调度任务,在非高峰时间和开发团队早上进入之前运行。

刷新开发数据库的关键是:

(1) 通过脚本自动刷新。



(3) 决定刷新的频率——我通常每周刷新一次。

取决于你在做什么样的工作。如果您正在调试与数据密切相关的问题,那么频繁的更新是很好的。

如果您正在进行数据质量保证(通常需要编写代码来检测和修复它,您必须在生产服务器之外进行开发和测试),那么您需要非常新的数据。最有价值修复的坏数据是今天刚刚插入或更新的数据。

如果您正在编写客户端代码,则不经常更新是好的。通常,当我编写C#UI代码时,我不太关心数据是什么,我只关心它是否显示在屏幕上的正确框中。

如果您的数据有任何安全问题,您应该停止使用生产数据(即永远不要从生产中更新),并获得一个好的示例数据生成器。编写一个好的示例数据生成器是很困难的,所以第三方产品是可行的。我想到了MS Data Dude,建议使用Sql RedGate的数据生成器。

最后,要得到生产数据的副本有多难?如果它便宜而且可以自动操作,那就每晚换一个新的。如果代价很高(需要非常繁忙的DBA的关注),那么资源约束可能会为您解答这个问题,而不考虑这些其他问题。

我们倾向于每隔几天更新一次,如果事情是“正常”的话,也许一周更新一次,不过如果我们在调查一些不正常的事情,我们可能会经常更新。

我们的生产数据库大约是1GB,所以复制不是一件小事。另外,对于我们来说,通常不需要将当前的数据从生产中获取到开发系统中。

“how”只是MySQL的“backup”和“restore”

在很多情况下,刷新dev数据库并不那么重要。通常,生产系统有更多的开发所需的数据,使用如此大的数据集可能是一个麻烦的原因有几个。示例包括在接口上进行开发,其中 一些

另一方面,性能缺陷通常需要生产规模的数据库能够重现和识别瓶颈,因此在这种情况下,拥有一个几乎实时的数据库是非常有用的。许多问题可能只出现在生产中使用的确切数据上。

一点也不,dev数据库(每个开发人员一个)每天通过脚本或类似的方式设置几次,在本地运行db测试时可能会设置几百次。这包括几张玩的唱片