《测试驱动数据库开发》—第2章2.3节数据库的类

  • 时间:
  • 浏览:0
  • 来源:uu直播快3平台

过了一段时间,让一帮人会重复上述过程来实施另某种转变,使数据库演进到下有兩个版本,如此这般循环往复。

本节书摘来自异步社区《测试驱动数据库开发》一书中的第2章2.3节数据库的类,作者【美】Max Guernsey, III,更多章节内容不能 访问云栖社区“异步社区”公众号查看。

2.3.2 难点:统一两条途径

正是过后数据库世界中你这俩表里不一的问題,使得定义数据库的类变成了一项困难的工作。如何不能为某件事构建有兩个类,使得在某种情况报告下,该类被从头过后刚开始创建;而在另某种情况报告下,该类过后在几瓶迭代周期里被多次构建,且什么迭代周期之间又会间隔很长的时间?

答案是“如此”的。几乎不能 什么都 认为,对于有兩个长期运转的数据库,其设计必将定期地趋于稳定变更。

然而,全世界每有兩个重要的数据库都不 被创建一次,过后被修改多次的。

在我与底下你这俩团队共同工作期间,使用上述工作依据进行了6次产品发布, 如此1次该依据实现了完美地工作。系统所有的用户回家度周末你这俩后备方案,不能保护让一帮人免受真正的灾难,帮助让一帮人抵御重大的系统服务中断。过后,在周五夜晚熬到9点半或更晚不能发布产品真的愿意抓狂。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

上述工作依据在开发团队中是很正常的。然而,什么开发团队编写并据此进行测试的上述脚本,永远不要在生产环境下使用。取而代之的是,让一帮人会把新的数据库设计提交给数据库专家,数据库专家再创建有兩个新的数据库实例,并运行有兩个diff工具,来搞清楚新的数据库设计与什么都 相比有什么变更。当然,上述工具的输出结果不要被全盘接受,而仅仅是用来指导数据库专家编写有兩个新的脚本,从而实现底下的数据库设计的变更。数据库专家会手工备份生产数据库实现变更,并验证一切不能正常工作。

规则很简单,具体如下。

有兩个清晰的模式正在形成:生产数据库设计的变更通常从每有兩个发布版本过渡到下有兩个版本,过后再到下有兩个,以此类推。这时,有兩个明显的问題会映入脑海:让一帮人不 过后克服变更你这俩问題吗?

2.3.3 真实的数据库的生长情况报告

找到上述途径对读者来说过后是具有挑战性的,不然立刻就能看后出理 方案。当难以找到某种出理 方案时,看看数据库世界真正趋于稳定了什么是会有所帮助的。在你这俩情况报告下,研究一下真正的生产数据库是如何构建和成长的对出理 问題会很有帮助。

2.3 数据库的类

测试驱动数据库开发

尽管事实上,大多数的过后,数据库什么都 底下保存什么不被使用的对象内容的“你这俩地方”,在数据库开发中运用上述模式你这俩什么都 切合实际。与上述描述最接近的做法,应该是当每次想更新对象的行为时,就从旧数据库中迁移数据到新创建的更新后的对象中。对于你这俩数据库来说,上述做法过后仍然比让一帮人现在做的依据要快你这俩,过后过后还有另某种支持比这如此快的开发过程的做法,过后就将上述做法作为有兩个可选项而不再继续讨论了。

2.3.5 所有数据库都遵循详细相同的途径

问題的关键是,只是依次执行有兩个版本之间的所有脚本,就能从任意版本过渡到下一版本。要想把数据库从版本5过渡到版本7,除了按上述依据执行脚本,就不如此做额外的工作了。过后你过后知道如何从版本5过渡到版本6,过后知道如何从版本6过渡到版本7,什么都 你就能知道如何从版本5过渡到版本7。

4.当构建数据库时,从数据库的当前版本直到期望的目标版本,依次运行所有相应的脚本。

2.3.4 将每个数据库构建成生产数据库会缘何样

什么都 ,过后如此改变构建生产数据库的依据,不能 考虑下面的替代方案:用构建生产数据库的依据来构建每个数据库。什么都 做会有什么问題吗?肯定一帮人会得出买车人的答案,过后对于让一帮人大多数人,对上述问題的回答是:“用构建生产数据库详细相同的依据来构建每个数据库居然非常有意义。”

2.为了获得新的数据库,构建脚本,使得数据库的版本从零过渡到1。

最后,当作出要以某种依据更改数据库的设计的决定后,开发人员会完成你这俩工作来确认更改,构建相关的功能和基础架构,并确保一切都不能组合在共同工作,过后生产数据库会被实施有兩个变更,使数据库的设计趋于稳定了由旧到新的改变。

过后,要构建有兩个新的版本为3的数据库,不能 执行版本1的脚本,接着执行版本2的脚本,再接着执行版本3的脚本。为了将数据库从版本1升级到版本3,不能 执行版本2的脚本,接着执行版本3的脚本。

上述“某种途径”的问題不要说能真正得到出理 。唯一合理的出理 方案是详细消除这两条途径,这原因分析分析应用程序池池员如此找到实例化数据库的类的单条途径,使得该途径既能产生新的数据库实例,又能更新数据库的类的现有实例。

1.将有兩个空的初始化好的数据库实例当做版本零。

3.为了升级数据库,构建脚本,使得数据库的版本从N过渡到N+1。

2.3.1 两条途径:创建或改变

在你这俩系统中,创建某“类”数据库实例有两条途径。两根途径是针对从无到有地被创建的数据库,你这俩情况报告老会 趋于稳定在测试和开发的环境中;另两根途径是针对反复更新的数据库,什么更新是过后随着时间的推移,数据库的设计以行为增量的形式不断地演进而产生的,你这俩情况报告往往趋于稳定在生产环境中。

在所有诸如创建空的数据库实例什么都 乏味的事情过后刚开始后,第一件事情什么都 执行一系列DDL的话,将所有数据库初始化时应具备的行为注入到数据库中。通常情况报告下,上述事情不能 通过执行与开发团队使用的详细相同的SQL脚什么都 完成。

问題的根源是,开发人员试图像对待典型的面向对象编程的类一样,即仅仅通过被创建和析构去对待数据库的类。让一帮人不 操心数据库被修改了的情况报告,过后那是买车人的工作。

只是按上述依据来做,就向测试驱动数据库开发的正确方向跨出了一大步。

应用开发团队的工作往往是上述情况报告的最好的说明。有兩个我曾参与工作的团队拥有有兩个代表“数据库”的脚本,该脚本通过你这俩如电子邮件或网络共享文件夹什么都 的机制被共享,当有兩个开发人员搞乱了他的数据库,他会把整个数据库删除,过后运行这段脚本。让一帮人不 设计你这俩有意义的变化时,让一帮人会把什么变化写入“脚本”中。有过后有兩个偷懒的开发人员过后通过你这俩GUI,用他操作的有兩个数据库实例为蓝本,重新生成了你这俩“脚本”。