CN107766526B

CN107766526B - 数据库访问方法、装置及系统

Info

Publication number: CN107766526B
Application number: CN201711017571.6A
Authority: CN
Inventors: 不公告发明人
Original assignee: National Clearing Center People's Bank Of China
Current assignee: National Clearing Center People's Bank Of China
Priority date: 2017-10-26
Filing date: 2017-10-26
Publication date: 2020-04-28
Anticipated expiration: 2037-10-26
Also published as: CN107766526A

Abstract

本发明提供一种数据库访问方法、装置及系统，包括：根据接收的数据库查询操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；利用结果集内部的游标机制动态从数据库服务器中获取检索数据并返回至业务系统，包括：当检索数据的数量大于结果集的容量时：多次移动结果集内部的游标至结果集尾部，触发多次数据装载操作，从数据库服务器中将相应数量的检索数据缓存到实体缓冲区中，并装载入结果集中，从结果集中返回至业务系统，其中，相应数量等于结果集的容量；实体缓冲区的容量和结果集的容量相同。该方案不用采用嵌入式SQL的方式就可以访问数据库，并且可以在进行大数据查询时减小对业务系统和数据库服务器的运行速度的影响。

Description

数据库访问方法、装置及系统

技术领域

本发明涉及数据库访问技术领域，特别涉及一种数据库访问方法、装置及系统。

背景技术

目前已投产的业务系统访问数据库均采用嵌入式SQL的方式——分别使用PROC(C语言加上SQL语言)和SQLC(嵌入式)访问ORACLE数据库及DB2数据库。嵌入式SQL使用起来较为简单，在一般应用场景下效率也较高。但随着业务系统的业务复杂度的提高，往往会导致嵌入式SQL的代码游离于业务系统的各个部分，这样一来使得设计上过于紧耦合，不易于新的业务逻辑或实现方式的扩展；二来开发成本较高，代码冗余量较大，也不易于维护。再者，当业务系统根据实际业务需求对数据库访问时，如交易系统对数据库进行查询操作时，尤其是进行大批量数据查询操作时，是一次性的从数据库服务器中获取大批量数据传输到业务系统，这样会影响数据库服务器和业务系统的运行速度。

发明内容

本发明实施例提供了一种数据库访问方法，无需采用嵌入式SQL的方式就可以访问数据库，在进行大批量数据查询时，不是一次性的将大批量数据由数据库服务器传输到业务系统，而是通过多次数据加载，可以减小对数据库服务器和业务系统的运行速度的影响。

该数据库访问方法包括：

接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；

根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；

利用结果集内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统，包括：

当检索数据的数量大于结果集的容量时：

移动结果集内部的游标，当游标移动至结果集尾部时，触发数据装载操作，从数据库服务器中将相应数量的检索数据缓存到实体缓冲区中，从实体缓冲区中提取相应数量的检索数据装载入结果集中，将装载数据后的结果集返回至业务系统，游标位置清零，重新开始移动游标，当游标再次移动至结果集尾部时，触发下一次数据装载操作，重复数据加载过程，直到所有检索数据都装载完成；

其中，相应数量等于结果集的容量；实体缓冲区的容量和结果集的容量相同。

本发明实施例提供了一种数据库访问装置，无需采用嵌入式SQL的方式就可以访问数据库，在进行大批量数据查询时，不是一次性的将大批量数据由数据库服务器传输到业务系统，而是通过多次数据加载，可以减小对数据库服务器和业务系统的运行速度的影响。

该数据库访问装置包括：条件接收模块、操作模块、数据获取及发送模块，其中，数据获取及发送模块包括结果集和实体缓冲区；

条件接收模块，用于接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；

操作模块，用于根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；

数据获取及发送模块，用于利用结果集内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统；

所述数据获取及发送模块具体用于：

当检索数据的数量大于结果集的容量时：

本发明实施例提供了一种数据库访问系统，包括：

业务系统；

如上所述的数据库访问装置；

数据库服务器。

在本发明实施例中，接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；利用结果集内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统，包括：当检索数据的数量大于结果集的容量时：多次移动结果集内部的游标至结果集尾部，触发多次数据装载操作，从数据库服务器中将相应数量的检索数据缓存到实体缓冲区中，并装载入结果集中，从结果集中返回至业务系统。该方案不用采用嵌入式SQL的方式，采用外部访问装置就可以访问数据库，并且可以在进行大批量数据查询时减小对业务系统和数据库服务器的运行速度的影响。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种数据库访问装置的一种结构框图；

图2是本发明实施例提供的一种数据库访问装置的分层设计结构示意图；

图3是本发明实施例提供的一种条件接收模块的接收及输出形式示意图；

图4是本发明实施例提供的一种EntityBuffer存储的数据结构示意图；

图5是本发明实施例提供的一种结果集装载和提取数据流程图；

图6是本发明实施提供的一种数据库访问方法流程图；

图7是本发明实施例提供的一种数据库访问系统的一种结构框图；

图8是本发明实施例提供的一种逐笔插入不含LOB字段记录的效果图(访问ORACLE数据库)；

图9是本发明实施例提供的一种批量插入不含LOB字段记录的效果图(访问ORACLE数据库)；

