CN107145574A - 数据库数据处理方法、装置及存储介质和电子设备 - Google Patents

数据库数据处理方法、装置及存储介质和电子设备 Download PDF

Info

Publication number
CN107145574A
CN107145574A CN201710313199.7A CN201710313199A CN107145574A CN 107145574 A CN107145574 A CN 107145574A CN 201710313199 A CN201710313199 A CN 201710313199A CN 107145574 A CN107145574 A CN 107145574A
Authority
CN
China
Prior art keywords
data
record object
tables
record
storage device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201710313199.7A
Other languages
English (en)
Inventor
陈静
朱金奇
周冬生
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hundsun Technologies Inc
Original Assignee
Hundsun Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hundsun Technologies Inc filed Critical Hundsun Technologies Inc
Priority to CN201710313199.7A priority Critical patent/CN107145574A/zh
Publication of CN107145574A publication Critical patent/CN107145574A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2282Tablespace storage structures; Management thereof

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开是关于一种数据库数据处理方法、装置及存储介质和电子设备。该方法包括:接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址;根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。本公开可以节省数据查询所花费的时间,提高数据查询效率。

Description

数据库数据处理方法、装置及存储介质和电子设备
技术领域
本公开涉及数据库技术领域,尤其涉及一种数据库数据处理方法、数据库数据处理装置以及实现该数据库数据处理方法的计算机可读存储介质和电子设备。
背景技术
目前,随着信息数据处理需求的日益增长,在一些高性能的业务处理***中,往往采用内存数据库的解决方案。由于内存数据库不使用磁盘,故节省了针对磁盘的I/O时间开销,从而能够显著地提高数据存储和查询效率。因此内存数据库的解决方案变得越来越重要。
相关技术中,目前在传统的采用内存数据库的业务处理***中,通常一个业务操作的完成需要访问多张业务表进行。例如有三张业务表TableA、TableB和TableC,一般是先从TableA中找到对应的记录进行检查或者更新等操作,再从TableB中找到对应的记录进行检查或者更新等操作,最后从TableC中找到对应的记录进行检查或者更新等操作。这样导致在业务处理过程的每一个小的步骤都要去访问所有不同业务表中的数据,且都要从各个业务表的全部记录中去查找对应的记录,查询范围过大从而使得业务处理过程耗时较多且效率低下。这进一步导致在对延时要求较高的业务处理场景中存在较大的业务处理性能问题,并且随着业务处理***中各个业务表中记录数据的大幅增加,业务处理性能会进一步受到很大的影响。
因此,有必要提供一种新的技术方案改善上述方案中存在的一个或者多个问题。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开的目的在于提供一种数据库数据处理方法、数据库数据处理装置以及实现该数据库数据处理方法的计算机可读存储介质和电子设备。进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。
本公开的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本公开的实践而习得。
根据本公开实施例的第一方面,提供一种数据库数据处理方法,所述方法包括:
接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址;
根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
本公开的一种示例性实施例中,所述数据库为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。
本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针;
所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象包括:
根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
本公开的一种示例性实施例中,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器;所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址;
所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象包括:
遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
本公开的一种示例性实施例中,所述关联容器包括唯一索引型容器和/或非唯一索引型容器。
本公开的一种示例性实施例中,所述第一数据表中每条第一记录对象包括多个所述第一存储装置。
本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址;
所述方法还包括:
根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。
本公开的一种示例性实施例中,所述第二存储装置采用指针或者关联容器。
根据本公开实施例的第二方面,提供一种数据库数据处理装置,所述装置包括:
数据获取模块,用于接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址;
第一数据查找模块,用于根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
本公开的一种示例性实施例中,所述数据库为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。
本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针;
所述第一数据查找模块,用于根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
本公开的一种示例性实施例中,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器;所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址;
所述第一数据查找模块,用于遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
本公开的一种示例性实施例中,所述关联容器包括唯一索引型容器和/或非唯一索引型容器。
本公开的一种示例性实施例中,所述第一数据表中每条第一记录对象包括多个所述第一存储装置。
本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址;
所述装置还包括:
第二数据查找模块,用于根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。
本公开的一种示例性实施例中,所述第二存储装置采用指针或者关联容器。
根据本公开实施例的第三方面,提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述任一实施例中所述数据库数据处理方法的步骤。
根据本公开实施例的第四方面,提供一种电子设备,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行上述任一实施例中所述数据库数据处理方法的步骤。
本公开的实施例提供的技术方案可以包括以下有益效果:
本公开的一种实施例中,通过上述数据库数据处理方法及装置,在一数据表中设置归属于每条记录对象的第一存储装置,该第一存储装置中记录和该数据表中的记录对象有关联关系的另一数据表中的另一记录对象的地址。这样,一方面,在查找数据时,可以根据该存储装置中记录的地址直接查找到数据,不用从各个数据表中的全部记录对象中逐一去查找,大大节省数据查询所花费的时间,提高了查询效率;另一方面,数据查询范围大大减小从而使得相应的业务处理过程效率提高,在对延时要求较高的业务处理场景中也可以提高业务处理性能,并且随着业务处理***中各个业务表中记录数据的大幅增加,业务处理性能也会在一定程度上得到提升。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1示意性示出本公开示例性实施例中数据库数据处理方法流程图;
图2示意性示出本公开示例性实施例中数据表的数据结构示意图;
图3示意性示出本公开示例性实施例中不同数据表间的关联关系示意图;
图4示意性示出本公开示例性实施例中另一数据库数据处理方法流程图;
图5示意性示出本公开示例性实施例中数据库数据处理装置示意图;
图6示意性示出本公开示例性实施例中另一数据库数据处理装置示意图;
图7示意性示出本公开示例性实施例中又一数据库数据处理装置示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。
此外,附图仅为本公开的示意性图解,并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
本示例实施方式中首先提供了一种数据库数据处理方法。参考图1中所示,该方法可以包括以下步骤:
步骤S101:接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址。
步骤S102:根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
通过上述数据库数据处理方法,一方面,在查找数据时,可以根据该第一存储装置中记录的地址直接查找到数据,不用从各个数据表中的全部记录对象中逐一去查找,大大节省数据查询所花费的时间,提高了查询效率;另一方面,数据查询范围大大减小从而使得相应的业务处理过程效率提高,在对延时要求较高的业务处理场景中也可以提高业务处理性能,并且随着业务处理***中各个业务表中记录数据的大幅增加,业务处理性能也会在一定程度上得到提升。
下面,将参考图1至图4对本示例实施方式中的上述方法的各个步骤进行更详细的说明。
在步骤S101中,接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址。
本示例实施方式中,所述预设操作请求可以是数据查询请求、数据删除请求或者数据更新请求等。所述数据库可以为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。内存数据库是将数据放在内存中直接操作的数据库。相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。另外,内存数据库是对象型的,维护开销小。本示例实施方式中示出了第一数据表和第二数据表,然而这并不用于限定本示例实施方式中的数据表的数量,任何两个或以上的数据表中每个数据表中的每条记录对象均可以设置存储装置以保存与其有关联关系的另一数据表中的记录对象的地址,从而可以缩小数据查询范围,直接查找数据减少耗时。下面将以三张数据表为例对本示例实施方式进行进一步说明。
示例性的,在一个如交易***的应用场景中,所述第一数据表可以是如表1所示的客户表,所述第二数据表可以是如表2所示的账户表。该应用场景中还可以包括如表3所示的第三数据表,即持仓表。客户表存放客户编号如ID、客户的状态以及客户姓名等其他客户信息。账户表用来存储对应的账户信息,一个客户可以有多个账户,比如做现货交易有现货交易的账号,做期货交易有期货交易的账号,同时每个账号也有对应的交易权限。持仓表用来存储客户在具体账户下对应的持仓。
表1
客户编号 客户状态 姓名 地址 手机
000001 正常交易 张三 浙江杭州 12345678911
000002 冻结 李四 浙江嘉兴 12345678912
100000 已销户 王五 湖北武汉 12345678913
表2
客户编号 交易账户 账户类型 账户权限 账户状态
000001 A00000101 现货 允许买卖 正常
000001 A00000102 期货 只能买 正常
000002 A00000201 现货 允许买卖 异常
000002 A00000202 期货 只能卖 正常
100000 A10000001 现货 允许买卖 正常
100000 A10000002 期货 只能买 正常
表3
本示例实施方式是根据业务应用场景中实体的关系把一些孤立的数据表中的记录对象相互组织起来,形成上下级的多级关联关系,从而在具体实现业务流程过程中,找到上级记录对象后可以快速地从上级记录对象的第一存储装置中获取地址查找到与上级记录对象关联的下级记录对象。下面说明上述关联关系也即所述第一存储装置建立的具体过程。
在一示例性实施例中,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针。而在另一示例性实施例中,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器。所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址。下面对该第一存储装置的建立过程作出详细说明。
参考图2~3所示,首先需要整理出业务处理过程中需要用到的所有实体,也就是对应的内存表,例如前面举例列出的客户表、账户表和持仓表。然后梳理这些实体之间的关系,并且设计关联关系。比如一个客户可能有多个账户(1个以上),可以设计客户表和账户表为一对多的关系。如果一个客户肯定只会有1个甚至没有账户,则这两个数据表的关系就是一对一的关系。
本示例性实施例中,只有当表1和表2中所有的记录对象之间均是一对一的关系时,两个表格之间的关系才是一对一。如果表1和表2之间有的记录对象之间是一对一,有的记录对象之间是一对多,则两个表格之间的关系是一对多,例如上述例举的客户表和账户表。另外,由于一个账户下面又可以有多个持仓,则账户表和持仓表也是一对多的关系。
接下来可以设计数据表的结构,本示例性实施例中是基于内存数据库的,因此在设计数据表时其实就是设计对应的结构体或者类。因此可以根据客户表Client和账户表Account的相关属性设计出对应的结构ClientClass和AccountClass。
设计数据表之间的关系,如客户表Client和账户表Account的关联关系。由于已经梳理出客户表和账户表之间是一对多的关系,则可以在客户表Client的结构ClientClass里面增加一个容器,这个容器用于存储和当前客户表Client有关联关系的所有账户表Account中的记录对象的地址,也就是存储当前某个客户下的所有账户。
示例性的,ClientClass和AccountClass结构设计可以如下:
本示例性实施例中一个数据表中的一条记录对应一个关联容器,而不是一个数据表用一个关联容器以实时更新关联容器中的内容,这样访问速度要比实时变化的快的多,因为不需要根据当前要查找的内容去实时更新关联容器中的内容。
需要说明的是,如果所述客户表Client和账户表Account在逻辑上只是一对一的关系,比如一个客户只会有一个账户,这时候在Client的结构ClientClass上只需要一个指向AccountClass中的指针,而不需要是关联容器。两个数据表之间是一对一的关系时,可采用指针,即内存表中的每条记录采用一个变量用来存储相关联的数据表中的记录的地址即可,这样比起用关联容器来存储,少了一次遍历或者按排序规则返回查询结果的操作,查找速度更快,进一步减少耗时提高效率。
根据上述原理可以依次建立好各个数据表结构之间的关联关系。至此,所有关联关系设计完成。在程序启动时候再根据设计的关系把实际的对象之间的关系进行初始化。比如客户表中的客户编号为000001的记录和账户表中客户编号为000001而交易账户为A00000101和A00000102的两条记录建立关系,也就是把这两条记录的地址***到客户表中客户编号为000001的客户记录的关联容器里。当在处理业务的过程中,先从客户表中找到客户编号为000001的客户,然后要查找该客户下的某一个账户时,就只需要从客户表中该客户记录对应的存储所述账户表中关联的交易账户的关联容器中查找到对应的那个账户,而不需要从账户表中的全部数据中去逐一查找数据,节省时间提高查询效率。
所述关联容器是指一个复杂的存储装置,其一般具有按照预设的排序规则将存储的内容进行自动排序的功能,例如客户表中的客户编号000001的关联容器中存储指向账户表中的交易账户A00000101和A00000102的指针,那么预先在账户表中就会定义好排序规则,例如根据资金大小、或者时间先后等等对其进行排序,类似于关系型数据库中的索引功能,有利于快速定位到要查找的交易账户。但排序规则不是必须的,也可以没有排序规则,这样在查找时就是遍历整个关联容器,定位速度稍微慢一些,但也可以在一定程度上相比相关技术提高查询效率。
在步骤S102中,根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
示例性的,当所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针。相应的,所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象,即步骤S102可以包括:
步骤1021:根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
举例来说,根据一携带客户编号的数据查询请求,从客户表中找到客户编号为000001的客户,然后要查找该客户下的某一个账户时,就只需要从客户表中该客户记录对应的存储所述账户表中关联的交易账户的地址的指针所指示的地址从账户表中查找到对应的账户,如账户A00000101或者A00000102。
示例性的,当所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器。所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址。相应的,所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象,即步骤S102可以包括:
步骤1022:遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
举例来说,根据一携带客户编号的数据查询请求,从客户表中找到客户编号为000001的客户,然后要查找该客户下的某一个账户时,就只需要根据客户表中该客户记录对应的存储所述账户表中关联的交易账户的地址的关联容器中所保存的地址从所述账户表中查找到对应的账户,如账户A00000101和A00000102。再例如可以根据所述账户表中交易账户为A00000101和A00000102各自对应的关联容器中所保存的多个地址从所述持仓表中查找到各自对应的5条持仓记录,具体可参考图3所示。
在本公开的一种示例性实施例中,所述第一数据表中每条第一记录对象还可以包括多个所述第一存储装置。该多个所述第一存储装置可以是全是指针,也可以是全是关联容器,或者部分是指针而剩余部分是关联容器。
在一示例性实施例中,所述关联容器可以包括唯一索引型容器和/或非唯一索引型容器。即多个所述关联容器可以单独是唯一索引型容器或者非唯一索引型容器,也可以是同时包括唯一索引型容器和非唯一索引型容器。索引的作用是排列好次序,使得查询时可以快速找到数据。唯一索引指的是被索引的字段组合其数据在全表中唯一。如下所示,为学号建索引,其是唯一的,即无重复相同的学号。
非唯一索引指的是数据可以不唯一。
如下所示,为Score建索引,其不唯一,如98是重复的。
所述关联容器类型包括唯一索引和非唯一索引两种类型,例如客户表中的客户编号000001对应的账户类型现货和期货分别对应的交易账户为A00000101和A00000102,即交易账户不唯一。而存在另一种业务应用场景,例如一个账户类型下包括证券和期货,该客户一次性在不同市场(证券市场和期货市场)下单,建立一个任务,则如果根据任务号来查找,任务号相同的情况下,其对应的是期货和证券,即非唯一的。因此,由于业务具有不同的维度,可以根据不同的维度在一个内存表的同一条记录中可以设置多个关联容器,每一个关联容器对应一种排序规则,例如,客户表中的每条记录可以同时包括唯一索引的关联容器和非唯一索引的关联容器,用于实现不同的目的,例如唯一索引的关联容器可以用于获得细分的查找结果(查找出对应的唯一结果),而非唯一索引的关联容器可以是为了统计或者遍历的目的,而非细分查找的目的。
前述实施方式中给出了不同数据表中记录对象间一对多和一对一的情况,但实际中还可能存在记录对象间多对多的情况。在多对多的情况下,本示例实施方式中两个数据表之间可以具有正反向传递功能,即一对多时是父集数据表中有一个关联容器用来记录关联的子集的内容,但多对多的情况下,子集数据表中也有一个关联容器可以用来记录关联的父集数据表的内容。
在本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表可以包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址。示例性的,所述第二存储装置采用指针或者关联容器。该第二存储装置与所述第一存储装置相同,具体可参考前述关于第一存储装置的说明,此处不再赘述。
参考图4所示,相应的,当所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述方法还可以包括以下步骤:
步骤S103:根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。该步骤S103与上述根据所述第一存储装置在第二数据表中查找数据的过程相同或相类似,此处不再赘述。
下面再结合一个具体示例比较说明本示例实施方式中的上述方法的技术优点。假设所述交易***当前一共有10万个客户,每个客户有2个账户,每个账户下都有5条持仓。这样客户表中的记录为10万条,账户表的记录为20万条,持仓表中的记录为100万条。现有的交易处理流程如以下201~204所示:
201:交易请求下达。
202:根据请求中传入的客户编号,在客户表的10万条记录中找到对应的客户,然后检验该客户状态是否正常,正常则通过继续往下进入203。
203:根据请求中传入的客户编号和交易类型从账户表的20万条记录中找到对应的交易账户记录,然后对该交易账户状态进行检查,检查通过则继续往下进入204,否则返回错误应答,交易失败。
204:根据客户编号和上一步找到的交易账户号以及请求传入的要卖的商品编号在持仓表的100万条记录中找到对应的商品,然后对该商品数据进行校验,如果数量大于等于要卖的数量则通过继续往下交易成功,请求处理结束。
从上面的流程中可以看到当一个请求进来,业务处理过程的每一个小的步骤都要去访问不同的数据表中的数据,并且都要从这些数据表的全部记录中去查找对应的记录。这种方式存在很大的一个缺陷,一个业务做下来需要访问三张表,每次都是从数据表的全部记录中去查找对应的那条记录。例如先是从10万条记录的客户表去找到对应的客户记录,再去20万条记录的账户表去找这个客户的账户,然后再从100万条记录的持仓表去找到要卖的那个持仓。这样对延时要求较高的场景会存在较大的性能问题。并且,随着数据表中数据增大,这个业务的性能会受很大影响,比如由现在的10万客户增加到了20万客户,账户表就可能增加到了40万,持仓表就可能增加到了200万,增加了新的客户后,对原有其他客户的交易性能都会产生影响,因为整个数据表的记录增大了,也就是查询的范围扩大了。
结合参考图3所示,采用本示例实施方式中的上述方法后的交易处理流程如以下301~304所示:
301:交易请求下达。
302:根据请求中传入的客户编号,在客户表的10万条记录中找到对应的客户记录,然后检验该客户状态是否正常,正常则继续往下进入303,否则返回错误应答,交易失败。
303:根据请求传入的交易类型从找到的对应的客户记录包含的2条交易账户记录的关联容器中查找到对应的交易账户记录,然后对该交易账户状态进行检查,检查通过则继续往下进入304,否则返回错误应答,交易失败。
304:根据请求传入的要卖的商品编号在交易账户记录包含的5条持仓记录的关联容器中查找到对应的商品记录。然后对商品数据进行校验,如果数量大于等于要卖的数量则通过继续往下交易成功,请求处理结束;否则返回错误应答,交易失败。
本示例实施方式中在数据表中设置关联容器记录对象间的层次关联关系,其业务处理过程先是从10万条记录的客户表去找到对应的客户记录,在根据客户记录里面包含账户记录的容器中去查找账户记录时,容器当中只有2条记录,查找的条件也只需要业务类型即可;同样根据账户记录里面包含持仓记录的容器去查找持仓记录时,容器当中只有5条记录,查找的条件也只需要根据商品编码即可。比如由现在的10万客户增加到了20万客户,账户表就可能增加到了40万,持仓表就可能增加到了200万,增加了新的客户后,对原有其他客户的交易性能产生的影响很小,只有客户表查找的时候数据量变大了,后面容器里面的数据量都是不变的。这样使得数据请求处理时可以利用关联容器更高效地找到下一个需要使用的数据,相比于现有技术使得在一个请求处理过程中大大节约了整个业务处理的总耗时,提高了业务***处理性能。
需要说明的是,尽管在附图中以特定顺序描述了本公开中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。另外,也易于理解的是,这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。
进一步的,本示例实施方式中,还提供了一种数据库数据处理装置。参考图5中所示,装置100可以包括数据获取模块101和第一数据查找模块102。其中:
所述数据获取模块101,用于接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址。
所述第一数据查找模块102,用于根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
在本公开的一种示例性实施例中,所述数据库为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。
在本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针。相应的,所述第一数据查找模块102,用于根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
在本公开的一种示例性实施例中,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器;所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址。相应的,所述第一数据查找模块102,用于遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
在本公开的一种示例性实施例中,所述关联容器可以包括唯一索引型容器和/或非唯一索引型容器。在本公开的一种示例性实施例中,所述第一数据表中每条第一记录对象可以包括多个所述第一存储装置。
参考图6中所示,在本公开的一种示例性实施例中,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表也可以包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址。所述装置100还可以包括第二数据查找模块103,用于根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。
在本公开的一种示例性实施例中,所述第二存储装置可以采用指针或者关联容器。
关于上述实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现木公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
本示例实施方式中,还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述任一实施例中所述数据库数据处理方法的步骤。关于该数据库数据处理方法的具体步骤可参考前述方法实施例中的详细描述,此处不再赘述。
另外,本示例实施方式中,还提供了一种电子设备,该电子设备可以包括处理器和存储器。其中,所述存储器,用于存储所述处理器的可执行指令;所述处理器配置为经由执行所述可执行指令来执行上述任一实施例中所述数据库数据处理方法的步骤。关于该数据库数据处理方法的具体步骤可参考前述方法实施例中的详细描述,此处不再赘述。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
图7示出根据本公开示例实施方式中一种数据库数据处理装置400的示意图。例如,装置400可以被提供为一服务器。参照图7,装置400包括处理组件422,其进一步包括一个或多个处理器,以及由存储器432所代表的存储器资源,用于存储可由处理组件422的执行的指令,例如应用程序。存储器432中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件422被配置为执行指令,以执行上述方法。
装置400还可以包括一个电源组件426被配置为执行装置400的电源管理,一个有线或无线网络接口450被配置为将装置400连接到网络,和一个输入输出(I/O)接口458。装置400可以操作基于存储在存储器432的操作***,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM或类似。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由所附的权利要求指出。

