《测试驱动数据库开发》—第2章2.5节实现

2.5 实现
测试驱动数据库开发
至此,前面描述的方式能够让读者初步地刻画和实例化数据库的类。下面将介绍一些实现一个数据库的类的方法。本书先从总体需求入手,然后提供一个数据库类的伪代码实现,可以将其移植到任何平台上。

2.5.1 需求
让我们来看看一个良好的数据库的类的实例化机制应该是什么样子的。了解这些需求能够让你编写自己的机制,或者当你面对的需求明显不同于本书描述的情况时,可以调整本书建议的机制,从而适应你的具体情况。

我已经确定了4个需求,并用4个以字母C开头的单词来分别描述之,称其为“4C机制”,希望这个词儿能流行起来。

4C机制如下所述,数据库的类的实例化机制必须是完整的(Complete),对于一个特定的版本,该机制执行了所有必要的变更;该机制必须是正确的(Correct),同样的变更从不在数据库上施加两遍;该机制必须是一致的(Consistent),每一次变更的实施,都是以完全相同的顺序来执行;最后,该机制必须是可控的(Controllable),只要想构建一个特定的数据库,读者就一定能够规定一个目标版本来构建之。

2.5.2 数据库实例化机制的伪代码
用可重复的方式来可靠地更新数据库的算法其实出奇地简单。经过多年的完善,至少与开始时搞出的东西相比,我总是惊讶于它是如此地简单。

UpgradeDatabase(<db>, <design>, <target version>)
  <current version> = current version of <db>
  <required versions> =
     versions from <design> after <current version> and up through
<target version>
  sort <required versions> in ascending order
  for each <version> in <required versions>
     execute transition for <version> against <db>
     update current version of <db> to version number of <version>

上述伪代码的实现细节将留给读者来完成,但是本书通常用XML文档的形式来表达数据库的设计,并且把已经施加到数据库上的变更版本存储在一个数据库表中。这样,数据库的“当前”版本就能够通过选择该表最近插入的行来推断。

2.5.3 输入的伪代码
上述算法的输入可以是一个XML文件或一些其他格式的文本文件。只要数据库的每一个版本可以被确定下来,被适当地排序,并能在数据库实例进行实例化时声明其所需的步骤,任何格式的输入都是可以的。

为了说明这个问题,下面给读者一段简单的XML,包含了用于构建和升级一个小型数据库的脚本:

<database>
  <version id="1">CREATE TABLE FOO(A I NT)</version>
  <version id="3">CREATE TABLE BAR(C CHAR(30))</version>
  <version id="2">ALTER TABLE FOO ADD B NVARCHAR(20)</version>
</database>

如上所示,XML文件包含了可用来排序、标识和执行SQL语句的所有信息,这些信息用来构建数据库或将数据库更新到任何特定的版本。

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

时间: 2024-10-28 23:38:58

《测试驱动数据库开发》—第2章2.5节实现的相关文章

《测试驱动数据库开发》—第2章2.1节TDD中类的角色

第 2 章 建立数据库的类 测试驱动数据库开发 开始测试驱动数据库时,需要做的第一件事是定义数据库的类,并且不用过多地担心特定的数据库实例.读完本书后,读者将有可能开始从允许任意的手工修改,转变到允许保持任意有意义的数据库实例.为了帮读者达到这个目的,本章将深入讨论什么是类以及类如何能够提供帮助,还将深入探讨在数据库开发中的影响力是如何不同于应用程序开发的影响力的. 在调和了类的本质与在数据库开发中出现的新的影响力之后,本章展现了一个数据库的类的需求,并展示了如何实现该需求.希望能为开发者提供与

《测试驱动数据库开发》—第1章1.4节小结

1.4 小结测试驱动数据库开发在写本书时,精益和敏捷软件开发正在全球大行其道,但是数据库开发在开发过程中仍然是瓶颈.为了消除阻挡整个组织的障碍,开发人员必须找到如何让数据库快速变化的方法. 然而,不能以牺牲对变化的信心来换取快速的变化,数据库是如此重要,以至于不能容许有任何额外的风险.这里 TDD 就可以派上用场了,与那些没有使用TDD缓慢的最小心翼翼地做出的变化相比,TDD能让开发者冒更小的风险而做出更频繁.快速的变化. 即使这样,开发者还是不能简单地将已经学到的适用于"常规"软件开

《测试驱动数据库开发》——第 1 章 为何改变书的内容、谁是

