基于 pureXML 技术的数据库表结构扩展

信息系统交付使用之初，数据库表结构的设计往往逻辑结构清晰，管理使用方便，但是当信息系统项目运行一段时间，随着业务的不断变化和增加，处理流程不断的变革，信息系统需要从前台界面到后台数据库的完善和修改，势必要对数据库表结构必须要进行扩展。我们通常的数据库扩展往往采用增加备用字段、扩展字段的内涵、增加主从表和管理表的方式，这种数据库表结构的扩展往往会带来营运的中断和操作的风险，本文通过分析常见的数据库库表结构的扩展方法中的不足，提出了几种基于 pureXML 方式的数据库表结构的扩展模式，可以成功的结束数据库扩展的技术难题。

概述

信息系统的建设往往遵循业务调研、需求分析、再进入到数据库和软件的概要设计、详细设计、代码编写等等阶段，在这个过程中数据库设计者往往根据已有的业务调研、需求分析的成果进行数据库表结构的设计，这时的数据库的设计者是通盘考虑，全局谋划所设计的数据库结构，整个库表结构逻辑清晰，管理方便并且符合 3NF 的要求。信息系统项目运行一段时间，随着业务的不断变化和增加，处理流程不断的变革，这种业务需求的驱动下，我们的软件体系也需要不断的修改和完善，这种修改和完善不仅是界面的调整和模块的增加，而且必须对数据库表结构进行必要的调整和修改。

这种项目维护期间的数据库调整和扩展，必须对数据库设计文档进行修改，对数据字典进行调整，理想的情况是文档齐备、资料完整，但实际工作中，由于设计和开发人员的责任心和对文档的轻视，每次对数据库表结构的调整都会造成数据库库表结构混乱，为今后的工作带来系统管理、维护和软件的再次修改和调整带来隐患;其次，数据库的扩展和调整中，对数据库设计者要求很高，很容易导致数据库设计中范式设计的隐患，进而造成数据库性能的急剧下降;最值得注意的是，由于数据库存储有大量的业务数据库，每次对数据库字段的修改和调整必须停机操作，从而带来运营的中断和操作的风险。特别是对于上线运行的核心业务系统，和若干 7×24 小时的业务系统，每次的数据库停机操作对营运的影响非常的巨大，而且还可能引来不良的社会影响。

为了对数据库进行有效的扩展，实际工作中往往采用预留备用字段、字段内涵扩展、增加从表扩展和增加关联表的方式进行扩展，这种扩展往往存在若干的问题：

设计之初预留备用字段带来的不足

为了减少对今后对数据库表中的字段调整，某些设计者在设计之初，根据经验对若干可能扩展的表中预留部分备用字段。预留备用字段的方式在某些程度上可以增加扩展的灵活性，但是确存在如下隐患：

预留字段的数量无法预测 , 预留 N 个还是预留 N+1，由于无法预知需要预留的数量造成扩展的不确定性;

预留字段的类型无法预测，预留字符型还是数值，无法去预测和评估;

常见在预留的扩展字段中，这些预留的扩展字段往往会破坏数据库最基本的范式要求，数据库的范式的最基本要求就是原子性和唯一性，而扩展的字段本身的定义是不明确的，这是不未确定的，也就是非原子的和非唯一的。

表结构的字段数据量不扩展，扩展若干字段的内涵

数据库的调整会带来运营的风险，部分数据库设计者为了应付数据库存储的需要，不对数据库表结构的字段的数量进行增加，而是非常“聪明”的将某个字段的内涵进行扩展，使得某些字段中同时存入 2+ 以上含义，由程序分析存入该字段的值的属性和内容。例如：某字段原定义为 VARCHAR(4)，如果存储字母开头的值，如 A001 表示意思 XX;存储数值开头的值，如 1000 表示意思 YY;还有一种方式就是采用间隔符，对字段进行扩展，例如 A001+1000 等形式。我们的数据库设计中，数据库表中的每一个字段都是单一属性，是不可再分的、原子性的，这个是数据库设计的第一范式理论，任何的数据库设计都应该遵守第一范式。这种设计不仅违反的数据库设计的第一范式理论，而且造成读取数据时需要程序进行“解码”后才能进行查询、统计等等，使得数据库的整体性能大大降低。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有