基于国产CPU环境的多类型数据库统一增量更新方法与流程

本发明涉及数据库技术领域，具体涉及一种基于国产CPU环境的多类型数据库统一增量更新方法。

背景技术：

近年来，国家大力扶持具有自主知识产权的全国产软硬件的发展，涌现了以国产操作系统和CPU为代表的众多具有自主知识产权的基础软硬件产品。中标麒麟系统、深度操作系统等国产操作系统生态环境日趋完善，龙芯、飞腾等具有自主知识产权的高端通用芯片蓬勃发展，技术水平达到或接近同类产品的世界先进水平。

随着国产基础软硬件的蓬勃发展，国产基础软硬件的推广和使用带来了前所未有的机遇。数据库作为生态环境中重要的一环，基于国产操作系统和CPU的环境下涌现出了多种国产数据库。

目前基于国产CPU和操作系统的全国产环境下应用生态日益完善，数据库领域涌现了多种类型数据库，包括神通数据库、金仓数据库、达梦数据库等。在全国产环境下WEB应用系统需要支持神通、达梦、金仓等多种国产数据库，以满足不同客户的需求。日常WEB应用系统迭代开发过程中，需要频繁的修改系统关联的数据库。

不同数据库间存在关键字不统一、支持的数据类型也不完全一致、SQL语句语法格式不一致、自带的函数不相同等问题。

一般的数据库开发流程为开发人员编写各种数据库的SQL语句并分别连接数据库测试，SQL测试通过后整理汇总到SQL文件中并提交SVN等版本控制系统，供开发人员间共享文件及方便后续发包人员获取升级文件。

开发人员需要学习并掌握各种国产数据库的SQL语法，针对不同数据库上编写对应的SQL语句并进行测试，并向版本控制系统提交各种数据库对应的SQL文件，供开发人员间共享文件及方便后续发包人员获取升级文件。

另外项目组开发成员的编程风格差异和数据库操作语句SQL的灵活性，导致SQL写法各异、SQL规范性较差，后续开发维护及问题定位困难。

发包人员需要从版本控制系统检出不同数据库对应的SQL文件，根据要发送的需求编号整理SQL文件并打包发给现场升级人员, 需要SQL执行顺序的正确性。现场升级人员需要提前备份每个待升级数据库，根据数据库类型，选择要执行的SQL并关注每条SQL执行结果。

另外开发人员还需要关注SQL语句执行顺序的正确性等。如果将升级数据库的SQL汇总到文件中，随着时间的推移，易出现文件目录复杂的问题，SQL文件不方便浏览和信息查找，增加了开发人员的维护、发包人员数据库更新文件的打包和升级人员的问题定位的困难。

当项目现场需要一次升级多个需求或者升级历史需求时，数据库文件检出繁琐、数据库文件整理易出错。后续项目需要支持新的数据库时，为了保证功能的完整性，需要开发人员学习并掌握新的数据库语法格式等，为新数据库增加新的SQL文件目录，修改历史SQL适配新的数据库，将修改后的SQL文件放到新增的SQL文件目录下。

另外将SQL汇总到文件中目录复杂，SQL文件不方便浏览和信息查找，增加了后续维护及问题定位的困难。一次性更新大量需求时，数据库改动较大，需要维护大量的SQL文件，由于SQL数量多、SQL关联性强，SQL文件整理极其复杂。

当批量更新需求时，需求编号集合关联的SQL文件多,数据库改动大, SQL依赖及关联性强，SQL文件整理极其复杂、易出错。当某个历史需求存在BUG被REOPEN时或者之前漏更某个模块时，需要向项目发送历史需求。由于难以通过SQL文件查看某个数据库表的历史需求修改，当更新历史需求集合时，易出现漏更或者出现旧数据库表结构、旧表数据等错误覆盖项目现场表结构及数据。

技术实现要素：

本发明要解决的技术问题是：本发明针对以上问题，提供一种基于国产CPU环境的多类型数据库统一增量更新方法。

通过应用数据库增量更新方法，开发人员只需要按照提交规范修改数据库XML文件，不再需要关注各种数据库SQL语法、维护复杂的SQL目录。通过使用XML数据库文件，增加了升级文件的可读性、维护性，通过数据库XML文件可以方便的查看某个数据库元素的全部的历史变更。后续数据库升级文件打包，方法根据需求编号集合自动检出并处理数据库XML文件并自动打包，现场升级人员只需获取升级包，使用方法提供的管理平台，输入数据库信息并选择升级包文件，方法自动备份数据库，分析XML文件并生成符合待升级数据库语法的SQL语句，实现数据库增量更新，简化了升级过程，升级出现问题时可根据备份文件自动恢复。

本发明所采用的技术方案为：

基于国产CPU环境的多类型数据库统一增量更新方法，所述方法根据输入的数据库信息，包括IP地址、端口号、实例名、用户名、密码，连接基准数据库，导出通用的数据库XML描述文件，作为基准XML数据库描述文件，记录了数据库的表、数据、视图；