图10是本发明实施例提供的一种逐笔插入含LOB字段记录的效果图(访问ORACLE数据库)；

图11是本发明实施例提供的一种批量插入含LOB字段的记录的效果图(访问ORACLE数据库)；

图12是本发明实施例提供的一种逐笔删除不含LOB字段记录的效果图(访问ORACLE数据库)；

图13是本发明实施例提供的一种批量删除不含LOB字段记录的效果图(访问ORACLE数据库)；

图14是本发明实施例提供的一种逐笔删除含LOB记录的效果图(访问ORACLE数据库)；

图15是本发明实施例提供的一种批量删除含LOB字段记录的效果图(访问ORACLE数据库)；

图16是本发明实施例提供的一种逐笔更新记录的非LOB字段的效果图(访问ORACLE数据库)；

图17是本发明实施例提供的一种批量更新记录的非LOB字段的效果图(访问ORACLE数据库)；

图18是本发明实施例提供的一种逐笔更新记录的LOB字段的效果图(访问ORACLE数据库)；

图19是本发明实施例提供的一种批量更新记录的LOB字段的效果图(访问ORACLE数据库)；

图20是本发明实施例提供的一种逐笔查询不含LOB字段记录的效果图(访问ORACLE数据库)；

图21是本发明实施例提供的一种批量查询不含LOB字段记录的效果图(访问ORACLE数据库)；

图22是本发明实施例提供的一种逐笔查询含LOB字段记录的效果图(访问ORACLE数据库)；

图23是本发明实施例提供的一种批量查询含LOB字段记录的效果图(访问ORACLE数据库)；

图24是本发明实施例提供的一种逐笔插入不含LOB字段记录的效果图(访问DB2数据库)；

图25是本发明实施例提供的一种批量插入不含LOB字段记录的效果图(访问DB2数据库)；

图26是本发明实施例提供的一种逐笔插入含LOB字段记录的效果图(访问DB2数据库)；

图27是本发明实施例提供的一种批量插入含LOB字段记录的效果图(访问DB2数据库)；

图28是本发明实施例提供的一种逐笔删除不含LOB字段记录的效果图(访问DB2数据库)；

图29是本发明实施例提供的一种批量删除不含LOB字段记录的效果图(访问DB2数据库)；

图30是本发明实施例提供的一种逐笔删除含LOB字段记录的效果图(访问DB2数据库)；

图31是本发明实施例提供的一种批量删除含LOB字段记录的效果图(访问DB2数据库)；

图32是本发明实施例提供的一种逐笔更新记录的非LOB字段的效果图(访问DB2数据库)；

图33是本发明实施例提供的一种批量更新记录的非LOB字段的效果图(访问DB2数据库)；

图34是本发明实施例提供的一种逐笔更新记录的LOB字段的效果图(访问DB2数据库)；

图35是本发明实施例提供的一种批量更新记录的LOB字段的效果图(访问DB2数据库)；

图36是本发明实施例提供的一种逐笔查询不含LOB字段记录的效果图(访问DB2数据库)；

图37是本发明实施例提供的一种批量查询不含LOB字段记录的效果图(访问DB2数据库)；

图38是本发明实施例提供的一种逐笔查询含LOB字段记录的效果图(访问DB2数据库)；

图39是本发明实施例提供的一种批量查询含LOB字段记录的效果图(访问DB2数据库)。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有的，针对业务系统采用嵌入式SQL的方式访问数据库存在的问题，在CICM原型项目研发的初始阶段曾尝试对数据库访问操作进行封装，实现了分层集中——即将每张表的所有数据库操作集中至一个对应的DATA类中，该DATA类的实现仍采用PROC的方式(CICM原型项目使用的是ORACLE数据库)。这样的好处在于将可能游离在整个项目中的数据库访问操作集中到了一起，有利于管理和维护。但在使用过程中还是出现了一些亟需解决的问题：比如(1)代码复用粒度不够，每个表的数据库操作类中还是混杂了一定的业务逻辑(就是处理数据的逻辑)，针对不同的业务级需求往往需要添加多个访问数据库的方法，不便于使用，导致后期有些服务为求方便干脆还是在自己的代码中直接嵌入了数据库访问代码；(2)开发及维护数据库操作类本身也占用了较长的项目周期，添加新表时需开发相应的类。因此需要继续寻求进一步对数据库操作进行封装的解决方案。

目前，JAVA领域对数据库访问层的封装已发展比较完备，如Hibernate、iBatis、JPA等，均实现了关系数据库中的记录与内存中的实体对象间的自动化映射(ORM，ObjectRelational Mapping)。这样，上层应用仅需与实体对象交互，至于实体对象如何被持久化(包括实体对象与数据库记录的对应关系、数据类型转换、存放在什么样的数据库中等)均不必关心。对数据持久化的托管，使开发人员能专注于系统业务逻辑的研发，也极大地提高了开发效率。在C/C++领域，也有一些效仿Hibernate的开源项目，不过没有一款业界较为通用的成熟的ORM框架。