第 1 章 为何改变书的内容.谁是 测试驱动数据库开发本书主要介绍如何将测试驱动开发(TDD)法则有效地运用在与数据库功能交付相关的任务上,是专为那些想知道如何将测试驱动开发法则运用到数据库编程上的人们而写的.然而,在讨论如何做之前,需要先看看为何改变本书内容,谁是目标读者,以及什么是障碍. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

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

第 2 章 建立数据库的类 测试驱动数据库开发开始测试驱动数据库时,需要做的第一件事是定义数据库的类,并且不用过多地担心特定的数据库实例.读完本书后,读者将有可能开始从允许任意的手工修改,转变到允许保持任意有意义的数据库实例.为了帮读者达到这个目的,本章将深入讨论什么是类以及类如何能够提供帮助,还将深入探讨在数据库开发中的影响力是如何不同于应用程序开发的影响力的. 在调和了类的本质与在数据库开发中出现的新的影响力之后,本章展现了一个数据库的类的需求,并展示了如何实现该需求.希望能为开发者提供与实

《测试驱动数据库开发》—第2章2.2节面向对象编程语言中的类

2.2 面向对象编程语言中的类 测试驱动数据库开发 为何对象的类来到应用开发世界的时间要远远比数据库的类早呢?首先,与在应用开发世界相比,在数据库世界中能让类成为必要元素的影响力没有那么强大,这一点先暂且不谈.其次,相比创建数据库实例,我们能够更加容易地建立可靠的方法来在应用会话中创建对象. 2.2.1 类的构建很容易:构建新对象即可 在面向对象编程的世界中,类其实仅有两个职责:创建新对象和析构(destroy)被废弃的对象.就本书的目的而言,析构其实并不重要.然而,对象的创建绝对是重要的. 在

《测试驱动数据库开发》—第1章1.2节谁是目标读者

1.2 谁是目标读者测试驱动数据库开发在讨论问题真正的本质是什么和如何解决问题之前,先谈一下关于本书的目标读者.任何读者都可能从本书获取价值,但在使用这本书之前,读者需要具备一些必备的技能. 1.2.1 TDD和OOP为了运用好本书中涉及的技术,读者需要理解测试驱动开发和面向对象编程的好处,但不必是这两方面的专家,只需要知道实现上述两个方面之后所带来的好处是什么.下面这些论断是有意义的. TDD通过让开发者保持在正确的轨道上,以使你能够快速地开发. OOP通过把不相关的事物进行封装并彼此分离,以

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

2.3 数据库的类测试驱动数据库开发尽管事实上,大多数的时候,数据库就是上面保存那些不被使用的对象内容的"其他地方",在数据库开发中运用上述模式一点也不切合实际.与上述描述最接近的做法,应该是当每次想更新对象的行为时,就从旧数据库中迁移数据到新创建的更新后的对象中.对于许多数据库来说,上述做法可能仍然比许多人现在做的方式要快许多,但是因为还有另一种支持比这还要快的开发过程的做法,因此就将上述做法作为一个可选项而不再继续讨论了. 2.3.1 两条途径:创建或改变在许多系统中,创建某&qu

《测试驱动数据库开发》—第2章2.4节增量构建

2.4 增量构建测试驱动数据库开发那么,该如何与上述机制进行交互呢?最好的方式应该是把数据库的每一次变更当做一个单独的版本用文档记录下来,并找到一个好方式(如版本号)来将这些变更进行排序.只要数据库能够标识已经发生了哪些变更,就能构建一个通用的机制来按正确的顺序实施正确的变更. 2.4.1 用文档记录每一次数据库的变更开始的时候,只编写涉及一个变更的脚本.只要该脚本没有在重要的数据库上运行,就可以根据开发人员的意图,或者根据需求的变化,来随意地修改这个脚本.此时,该脚本其实是在不久的将来要做的事

《测试驱动数据库开发》—第2章2.6节小结

2.6 小结测试驱动数据库开发测试执行时检查特定对象的行为.存在可靠的实例化过程很有用处,因为它确保了一个特定类的所有对象都是相同的.这种关联意味着如果测试了一个类的一个对象,就测试了这个类的所有对象,因此,看起来好像测试了这个类本身. 这就是数据库开发真正不同于传统的面向对象开发的第一点.对于存储在内存中的对象,其类的构造方法可以用销毁先前为该对象分配.在内存中的任何内容的方式,并遵循一个单一的.简单的途径来构建一个工作对象. 然而,当构建一个数据库时,照顾到那些已经保存在数据库内的数据往往是