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@
有点道理