针对上述现有技术中存在的问题，本发明提出了一种数据库访问方法、装置及系统，借鉴了Hibernate等ORM框架的一些实现理念，并结合了目前业务系统对数据库访问的实际业务需求(如交易系统将数据库事务托管给CICS，查询操作居多，存在较多的数据库批量操作等)做了一定的定制。

图1是本发明实施例的数据库访问装置的一种结构框图，如图1所示，该数据库访问装置包括：条件接收模块101、操作模块102、数据获取及发送模块103，其中，数据获取及发送模块103包括结果集1031和实体缓冲区(EntityBuffer)1032；

所述条件接收模块101用于：接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；

所述操作模块102用于：根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集1031；

所述数据获取及发送模块103用于：利用结果集1031内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统；

所述数据获取及发送模块103具体用于：

当检索数据的数量大于结果集的容量时：

移动结果集1031内部的游标，当游标移动至结果集1031尾部时，触发数据装载操作，从数据库服务器中将相应数量的检索数据缓存到实体缓冲区1032中，从实体缓冲区1032中提取相应数量的检索数据装载入结果集1031中，将装载数据后的结果集1031返回至业务系统，游标位置清零，重新开始移动游标，当游标再次移动至结果集1031尾部时，触发下一次数据装载操作，重复数据加载过程，直到所有检索数据都装载完成；

其中，相应数量等于结果集1031的容量；实体缓冲区1032的容量和结果集1031的容量相同。

其中，实体缓冲区中按照如下方式缓存检索数据：

所述检索数据为多条查询记录，每条查询记录包含多个字段；

所述实体缓冲区为每条查询记录中的每个字段分别设置缓冲区；

当查询记录中不包含LOB字段时，实体缓冲区的容量大小为可容纳的查询记录条数和每个查询记录包含的多个字段所占字节数的乘积；

当查询记录中包含LOB字段时，实体缓冲区中存放的是指向查询记录对应的LOB字符串空间的指针。

下面从功能方面对各模块进行说明。

具体实施时，所述条件接收模块101具体用于：

采用结构化的查询接口或原生SQL访问接口接收业务系统输入的数据库访问操作条件；

所述操作模块102具体用于：

将采用结构化的查询接口或原生SQL访问接口输入的数据库访问操作条件进行解析，获得以SQL串和占位符列表形式表示的数据库访问操作条件，通过数据访问对象接口，根据SQL串和占位符列表形式表示的数据库访问操作条件访问数据库服务器。

具体实施时，所述操作模块102还用于：在接收业务系统输入的数据库访问操作条件之前，与数据库服务器建立连接；

所述操作模块102具体用于：

根据业务系统所使用的数据库类型，利用配置文件104中的数据访问配置信息，从数据驱动存储器105中自动选择对应的数据库驱动程序，与对应的数据库服务器建立连接；

其中，数据访问配置信息包括使用的数据库类型信息、数据库操作实现方式信息和数据库连接方式信息；数据驱动存储器105中存储有多种数据库驱动程序。

所述操作模块102还用于：在将检索数据返回至业务系统之后，销毁与数据库服务器的连接。

具体实施时，所述配置文件104中还包括实体映射配置信息，其中，实体映射配置信息包括数据库访问操作涉及到的数据库表信息、和数据库表中的字段属性信息；

所述操作模块102具体用于：

根据数据库访问操作条件，利用配置文件104中的实体映射配置信息访问数据库服务器；

所述数据获取及发送模块103具体用于：

根据配置文件中的实体映射配置信息，将所述查询记录映射成实体类文件返回至业务系统。

具体实施时，所述数据获取及发送模块103还用于：

将所述查询记录中指定字段的值输出至预设的变量中，将所述变量输出至业务系统。

具体实施时，所述数据库访问操作条件还包括数据库增加数据操作条件、数据库删减数据操作条件、数据库更新数据操作条件中的其中之一或多个；

所述操作模块102还用于：

根据数据库增加数据操作条件、数据库删减数据操作条件、数据库更新数据操作条件中的其中之一或多个访问数据库服务器，获得相应的操作结果；将所述操作结果返回至业务系统；

所述操作结果为操作成功信息或操作失败信息。

下面从装置整体和所涉及的程序及其执行方面来详细描述本发明装置。

具体实施时，本发明装置采用分层设计，自上往下依次是应用接口层、实体管理层和数据驱动层，如图2所示：

具体的，应用接口层主要分为输入、输出和控制三类，上层业务应用通过条件接收模块101设置数据库操作条件，然后通过数据库访问对象传入条件，对于检索操作，可通过结果集获取输出。此外，在首次加载时需要将配置文件104信息写入共享内存，供其他模块读取。

其中，条件接收模块101一方面对上层应用提供不同的检索条件录入方式(这里的检索条件涉及到Select、Delete以及Update操作)，包括结构化查询以及原生SQL的方式；另一方面则向操作模块102统一输出包含占位符的标准SQL语句以及占位符信息列表，如图3所示.

在实现上，条件接收模块101中所有成员均实现统一的接口，即输出SQL串和占位符列表，至于接手上层应用的输入方式则不作限制。下面分别对于目前提供的这两种检索条件录入方式分别进行简要介绍。

(一)结构化检索条件