在此基准XML数据库描述文件上进行修改，完成对数据库的增量更新。

所述方法内容还包括：

基于基准XML数据库描述文件完成对其他数据库的部署、阶段更新、按照需求编号集合更新。

所述数据库XML描述文件分目录按模块组织数据库表结构、表数据、视图，包括目录存放类型转换文件、模块定义文件、模块文件、视图文件，其中：

目录存放类型转换文件中定义了国产数据库数据类型和XML数据库类型的转换关系，屏蔽不同数据库的数据类型差异；

模块定义文件定义了模块与数据库的表的对应关系，方法可以根据此文件生成各个模块目录，分别存放每个模块下的表及数据；

模块文件包括该模块相关的表结构XML文件及表数据XML文件；

每个模块下的表结构XML文件中包含该模块相关的所有表信息。

所述数据库的表作为一个XML元素，其中表名、表备注信息存储在XML元素的属性值中，表字段、表索引、表约束作为XML元素的子元素，记录了表基本信息、表字段信息、表索引信息、主键外键表约束信息，其中：

表字段信息记录了表的字段名、字段类型、是否空、默认值，每个信息作为该字段元素的一个属性；

表索引信息记录了表上的索引信息，包括索引名、索引字段；

主键表约束信息记录了表上主键信息，每个主键的名称、字段；

外键表约束信息记录了每个外键的名称、字段及关联的表名、字段名。

所述方法在XML元素中支持“修改类型”、“需求编号”、“历史需求”、“关联需求”、“序列号”属性值，通过在表字段信息、表索引信息、主键外键表约束信息的元素下增加子元素，进一步记录表结构的修改；

每个子元素对应一次修改操作，用于记录一次数据库表结构变更。

所述表数据XML文件，记录了表中的数据操作，表数据修改支持插入、删除、更新操作，其中：

每个XML元素记录了一个数据更新操作，一个数据更新操作能够针对修改数据库一条记录或者多条记录。

所述方法还包括：

XML文件修改规范，表数据、表结构按照约定的XML文件修改规范修改。

所述表数据、表结构的修改通过确认待修改的表或数据所在的模块，在该模块目录下修改表结构文件或表数据库文件；针对每个修改，XML元素需要增加“修改类型”、“需求编号”、“关联需求编号”、“版本号”，其中：

修改类型支持add、alter、delete，描述了对该XML元素的修改类型；

需求编号记录了本次修改对应的需求编号，便于后期根据需求编号获取XML文件中XML元素的修改；

开发人员修改完毕后，将修改后的数据库XML文件提交到版本控制系统。

所述方法通过表数据XML文件语法正确性测试及XML元素修改规范性测，测试表数据XML文件的正确性。

所述方法还包括数据库的升级，内容包括：

根据输入的需求编号集合，首先分析XML数据库文件，逐个校验XML文件的正确性，依次分析XML文件中的XML元素，校验是否符合XML修改规范；

逐个分析每个XML文件，根据需求编号集合查找XML修改内容，保留XML文件中的修改内容，删掉没有修改的XML元素；

将XML描述XML文件打包成数据库升级包。

本发明的有益效果为：

本发明方法简化开发人员数据库维护操作并提升SQL的规范性：开发人员无需关注具体的数据库，只需要按照修改规范修改XML文件，并提交管控平台。后续项目需要支持一个新的国产数据库时，只需增加适配新数据库，开发人员无需关注新的数据库SQL语法。相对开发人员提交的SQL，工具根据XML数据库文件生成的SQL更加规范。

简化打包发包流程：发包人员和升级人员无需关注复杂的SQL目录，整理汇总需求相关的SQL语句。根据要检出的需求编号，自动从SVN等版本控制系统检出数据库XML文件，逐个分析XML文件，获取数据库修改内容，打包成数据库升级包，发送升级包给项目实施人员。

简化实施升级数据库的流程：实施人员在本发明提供的管理平台输入数据库信息并选择升级包，自动远程备份数据库，根据要升级的数据库类型，自动生成并依次执行SQL语句，并记录升级详细日志，方便问题定位以及对失败进行修复，避免手动升级过程中出现的问题。

附图说明

图1为表结构xsd模型结构图；

图2为表字段xsd模型结构图；

图3为表主键xsd模型结构图；

图4为表索引xsd模型结构图；

图5为表外键xsd模型结构图；

图6为视图xsd模型结构图；

图7为表数据xsd模型结构图；

图8为表修改xsd模型结构图（以对PUB_OPERATION_TYPE表操作为例）；

其中，xsd，XML Schema语言，描述了XML文档的结构。

具体实施方式

下面根据说明书附图，结合具体实施方式对本发明进一步说明：

基于国产CPU环境的多类型数据库统一增量更新方法，所述方法根据输入的数据库信息，包括IP地址、端口号、实例名、用户名、密码，连接基准数据库，导出通用的数据库XML描述文件，作为基准XML数据库描述文件，记录了数据库的表、数据、视图等。

开发人员后续在此基准XML数据库描述文件上进行修改，完成对数据库的增量更新。