Claims (18)

1.一种数据库数据处理方法,其特征在于,所述方法包括:
接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址;
根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
2.根据权利要求1所述方法,其特征在于,所述数据库为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。
3.根据权利要求2所述方法,其特征在于,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针;
所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象包括:
根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
4.根据权利要求2所述方法,其特征在于,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器;所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址;
所述根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象包括:
遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
5.根据权利要求4所述方法,其特征在于,所述关联容器包括唯一索引型容器和/或非唯一索引型容器。
6.根据权利要求1或2所述方法,其特征在于,所述第一数据表中每条第一记录对象包括多个所述第一存储装置。
7.根据权利要求2所述方法,其特征在于,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址;
所述方法还包括:
根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。
8.根据权利要求7所述方法,其特征在于,所述第二存储装置采用指针或者关联容器。
9.一种数据库数据处理装置,其特征在于,所述装置包括:
数据获取模块,用于接收一预设操作请求,响应所述预设操作请求以从一第一数据表中获取对应的一第一记录对象;其中,所述第一数据表包括归属于每条所述第一记录对象的一第一存储装置,所述第一存储装置用于保存和对应的所述第一记录对象有关联关系的一第二数据表中的一第二记录对象的地址;
第一数据查找模块,用于根据所述第一记录对象所属的所述第一存储装置中的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
10.根据权利要求9所述装置,其特征在于,所述数据库为一内存数据库,所述第一数据表和所述第二数据表均为所述内存数据库中的内存表。
11.根据权利要求10所述装置,其特征在于,所述第一数据表和所述第二数据表中有关联关系的记录对象之间是一对一的关系时,所述第一存储装置采用指针;
所述第一数据查找模块,用于根据所述第一记录对象所属的所述指针所指示的所述地址从所述第二数据表中获取与所述第一记录对象有关联关系的所述第二记录对象。
12.根据权利要求10所述装置,其特征在于,所述第一数据表和所述数据第二表中的记录对象之间是一对多的关系时,所述第一存储装置采用关联容器;所述关联容器用于保存和对应的所述第一记录对象有关联关系的所述第二数据表中的多个第二记录对象的地址;
所述第一数据查找模块,用于遍历所述第一记录对象所属的所述关联容器中的所述多个第二记录对象的地址以从所述第二数据表中获取与所述第一记录对象有关联关系的多个所述第二记录对象。
13.根据权利要求12所述装置,其特征在于,所述关联容器包括唯一索引型容器和/或非唯一索引型容器。
14.根据权利要求9或10所述装置,其特征在于,所述第一数据表中每条第一记录对象包括多个所述第一存储装置。
15.根据权利要求10所述装置,其特征在于,所述第一数据表和所述第二数据表中的记录对象之间是多对多的关系时,所述第二数据表包括归属于每条第二记录对象的一第二存储装置,其中所述第二存储装置用于保存和所述第二记录对象有关联关系的所述第一数据表中的一第一记录对象的地址;
所述装置还包括:
第二数据查找模块,用于根据所述第二记录对象所属的所述第二存储装置中的所述地址从所述第一数据表中获取与所述第二记录对象有关联关系的所述第一记录对象。
16.根据权利要求15所述装置,其特征在于,所述第二存储装置采用指针或者关联容器。
17.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1~8任一项所述数据库数据处理方法的步骤。
18.一种电子设备,其特征在于,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行权利要求1~8任一项所述数据库数据处理方法的步骤。
CN201710313199.7A 2017-05-05 2017-05-05 数据库数据处理方法、装置及存储介质和电子设备 Pending CN107145574A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710313199.7A CN107145574A (zh) 2017-05-05 2017-05-05 数据库数据处理方法、装置及存储介质和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710313199.7A CN107145574A (zh) 2017-05-05 2017-05-05 数据库数据处理方法、装置及存储介质和电子设备