所谓结构化检索条件，是指将原来SQL串中的各个组成部分按照语义分解开来，分别进行设置，而不用拼写SQL串。比如对于查询操作，应用可以通过Select函数设置要查询的属性，然后通过Where函数设置一系列查询条件即可，类CDataCriteria可以将这些信息按特定的次序组装成SQL串。

结构化检索条件的示例如下：

从示例中可以看出，使用结构化检索条件时需要用到两个类：CDataCriteria类和CRestriction类。CDataCriteria类包含了一组条件容器，可以分别往每个容器中添加对应的条件项；而条件项统一由CRestriction类生成，这是一个工厂类，提供了常用的数据库操作条件函数。

结构化检索条件处理涉及到类分为以下三种：

1)用于表示单个条件元素的类：

a)CSelection类用于设置单个查询元素，可以是某个字段或者针对一个字段的统计函数等；

b)CRegulation类用于设置分组及排序元素；

c)CCondition类设置单个检索条件元素，可用于where子句、set子句以及having子句中。

这些类均实现了ISqlAdaptable接口，该接口可以将结构化的元素转为对应的SQL语句片段。CCondition类还实现了ICondition接口，该接口用于输出条件元素中包含的占位符信息——因为条件元素包含字段名和对应的条件值，而在输出的SQL片段中，条件值被替换为占位符，因此需要将占位符对应的值等信息一并输出。

2)用于表示条件容器的类：

条件容器中可存放多个实现了ISqlAdaptable接口的条件元素，而条件容器本身也可是输出成一个SQL片段——即将其中存放的条件元素转换成的SQL片段按某种方式进行组织后再进行输出。

CSqlContainer类是条件容器的抽象基类，统一定义了往容器中添加元素以及输出SQL语句片段的方法，而派生类需实现其中的GetPrefix、GetPostfix、GetSep方法——这些方法定义了如何组织容器中条件元素。

派生容器类中的CConditionContainer类专门用于存放检索条件元素，该类也需实现ICondition接口——将存放的条件元素的占位符信息汇聚在一起输出。条件元素可以按照AND方式或者OR方式进行组合，因此派生出了CAndContainer和COrContainer两个类，分别代表两类组合条件。需要说明的是，由于容器类本身实现了ISqlAdaptable接口，因此组合条件也可以作为条件元素放入CConditionContainer中。

标准的SQL语句分解后可分为6个子块，这些子块中均可以添加一个或多个元素，分别对应6个容器类：CSelectionContainer、CSetContainer、CWhereContainer、COrderByContainer、CGroupContainer、CHavingContainer。其中CWhereContainer/CHavingContainer/CSetContainer均用于放置条件元素，而前两者在处理多个条件元素时，默认按照AND方式进行连接。

3)辅助类

CDataCriteria类和CRestriction类是为了便于外部应用调用而设置的，前者是6类标准容器的组合，可以分别往各个容器中添加元素；而后者则通过一系列封装函数创建条件元素——包括单个条件以及组合条件。

结构化检索的优点在于：(1)应用开发人员不需直接接触SQL，降低了开发门槛，提高了效率；(2)使应用的数据库可移植性增强，结构化检索条件对与数据库类型相关的特化操作进行了封装并提供统一的接口函数，这样在变化底层使用的数据库时，上层应用不需要做变更。比如对于查询加锁的操作，在Orale数据库中直接使用For Update即可，而在DB2中一般需要指定锁的类型，如对检索记录加行级锁为For Update With RS。

结构化检索的缺点也比较明显：(1)对于习惯了SQL的开发人员可能反而使代码不够直观；(2)不支持某些数据库特有的函数；(3)对于复杂查询，自动生成的SQL串效率可能不够高。因此，在某些使用情形下，还需要原生SQL方式的支持。

(二)原生SQL检索

对于上层应用传入的原生SQL串，通过CStatement类进行封装。传入的SQL串如果包含了占位符，应用还需为占位符进行赋值。由于不需进行SQL串的拼接，效率上较优。不过，该类不会对传入的SQL串做语法检查，SQL串本身的正确性需由应用保证。

其中，数据库访问对象CEasyDAO类为上层应用提供了访问数据库的API(应用程序接口API)，包括增删改查等函数。CEaysDAO接受业务系统输入的数据库访问操作条件，利用操作模块(也可称为实体管理器)CEntityManager完成对数据库的操作。对于查询操作，返回的结果保存在结果集CResultSet类的实例中。如果操作失败，错误信息保存在CSqlInfo对象中，应用可检查具体错误原因。

其中，配置文件104中包含了数据访问配置信息和实体映射配置信息两部分。

(1)数据访问配置信息包括：

(11)使用的数据库类型信息、数据库操作实现方式信息、数据库连接方式信息(XA环境或非XA环境)——用来选择底层数据库访问驱动程序；

(12)数据源配置信息，包括数据源实例名、用户名、密码、Schema等(对于XA环境，无需配置此类信息)。Schema是用于描述和规范XML文档的逻辑结构的一种语言，它最大的作用就是验证XML文件逻辑结构的正确性。可以理解成与DTD(文档类型定义)功能差不多，但是Schema在当前的WEB开发环境下优越很多。因为它本身就是一个有效的XML文档，因而可以更直观地了解XML的结构。除此之外，Schema支持命名空间，内置多种简单和复杂的数据类型，并支持自定义数据类型。由于存在这么多的优点，所以Schema渐渐成为XML应用的统一规范。

