发信人: hunter__fox(雁回西楼)
整理人: foxzz(2003-08-14 09:13:40), 站内信件
|
经过前几个篇幅的讨论,我们已经了解到一些建立数据库的目标和方法,这里,我们进一步从数据库中找出那些比其它数据更核心的数据.
这里所说的核心数据并不一定是那些最重要的数据.事实上,对于一个完备的数据库来说,90%以上的数据都可以说是重要的.数据库越完备,数据之间的关系也就越复杂,数据之间的影响也就更加难以明了.一个大的数据库,很可能一个小小的数据格式错误就能引起前端系统运行中的一系列错误.因此,大的数据库很难控制(仅从设计角度来看).
因此,我们需要有一些方法来避免这样的情况出现,至少,我们需要让这种情形看起来不是那么糟.
我们有什么可用的手段呢?
第一种方法是使用更严格的规则,如,使用大型数据库平台.大型数据库平台提供了更多的控制,更多的功能,这些控制和功能很大程度上减少了一些隐含的错误的出现几率(当然,它们并不是不会出现,但绝大多数时候,它们在能够在真正影响数据之前被发现).一些大型的数据库也通过一些限制让数据库在设计时就能够处在一个较高的起点.
在MS SQL中,我们想通过记录号来定位记录是很困难的(可以简单的认为是不可能的).这种方式下,我们的数据库没有了看来很方便的一种操作方法,设计数据库时可能会困难一些,但数据库使用起来,却会有一些高的较率.记录号是基于物理位置的,它在数据整理时会改变,不像数据特征,你使用的一个查询语句得到的一些记录,在它们没有改变时,这个查询语句将一直会得到这些记录,不论你是否添加了新的记录,或者是整理了数据库.
对于索引,对于视图,对于存储过程,很多功能,在一些新的数据平台上,都有了很好的完善,这些完善,对于建立数据库系统来说,是很好的.
善用这些功能,可以让数据库设计不再那么头疼----我们一旦设计完成,不需要花太多时间去为一些Bug去修正.
但有些时候,我们局限于一个已经确定的平台,那么,我们就不能通过先用更好的数据平台来得到更好的设计安全.或者,我们能够选择的数据库平台中没有足够好的平台能够满足要求,那么,我们就需要从另外的角度来解决这个问题了.
在前面,我们已经通过测试用例来测试一些数据库元素,我们通过它们来确定我们对数据库的基本了解是正确的(这些测试用例被保留下来了).必要的时候,我们可以修改数据库结构来使这些测试用例更好的运行.
这些测试用便访问了很多数据.那么,是否有什么数据是这些测试用例使用得最多的呢?
在设计时,我们的测试用例模拟了一些可以预见的数据方问方式,我们的用例保证了这些方式在后续的程序开发和软件运行中能够正确的被运行.那么,事实上使用的数据是否仅仅按照这些用例所涵盖的方法来使用数据呢?
显然,答案是否定的.
但是,不必为这事太担心.在快速开发模式里,除了用测试用例引导开发过程是一个很好的主意外,还有一个观点:重构.
重构是指:在开发到进行到一定的阶段后,我们需要重新来组织程个系统,以便它更好的运行.
那么,在初期,我们所做的工作有什么会被保留下来?
一些实际的代码,一些数据之间的关系.实际代码将被放在新的类里,而不是临时随意建立的诸如“readdata”这样的表单方法里.重构不是一次大修改,它是一个新的项目----之前我们所做的那个项目,仅是这个项目的一个草案.当然,这个草案已经具有了很高的可行度了.
由此可见,我们不必为最初的系统制定很严格的效率要求.
那么,我们可以在程序里加入一些处理,来记录各程操作,如,对数据表的方问频度,对数据表的占用时间等等等等.
当需要进行重构之时,这些数据可以让我们了解到哪些数据更多的被访问,哪些则是比较少的.对于那些使用频率高的数据,我们在重新设计数据库时,需要重点考虑----它们就是我们这里所说的核心数据.
一般情况下,一个数据库里会有很少的一些数据会被很频繁的使用,它们可能只占整个数据库内容的20%,但几乎95%的数据访问操作里都会用到它们中的一部分.这些,我们只需要对访问数据库的那些SQL语句进行语法分析就能得到(还有各种语句的使用次数).
进一步,我们需要对这些数据进行分类.
它们需要被分为访问频繁型,更新频繁型以及引用频繁型.这三种类型可能会有一定的交叉.
访问频繁:也许,一个经常进入/退出的系统中,用户权限表就会成为访问频繁型的数据.一些高权限控制要求的系统就是需要经常访问这样的数据.
更新频繁:MIS系统里的日统计类的数据表中的数据显然属于这类.在非核心数据中,操作Log也属于更新频繁类型的数据.
引用频繁:最明显的是id和name字段.各种表里这两类字段很多,它们经常被引用,但很少会被改变.
在重新构建数据库时,我们就可以对不同类型的数据进行不同的优化.如,对引用频繁的数据建立完善的索引,对更新频繁的数据进行长度控制并减少索引.
通过对核心数据进行这样的优化,整个数据库里最常用的数据的使用效率有了明显的提高,这一点,以新的系统里将会有明显的体现.
但还有一点:稳定.
仅仅快速还不够,我们有更重要的目标.一个不能正确运行的数据库是不安全的,没人敢用它进行管理.
核心数据的确定,很大程度上减少了我们测试的强度.如果核心数据的所有类型的测试均安全通过,那么,我们就已经完成了整个测试的90%了(因为它们在整个数据调用的90%里都被使用)----前提是,我们的测试用例真实的涵盖了事实使用的情况.
由此可见,测试用例的作用在数据库设计中是很重要的一点.
下一次,我们将进一步走近测试用例,我们会先了解一些关于数据库的测试用例的建立和使用方法.
相关文章:
关闭][返回]
|
|