Publications (1)

Publication Number Publication Date
CN107145574A true CN107145574A (zh) 2017-09-08

Family

ID=59777911

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710313199.7A Pending CN107145574A (zh) 2017-05-05 2017-05-05 数据库数据处理方法、装置及存储介质和电子设备

Country Status (1)

Country Link
CN (1) CN107145574A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108932313A (zh) * 2018-06-20 2018-12-04 斑马网络技术有限公司 数据处理方法、装置、电子设备及存储介质
CN109101634A (zh) * 2018-08-15 2018-12-28 北京三快在线科技有限公司 数据记录处理方法、装置、电子设备及存储介质
CN109471840A (zh) * 2018-10-15 2019-03-15 北京海数宝科技有限公司 文件查看方法、装置、计算机设备和存储介质
CN110196889A (zh) * 2019-05-30 2019-09-03 北京字节跳动网络技术有限公司 数据处理方法、装置、电子设备及存储介质
CN112131215A (zh) * 2019-06-25 2020-12-25 ***通信集团重庆有限公司 自底向上的数据库信息获取方法及装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101770479A (zh) * 2008-12-31 2010-07-07 北京亿阳信通软件研究院有限公司 一种关联关系的查询方法及装置
CN102195781A (zh) * 2011-05-30 2011-09-21 武汉理工大学 一种基于电子记录关联签名的电子证据取证***
CN102467507A (zh) * 2010-11-03 2012-05-23 康佳集团股份有限公司 一种快速查找日记的方法及移动终端
CN102467525A (zh) * 2010-11-10 2012-05-23 金蝶软件(中国)有限公司 单据关联方法及***
CN102624698A (zh) * 2012-01-17 2012-08-01 武汉理工大学 一种面向电子记录的证据管理与服务***
CN103678314A (zh) * 2012-09-03 2014-03-26 ***股份有限公司 基于关联规则提取的海量数据处理***、设备及方法
CN103984640A (zh) * 2014-05-14 2014-08-13 华为技术有限公司 实现数据预取方法及装置
CN105354149A (zh) * 2015-11-26 2016-02-24 深圳市金证科技股份有限公司 一种内存数据查找方法和装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101770479A (zh) * 2008-12-31 2010-07-07 北京亿阳信通软件研究院有限公司 一种关联关系的查询方法及装置
CN102467507A (zh) * 2010-11-03 2012-05-23 康佳集团股份有限公司 一种快速查找日记的方法及移动终端
CN102467525A (zh) * 2010-11-10 2012-05-23 金蝶软件(中国)有限公司 单据关联方法及***
CN102195781A (zh) * 2011-05-30 2011-09-21 武汉理工大学 一种基于电子记录关联签名的电子证据取证***
CN102624698A (zh) * 2012-01-17 2012-08-01 武汉理工大学 一种面向电子记录的证据管理与服务***
CN103678314A (zh) * 2012-09-03 2014-03-26 ***股份有限公司 基于关联规则提取的海量数据处理***、设备及方法
CN103984640A (zh) * 2014-05-14 2014-08-13 华为技术有限公司 实现数据预取方法及装置
CN105354149A (zh) * 2015-11-26 2016-02-24 深圳市金证科技股份有限公司 一种内存数据查找方法和装置

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108932313A (zh) * 2018-06-20 2018-12-04 斑马网络技术有限公司 数据处理方法、装置、电子设备及存储介质
CN108932313B (zh) * 2018-06-20 2021-06-04 斑马网络技术有限公司 数据处理方法、装置、电子设备及存储介质
CN109101634A (zh) * 2018-08-15 2018-12-28 北京三快在线科技有限公司 数据记录处理方法、装置、电子设备及存储介质
CN109101634B (zh) * 2018-08-15 2021-06-11 北京三快在线科技有限公司 数据记录处理方法、装置、电子设备及存储介质
CN109471840A (zh) * 2018-10-15 2019-03-15 北京海数宝科技有限公司 文件查看方法、装置、计算机设备和存储介质
CN109471840B (zh) * 2018-10-15 2021-10-26 北京海数宝科技有限公司 文件查看方法、装置、计算机设备和存储介质
CN110196889A (zh) * 2019-05-30 2019-09-03 北京字节跳动网络技术有限公司 数据处理方法、装置、电子设备及存储介质
CN112131215A (zh) * 2019-06-25 2020-12-25 ***通信集团重庆有限公司 自底向上的数据库信息获取方法及装置
CN112131215B (zh) * 2019-06-25 2023-09-19 ***通信集团重庆有限公司 自底向上的数据库信息获取方法及装置