(2)实体映射配置信息中分层定义了所有要操作的数据库表、数据库表中的字段属性(包括字段名、字段类型、字段长度等)，样例如下：

操作模块102可以提供加载配置文件和读取配置信息的功能，首次加载配置文件时会将配置信息写入业务系统中的全局共享内存，之后每次取配置信息均从业务系统中的全局共享内存共享内存中直接获取。

具体的，实体管理层负责控制对驱动的选择和调用，包括操作模块102(也可以称其为实体管理器)和结果集1031。操作模块102(实体管理器类CEntityManager)负责根据配置文件104中的设置选择要使用的数据驱动、创建及销毁数据库连接、调用驱动接口实现上层的数据库指令、事务管理、将底层的数据库错误转化为内部异常向调用模块抛出等。实体管理器采用单态模式。

通过实体管理器可以使接口层专注于与上层业务应用交互，而将数据库应用相关特有的操作(数据库连接以及事务的维护等)进行了集中。

结果集1031是个比较特殊的模块，它仅与查询操作相关联。一方面结果集属于接口层部分，被业务系统直接使用来获取检索结果，另一方面由于结果集内部采用游标机制动态从数据库中获取记录，因此又需要直接调用数据驱动层的接口。结果集中保存了数据库驱动程序在执行查询SQL时的上下文，并通过实体缓冲区(EntityBuffer)与数据驱动层交互。数据驱动层直接向EntityBuffer中输出检索记录，然后结果集从中取出数据进行封装并向上层应用反馈。

EntityBuffer是一块堆上的内存区域，该缓冲区一方面被底层数据库驱动程序用来缓存从数据库服务器检索得到的记录数据，另一方面则被结果集调用，直接对其中的数据进行重新解析和封装，并向上层应用返回。每个EntityBuffer在创建时指定其容量N——最多可容纳的记录数。其数据结构如图4所示：

EntityBuffer中为每个检索的字段分别设置缓冲区。对于非LOB字段，对应的缓冲区是一块连续的内存区域，由于缓冲区能容纳的记录数是固定的，但每个输出字段的大小可能不一样，因此缓冲区的大小也可能不尽相同(缓冲区大小＝N*输出字段所占字节数)；而对于LOB字段，由于对应的字符串较大，缓冲区中存放的只是指向堆上这段字符串空间的指针。

结果集对上层应用提供顺序移动游标以及获取当前记录的接口，封装了从数据库服务器获取数据至应用程序内存的整个过程——包括两个阶段：数据装载阶段和数据提取阶段。如图5所示：

查询API函数在完成SQL执行过程后返回一个结果集对象，但此时其中并不包含任何数据记录。直到业务系统首次移动结果集的游标时，结果集对象才会开始装载数据。结果集每次装载的数据量有限，当检索记录数目较大时，会导致多次数据装载的过程——当应用移动游标至缓存的数据末尾时，触发下一次数据装载。每个结果集可以设定最大的检索记录数，默认不做限制。当从数据库服务器中获取完所有的检索结果或已获取的检索记录数达到设定的最大值时，游标失效。

每个结果集对象包含一个EntityBuffer对象用来装载数据，以及一个语句执行上下文对象——该对象由底层数据库驱动程序返回，以便后续可通过此上下文对象继续从数据库中检索数据。结果集类CResultset的实现机制不同，对于访问不同类型的数据库，甚至访问同一种数据库不同的实现方式，执行SQL语句时所需要保存的上下文内容都不一样，因此定义了语句执行上下文基类CStmtContext。这是一个抽象类，其中定义了上下文派生类所必须实现的接口。本发明装置中针对使用OCI方式访问Oracle数据库以及使用CLI方式访问DB2数据库均提供了各自的上下文类型。

从结果集中获取数据的方式有多种，可以直接将指定的检索字段值输出至变量string、int、double中，也可以将当前的检索记录映射至一个实体对象中。检索记录存放在EntityBuffer中(假设其位置为i)，在映射第一阶段，需要遍历EntityBuffer中所有字段缓冲区，以字段名作为键，指向缓冲区中第i个元素的指针为值，放入一个CPtrEntity对象中；第二阶段则是以CPtrEntity对象作为参数调用表实体类的FromGenlEntity函数，在该函数体内，每个实体类根据自己所包含的属性名从CPtrEntity对象中获取对应的值，并为相应的成员变量赋值。

其中，数据驱动层为数据驱动存储器104，其中存储有多种数据库驱动程序。所有驱动程序均实现了相同的接口，可往其中添加新的驱动以支持其他数据库类型，针对同一款数据库也可以提供多种驱动实现(比如XA环境下与非XA(就是X/Open DTP定义的交易中间件与数据库之间的接口规范，即接口函数，交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等)环境下的版本)。业务系统应用根据实际使用的数据库类型选取合适的驱动程序，当业务系统应用的数据库需要移植时，只需通过配置新的驱动即可，业务系统应用本身不需要进行变更。

