vfp 数据库集: 巨量存放,仍然快速之体会
vfp 数据库集: 巨量存放,仍然快速之体会(1)目前,对于所有的数据库,个人认为:从操作类型方面。可以分为2类。文件型数据库和服务型数据库。
前者有 access 和 vfp 数据库等,文件型磁盘存放,无平台直接使用。后者有 sql_server 和 oracle 等,基本上都借助平台
才能使用。目前常见的的使用中,前者侧重于小型局域网或单机,后者侧重于大型网络或远程服务。因为两者用途各有侧重,
所以,各自表现的性能和主要功能互不兼顾。前者操作简单容易,运行速度快,而且很容易移植和修改。
其中,vfp 数据库的特征更为突出。他不但运行速度更快,而且单表的容纳量大于 access. 因为他是受vfp直接操纵,
在众多数据库中是唯一的不需要做数据库连接,也能直通直打、直接操作的数据库。到目前为止,极易操作的性能,
在各类数据库中仍然属于第一。服务型数据库特点,容量大,共享性能高,端口连接保密性强。所以适合用于
大型网络和远程。但是,具体使用时,不能直通直打,必须作有效连接,利用较为严格的 sql 查询语句才能实现其功能,
相对的,跨数据库查询难度大,速度慢。
(2)从数据库表的容量使用特点,所有的数据库中的表也可以分为2类。有限型表和无限型表两类,这是按照数据库的
表使用时,使用者存放数据量的限度相区分,于表本身属性无关。举例说明:例如在医院his 系统中,药品目录表,
收费项目目录表,医生名表,医院科室名称表等。这些表存放记录数,伴随时间的不断过度,实际应用中,他不会无限
增加记录数的。总之,记录数据到达一定数量后,按照实际需要,不会再有多少记录条数继续添加,或者不再增加了。
呈现极限状态。这个表可以称为有限型表。我们再看另一些表:门诊和住院业务记录表,物品入库或出库表等,
这些表存放记录数,会伴随时间的不断过度,他会不断无限增加记录数的。呈现无限增长的趋势,不存在极限。
这种表可以称为无限型表。
(3)vfp 数据库集的侧重。关于有限型表,存放量和运行速度,一般遇不到多大困难,操作也容易掌握。
但是,无限型表不同,当把一类数据不断的放在一张数据表内时,当数据量达到一定程度,超大量存放数据时,
想要仍然保持快速如初的数据库操作,显然变得比较困难了。针对无限型表,数据库集开始发挥重大的作用。
由于vfp数据库是文件型数据库,利用文件型的特点,可以在很大程度上,解决vfp数据表的巨量存放记录时,
如何仍然快速实现数据库操作的问题。数据库集,针对的就是无限型数据表。
(4)vfp 数据库集的结构特点。把存放同类数据的一张无限型表,分成相同结构和字段的众多的表,有序的放在
文件夹中,文件夹也是有序的,可以层层叠加,可容纳成千上万张相同结构的表。硬盘存放文件的量本来就是巨大的。
每张表容纳数据记录,则是相对很少的。常规情况下,数据操作只是针对记录量很少的少数张表进行,大量相同结构
和字段的表,暂时都属于无关的表不需要操作。针对性的操作,使得操作速度大大加强。这个存放大量相同结构
和字段的文件型数据库的文件夹,就是一个数据库集。
数据库集,好比是一个庞大的图书馆,内部的书架好比是一个个文件夹,文件夹内又有文件夹,层层叠加,
最后的底层文件夹才包含同字段的大量文件型数据库和表。这是一个多么庞大的数据库!简直可以用阶乘计算!
数据的存放、查询、交换,在大量的同字段的库表中,只对相关的极少数文件夹内数据库进行,好比在图书馆内,
查找与存放书籍资料,按照自然法则,当然是,房间内全部图书的类型尽量相近,同书架的书籍进一步相近,
同层书籍更加相近..,步步逼近,同者相邻。我们存放资料,不可能把极其大量的全部相近的资料,都放在一本书内,
更不可能把它放在一本书的一个页面内,让这一页的纸张变得非常非常的长。数据库集的存放和查询模式,
是个同构同字段多表的集合,数据存放和查询,是地址有序的分散和集中的调合,符合自然常规法则规律。
(5)vfp数据库集的可扩充性。他是很容易扩充的,可以自动或人工方式,直接复制空库,就立刻增多数据库
的个数。只要硬盘空间容量允许,他可以一直复制下去。呈现名副其实的海量存放。同时,数据在执行存放时,
可以做到不同磁盘的同时多份存放。因此,这种数据库一般不需要人工备份,处理得当会确保数据永远不会丢失。
因为常规情况下,多微机多磁盘同时损坏几乎是不可能的。
(6)数据库集的分类。
(a)时间序列型。这是按照一定时间内设计出一张表。比如每天一张同结构表。天天自动更换新表操作。
主要侧重于,顺序时间内,定期时间内,发生的全部数据的操作。比如:2010年2月16日的仓库物品出库记录表。
可以是:\\..\e$\y2010\m02\wpck!wpck_16,他只存放该天的有关全部数据。
(b)数字序列型。这是按照数字排列构造的表。主要侧重于不定时间内,产生数据的操作。比如:医院的一个病员,
自来院就诊,直至现在的全部诊断,检查、治疗、用药方案的全部数据。由于他何时来医院,何时再来?是个不定数,
但是,他的门诊号是:000051067,那么,这张表可以是:\\..\e$\00\00\05\10\br_67.独立存放本人的全部资料。
而对于门诊号总表,即存放全部门诊号的目录表,记录不重复。可以做成数据库集。而该库集的引导表,则几乎是一个
有限型表,只记载区段。
(c)混合型。这是时间型和数字型表的混合使用。其中,时间型文件夹内,可能存在数字型文件夹,或者相互
掺杂。这要根据实际需要而设计。
(7) vfp数据库集的运行的特点。他运行的最大特点就是:以“寻址方式”为主。操作数据的时候,首先寻找的
是数据库的位址。系统存放数据时,能够自动识别,哪些数据应该放在哪些数据库类之中。查询时,只需寻找出这些
数据库表,所需数据肯定就在里面,而其他的同结构数据库里根本就没有,一概不需要操作,就可以了。
常规情况下,实现数据库集内的各种各样的数据操作,通常只是对其中一张表的操作,而且这张表内的
数据又是相对的那么少!或者对多张类似表的重复式操作。操作他,如同操作单张表一样简单。数据的存放和
修改一般只对单张或2-3张小表进行,因而快速完成。而数据查询,是写在数据库里面的固定存储过程。调用数据库集,
如同调用一张单表。巨量数据汇总时,存储过程实现一边读数,同时汇总的功能。流水作业式,
中间不会产生巨量的临时表。常规情况下,数据库集里面的全部数据,绝大部分是长期处于非活动状态,不被操作。
这一点,是与大型数据库 sql_server 或 oracle,在使用少量表做巨量存储时存在的原则区别。后者正好是相反的。
例如:数据装入:记录每天门诊业务,每天自动打开时间型库集的2张新空白表,其中还有1张备份。
同步分次方式装入该天的全部记录。 例如:查询2010年1月1日--月底的药品出库明细。寻址查找时间型库集,
抽出该月1-31的表,依次合并即可。查询该月内药品明细汇总,再加一条 select .. group by 语句。最快的,
查询某一天的明细,直接抽出这张表即可。因为数据存放时,提前已经按需要分类存放,查询时,又容易又快。
(8)vfp数据库集,存量与速度的关系。伴随整个库集的记录数量的增加,查询速度影响不大。
因为其中很多操作方式,其操作速度与整个库集的存放量无关。当整个库集的存储数据的总量远远超过sql_server
或 oracle时,与后者比较,他仍然呈现着极其快速的运行模式现象。原因是,他一直在一个或一些小表上运行。
一直是依靠“寻址方式”进行数据操作。大家都知道,目前微机的寻址功能,到底有多块!是不言而喻的!
假如,在海量的一张大表中,搜索寻找符合条件的记录的操作。后者无疑是,数据越来越多时,
无关数据作为一种累加的包袱共同参与运行之中。这个缺陷,在大型数据库里,比如:oracle中尤为突出。
而vfp数据库集没有这个包袱,无关的数据表他会自动不再访问的,因为他的查询方式,是以“寻找地址"为重点,
而不是”大表内找记录“方式。
(7)vfp数据库集与服务型数据库的联合使用。因为两者各有优势侧重,在远程大型网络中,使用大型数据库,用于
数据的接受和发送,而数据的备份存放和查询,则使用vfp数据库集。笔者的实际应用中,是让大型数据库的某些频繁
应用,交换量最多的数据库表,时刻恢复到空记录状态。可以让程序自动实现两种数据库之间的数据交换,
起到各取优势的作用。当然,这里面也要牵扯到很多问题,可以因事而定,灵活处理。..可待续..
欢迎高手多加指点! 信箱:qingfameng@