Similar Documents

Publication Publication Date Title
US12003393B2 (en) Parallel computational framework and application server for determining path connectivity
CN107145574A (zh) 数据库数据处理方法、装置及存储介质和电子设备
US10887177B2 (en) Calculating trust scores based on social graph statistics
CN103748579B (zh) 在映射化简框架中处理数据
US9922134B2 (en) Assessing and scoring people, businesses, places, things, and brands
CN107123047B (zh) 基于债券交易的数据采集***及其数据采集方法
CN109299334B (zh) 一种知识图谱的数据处理方法及装置
CN102831122B (zh) 工作流表的数据保存方法、查询方法及装置
WO2019024496A1 (zh) 企业推荐方法及应用服务器
US11972228B2 (en) Merging database tables by classifying comparison signatures
CN107798038A (zh) 数据响应方法及数据响应设备
US8838610B2 (en) Listing tune-up system
CN101566986A (zh) 联机事务处理中的数据处理方法和装置
CN105117442B (zh) 一种基于概率的大数据查询方法
CN106326243B (zh) 一种数据处理方法及装置
CN107784070A (zh) 一种提高数据清洗效率的方法、装置及设备
CN107133289A (zh) 一种确定商圈的方法和装置
CN107577787A (zh) 关联数据信息入库的方法及***
CN107967279A (zh) 分布式数据库的数据更新方法及装置
US20180032934A1 (en) Assortment optimization
CN107146155A (zh) 一种利用红黑树索引提高交易***撮合效率的方法及***
CN109471874A (zh) 数据分析方法、设备及存储介质
US20220229814A1 (en) Maintaining stable record identifiers in the presence of updated data records
CN102193988A (zh) 一种图形数据库节点数据的检索方法及***
CN110119396A (zh) 数据管理方法及相关产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20170908