数据库驱动类继承于抽象基类CDatabaseAccessTool，对外提供统一的接口，基类CDatabaseAccessTool中定义了四类方法：

(1)数据库连接管理类：如Connect和Disconnect方法；

(2)事务管理类：如Commit和Rollback方法；

(3)操作执行类：如ExecQuery执行查询操作，ExecDML执行增删改操作；

(4)数据库特有操作封装类：如LockQuery方法，对于上层传递过来的标准SQL串，不同数据库实现加锁的方式也不同。

第一层派生类是与数据库类型相关，从数据库的角度提供统一的实现——比如不论采用哪种数据库访问方式，对于Oracle数据库，查询加锁的方式都是一致的。

第二层派生类则与具体访问数据库的实现方式有关，本装置中目前提供了通过OCI访问Oracle数据库以及通过CLI-ODBC访问DB2数据库的方式。

需要说明的是，所有字段值，除LOB字段外，均以字符串形式写入数据库或者从数据库中读取，目的是为了简化底层驱动程序的处理。

每一款数据库驱动其实包括两个版本——适用于XA环境与非XA环境。其实这两个版本的区别仅在于数据库连接和事务管理上：对于XA版本的驱动，数据库连接从当前XA环境中获取而不是自己创建，数据库调用结束后也不可以释放连接；而对于事务的管理应该统一交由事务中间件控制，本身不可以单方面进行递交或回滚。

综上所述，本发明装置是一套AIX平台下基于C语言的轻量级ORM框架，考虑到性能需求以及应用场景(如交易系统在CICS下运行，与数据库通过XA协议相连)，具有如下优点：

(1)在保证性能的前提下通过少量的API来托管应用的数据库访问需求；

(2)可配置，减少额外的数据库访问相关的开发工作；

(3)友好方便的输入输出接口；

(4)支持多种数据库(至少包括ORACLE、DB2等)；

(5)支持在XA及非XA环境下运行。

基于同一发明构思，本发明实施例中还提供了一种数据库访问方法，如下面的实施例所述。由于数据库访问方法解决问题的原理与数据库访问装置方法相似，因此数据库访问方法的实施可以参见数据库访问装置的实施，重复之处不再赘述。

图6是本发明实施例的数据库访问方法流程图，如图3所示，该数据库访问方法包括：

步骤601：接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；

步骤602：根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；

步骤603：利用结果集内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统，包括：

当检索数据的数量大于结果集的容量时：

具体实施时，所述实体缓冲区中按照如下方式缓存检索数据：

具体实施时，接收业务系统输入的数据库访问操作条件(步骤101)，包括：

根据数据库访问操作条件访问数据库服务器，包括：

具体实施时，接收业务系统输入的数据库访问操作条件(步骤101)之前，还包括：

与数据库服务器建立连接；

与数据库服务器建立连接，包括：

根据业务系统所使用的数据库类型，利用配置文件中的数据访问配置信息，从数据驱动存储器中自动选择对应的数据库驱动程序，与对应的数据库服务器建立连接；

其中，数据访问配置信息包括使用的数据库类型信息、数据库操作实现方式信息和数据库连接方式信息；数据驱动存储器中存储有多种数据库驱动程序。

具体实施时，在将检索数据返回至业务系统(步骤103)之后，还包括：

销毁与数据库服务器的连接。

具体实施时，所述配置文件中还包括实体映射配置信息，其中，实体映射配置信息包括数据库访问操作涉及到的数据库表信息、和数据库表中的字段属性信息；

根据数据库访问操作条件访问数据库服务器(步骤102)，包括：

根据数据库访问操作条件，利用配置文件中的实体映射配置信息访问数据库服务器；

将查询记录返回至业务系统(步骤103)包括：

具体实施时，将查询记录返回至业务系统(步骤103)，还包括：

还包括：

根据数据库增加数据操作条件、数据库删减数据操作条件、数据库更新数据操作条件中的其中之一或多个访问数据库服务器，获得相应的操作结果；

将所述操作结果返回至业务系统；

所述操作结果为操作成功信息或操作失败信息。

基于同一发明构思，本发明实施例中还提供了一种数据库访问系统，包括：业务系统701、数据库访问装置702、数据库服务器703。如图7所示。该数据库访问系统还包括：实体类生成装置704，用于根据配置文件中的实体映射配置信息自动为每张数据库表生成对应的实体类文件。

本发明给出了对该数据库访问装置的性能测试实例，如下所示：

性能测试在CICS环境下进行，目前用于测试性能的案例分为8类，包括：

(1)插入含LOB字段的记录与不含LOB字段的记录；

(2)删除含LOB字段的记录与不含LOB字段的记录；

(3)更新记录的LOB字段与非LOB字段；

(4)查询含LOB字段的记录与不含LOB字段的记录；

针对每个案例分别在1000、5000、10000、20000和50000的数据量下进行测试。由于涉及到事务的递交，每个测试案例又拆分为逐笔递交事务和批量递交事务两种，共16个案例。

测试时选取了使用本发明提出的结构化检索条件、使用原生SQL以及使用嵌入式SQL(现有技术)三种实现方式进行比对，分别使用代号EasyDao、NativeSql、PROC/SQLC。