所述方法内容还包括：

基于基准XML数据库描述文件完成对其他数据库的部署、阶段更新、按照需求编号集合更新等。

如图1、6所示，所述数据库XML描述文件分目录按模块组织数据库表结构、表数据、视图，包括目录存放类型转换文件、模块定义文件、模块文件、视图文件，其中：

目录存放类型转换文件中定义了国产数据库数据类型和XML数据库类型的转换关系，屏蔽不同数据库的数据类型差异；

模块定义文件定义了模块与数据库的表的对应关系，方法可以根据此文件生成各个模块目录，分别存放每个模块下的表及数据；

模块文件包括该模块相关的表结构XML文件及表数据XML文件；

每个模块下的表结构XML文件中包含该模块相关的所有表信息。

所述数据库的表作为一个XML元素，其中表名、表备注等信息存储在XML元素的属性值中，表字段、表索引、表约束等作为XML元素的子元素，记录了表基本信息、表字段信息、表索引信息、主键外键等表约束信息，其中：

如图2所示，表字段信息记录了表的字段名、字段类型、是否空、默认值等，每个信息作为该字段元素的一个属性；

如图4所示，表索引信息记录了表上的索引信息，包括索引名、索引字段等；

如图3所示，主键表约束信息记录了表上主键信息，每个主键的名称、字段；

如图5所示，外键表约束信息记录了每个外键的名称、字段及关联的表名、字段名。

所述方法在XML元素中支持“修改类型”、“需求编号”、“历史需求”、“关联需求”、“序列号”等属性值，通过在表字段信息、表索引信息、主键外键表约束信息的元素下增加子元素，进一步记录表结构的修改；

每个子元素对应一次修改操作，用于记录一次数据库表结构变更。

所述表数据XML文件，记录了表中的数据操作，表数据修改支持插入、删除、更新等操作，其中：

每个XML元素记录了一个数据更新操作，一个数据更新操作能够针对修改数据库一条记录或者多条记录。

XML元素属性中存放待更新字段，where子元素属性中存放条件字段。字段支持多种写法类型，包括最基本的“字段名”=“字段值”类型，同时支持子查询类型、SQL语句类型等，支持“between and”、“ not null”、“in”等语法。序列号用于保证SQL的执行顺序。

如图8所示，所述方法还包括：

XML文件修改规范，表数据、表结构按照约定的XML文件修改规范修改。

所述表数据、表结构的修改通过确认待修改的表或数据所在的模块，在该模块目录下修改表结构文件或表数据库文件；针对每个修改，XML元素需要增加“修改类型”、“需求编号”、“关联需求编号”、“版本号”等属性，其中：

修改类型支持add、alter、delete等关键字，描述了对该XML元素的修改类型；每种元素支持多种修改类型，如数据库的创建，用户的创建，表的新增、重命名、删除等，表字段的新增、删除、重命名、类型修改，视图的新增、修改、删除，索引的新增、修改、删除，约束的新增、修改、删除等；

需求编号记录了本次修改对应的需求编号，便于后期根据需求编号获取XML文件中XML元素的修改；

开发人员修改完毕后，将修改后的数据库XML文件提交到SVN等版本控制系统。

所述方法通过表数据XML文件语法正确性测试及XML元素修改规范性测，测试表数据XML文件的正确性。

通过使用方法提供管理平台，开发人员可测试XML文件的正确性、预览基于XML生成的SQL、连接测试库执行SQL验证。XML正确性测试包括表数据XML文件语法正确性测试及XML元素修改规范性测试。根据数据库类型及需求编号集合，方法可以根据数据库XML文件生成的SQL语句，开发人员可以预览方法自动生成的SQL集合。方法可连接测试库，执行每条SQL语句并依次返回每条SQL运行有无错误。

所述方法还包括数据库的升级，内容包括：

根据输入的需求编号集合，首先分析XML数据库文件，逐个校验XML文件的正确性，依次分析XML文件中的XML元素，校验是否符合XML修改规范；

逐个分析每个XML文件，根据需求编号集合查找XML修改内容，保留XML文件中的修改内容，删掉没有修改的XML元素；

将XML描述XML文件打包成数据库升级包，将数据库升级包发送到项目现场。

另外发包人员也可以在管理平台上进行升级包测试。在管理平台上输入测试数据库信息，方法连接测试库，自动生成SQL，在测试环境测试。

实施人员获取数据库升级包文件，获取项目现场升级人员输入的数据库信息和升级包文件路径，首先连接数据库所在的远程机器并执行脚本文件备份数据库，依次分析XML数据库文件，生成符合对应数据库类型的SQL语句，SQL语句、执行结果、执行过程等记录在日志文件中，并记录数据库升级日期、升级需求编号及数据库更改信息，便于问题定位，避免遗漏更新等问题；根据XML元素中“序列号”属性及内置的算法，保证SQL执行顺序的正确性；升级失败时（比如网络连接失败），支持通过备份文件，对失败进行修复。

实施方式仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。