测试数据：测试涉及到两张表，分别命名为CICMODT0101和CICMODT0702，表结构如下表1所示：

表1测试数据表

录入记录的MSGID值递增，其余字段使用固定值，对于LOB字段，初始录入的字段大小为3983字节，更新后的字段大小851字节。

(一)访问Oracle数据库性能比对：

图8是逐笔插入不含LOB字段记录的效果图，图9是批量插入不含LOB字段记录的效果图。由图8和图9可知，对于不含LOB字段记录的插入，逐笔操作的情形下，PROC效率较优，使用本发明装置效率会损失一些，但总体差距不大；而对于批量递交(连续执行多条插入语句，最后一并递交)的情形，PROC效率明显占优，但此种使用情形在应用中不太常见。

图10是逐笔插入含LOB字段记录的效果图，图11是批量插入含LOB字段的记录的效果图。由图10和图11可知，两种方式下使用本发明装置效率上都占优，对于逐笔操作，性能上差距明显。

图12是逐笔删除不含LOB字段记录的效果图，图13是批量删除不含LOB字段记录的效果图。由图12和图13可知，逐笔操作三者性能近似，而批量删除由于耗时极短，很容易出现“扰动”而导致测试数据出现偏离。总体上，三者对不含LOB字段的删除操作性能基本一致。

图14是逐笔删除含LOB记录的效果图，图15是批量删除含LOB字段记录的效果图。由图14和图15可知，三者性能基本一致，对于批量删除的情形，使用本发明装置的两种方式的效率较嵌入式SQL略高。

图16是逐笔更新记录的非LOB字段的效果图，图17是批量更新记录的非LOB字段的效果图。由图16和图17可知，三者效率上基本一致。

图18是逐笔更新记录的LOB字段的效果图，图19是批量更新记录的LOB字段的效果图。由图18和图19可知，三者对LOB字段的更新效率基本一致。

图20是逐笔查询不含LOB字段记录的效果图，图21是批量查询不含LOB字段记录的效果图。由图20和图21可知，对于频繁进行结果集很小的查询(逐笔查询)操作，PROC效率较优，但使用本发明装置不会导致性能有太大的下降；对于结果集较大的批处理查询，本发明装置效率略高。

图22是逐笔查询含LOB字段记录的效果图，图23是批量查询含LOB字段记录的效果图。由图22和图23可知，对于频繁进行结果集很小的查询(逐笔查询)操作，三者性能相差不大；而对于含LOB字段的批处理查询，使用本发明装置的两种方式效率较优。

由图8-23中可以看出，对于逐笔操作，随着数据量的增大，测试耗时基本上成线性增长，平均每笔操作的耗时统计如表2所示：

表2

对于批量操作，SQL语句的执行(插入操作除外)以及事务的递交都只进行一次，因此随着数据量的增大，一般来说每笔操作的平均耗时是逐渐降低的，计算平均耗时的误差也减小。以数据量50000的案例为例，平均每笔操作的耗时统计如表3所示：

表3

总体来说，在目前的应用场景下，使用本发明装置替换嵌入式SQL访问ORACLE数据库，对大部分操作的影响不大。对于涉及到LOB字段的处理，使用本发明装置效率上则更为占优；对于非LOB字段的查询及插入操作，本发明装置在效率上目前还不及PROC，但由于该类操作一般耗时较短，所以差距并不明显。

而对于本发明装置所提供的两种检索方式，使用原生SQL在效率上要略优，对于结构化检索条件的处理还有待优化。

(二)访问DB2数据库性能比对

图24是逐笔插入不含LOB字段记录的效果图，图25是批量插入不含LOB字段记录的效果图。由图24和图25可知，三种方式执行案例的耗时随数据量递增基本成线性增长。SQLC的方式在两种情形下效率均较高，尤其对于批量插入的情形，较本发明装置提供的两种方式性能差距明显。

图26是逐笔插入含LOB字段记录的效果图，图27是批量插入含LOB字段记录的效果图。由图26和图27可知，与插入非LOB字段记录结果类似，对于含LOB字段记录插入的性能案例，SQLC效率均占优。对于批量插入的情形，本发明装置的两种方式，尤其使用结构化条件的方式，效率较低。

图28是逐笔删除不含LOB字段记录的效果图，图29是批量删除不含LOB字段记录的效果图。由图28和图29可知，三种方式效率基本一致。

图30是逐笔删除含LOB字段记录的效果图，图31是批量删除含LOB字段记录的效果图。由图30和图31可知，三种方式效率基本一致。对于批量删除的情形，由于总耗时较短，排除可能存在的“扰动”，三者性能差距并不明显。

图32是逐笔更新记录的非LOB字段的效果图，图33是批量更新记录的非LOB字段的效果图。由图32和图33可知，对于逐笔更新的情形，SQLC方式略优，使用本发明装置的两种方式与其差距不大；对于批量更新的情形，三者性能基本一致。

图34是逐笔更新记录的LOB字段的效果图，图35是批量更新记录的LOB字段的效果图。由图34和图35可知，对于逐笔更新的情形，三者的效率基本一致；对于批量更新的情形，性能差距较为明显，使用本发明装置的方式耗时约为SQLC的两倍。

图36是逐笔查询不含LOB字段记录的效果图，图37是批量查询不含LOB字段记录的效果图。由图36和图37可知，两种情形下SQLC的方式性能优势较为明显，在效率上比使用本发明装置约高一倍以上。

图38是逐笔查询含LOB字段记录的效果图，图39是批量查询含LOB字段记录的效果图。由图38和图39可知，对于LOB字段的查询，使用本发明装置相比于使用SQL的方式，性能差距不大。

由图24-39中可以看出，对于逐笔操作，平均每笔操作的耗时如表4所示：

表4

对于批量操作，以数据量20000的案例为例，平均每笔操作的耗时统计如表5所示：

表5

总体来说，使用本发明装置操作DB2数据库的性能较直接使用SQLC的方式有所下降，其中，对于数据的插入及查询尤为明显，效率下降了一倍左右。DB2数据库的驱动程序还有待优化。目前的驱动程序是使用DB2提供的CLI接口实现，一方面调用该接口的方式可能需要调整，另一方面由于CLI本身遵从ODBC规范已经对数据库操作进行了一次封装，不像Oracle数据库提供的是偏底层的OCI接口。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种数据库访问方法，其特征在于，包括：

当检索数据的数量大于结果集的容量时：

2.如权利要求1所述的数据库访问方法，其特征在于，所述实体缓冲区中按照如下方式缓存检索数据：

3.如权利要求1所述的数据库访问方法，其特征在于，接收业务系统输入的数据库访问操作条件之前，还包括：

与数据库服务器建立连接；

与数据库服务器建立连接，包括：

4.如权利要求3所述的数据库访问方法，其特征在于，在将检索数据返回至业务系统之后，还包括：

销毁与数据库服务器的连接。

5.如权利要求3所述的数据库访问方法，其特征在于，所述配置文件中还包括实体映射配置信息，其中，实体映射配置信息包括数据库访问操作涉及到的数据库表信息、和数据库表中的字段属性信息；

根据数据库访问操作条件访问数据库服务器，包括：

将查询记录返回至业务系统，包括：

6.如权利要求1或5所述的数据库访问方法，其特征在于，将查询记录返回至业务系统，还包括：

7.如权利要求1所述的数据库访问方法，其特征在于，所述数据库访问操作条件还包括数据库更新数据操作条件；

还包括：

根据数据库更新数据操作条件访问数据库服务器，获得相应的操作结果；

将所述操作结果返回至业务系统；

所述操作结果为操作成功信息或操作失败信息。

8.如权利要求1所述的数据库访问方法，其特征在于，接收业务系统输入的数据库访问操作条件，包括：

根据数据库访问操作条件访问数据库服务器，包括：

9.一种数据库访问装置，其特征在于，包括：条件接收模块、操作模块、数据获取及发送模块，其中，数据获取及发送模块包括结果集和实体缓冲区；

所述条件接收模块用于：接收业务系统输入的数据库访问操作条件，其中，数据库访问操作条件为数据库查询操作条件；

所述操作模块用于：根据数据库访问操作条件访问数据库服务器，接收数据库服务器返回的空的结果集；

所述数据获取及发送模块用于：利用结果集内部的游标机制动态从数据库服务器中获取检索数据，并将检索数据返回至业务系统；

所述数据获取及发送模块具体用于：

当检索数据的数量大于结果集的容量时：

10.如权利要求9所述的数据库访问装置，其特征在于，所述实体缓冲区中按照如下方式缓存检索数据：

11.如权利要求10所述的数据库访问装置，其特征在于，所述操作模块还用于：在接收业务系统输入的数据库访问操作条件之前，与数据库服务器建立连接；

所述操作模块具体用于：

12.如权利要求11所述的数据库访问装置，其特征在于，所述操作模块还用于：在将检索数据返回至业务系统之后，销毁与数据库服务器的连接。

13.如权利要求11所述的数据库访问装置，其特征在于，所述配置文件中还包括实体映射配置信息，其中，实体映射配置信息包括数据库访问操作涉及到的数据库表信息、和数据库表中的字段属性信息；

所述操作模块具体用于：

所述数据获取及发送模块具体用于：

14.如权利要求10或13所述的数据库访问装置，其特征在于，所述数据获取及发送模块还用于：

15.如权利要求9所述的数据库访问装置，其特征在于，所述数据库访问操作条件还包括数据库更新数据操作条件；

所述操作模块还用于：

根据数据库更新数据操作条件访问数据库服务器，获得相应的操作结果；将所述操作结果返回至业务系统；

所述操作结果为操作成功信息或操作失败信息。

16.如权利要求9所述的数据库访问装置，其特征在于，所述条件接收模块具体用于：

所述操作模块具体用于：

17.一种数据库访问系统，其特征在于，包括：

业务系统；

如权利要求9至16任一项所述的数据库访问装置；

数据库服务器。

18.如权利要求17所述的数据库访问系统，其特征在于，还包括：实体类生成装置，用于根据配置文件中的实体映射配置信息自动为每张数据库表生成对应的实体类文件。