CN111831661A - 一种基于快递业务逻辑的数据库归档方法 - Google Patents

Abstract

本发明公开一种基于快递业务逻辑的数据库归档方法，包括业务库、归档库；所述业务库包括主表、副表；主表中包括业务ID、创建时间、业务状态数据；副表中包括业务ID、创建时间；包括以下步骤：设定数据归档策略，数据归档策略包括归档时间的设定值，业务状态数据中包括的数据条件；先查询主表，筛选出符合数据归档策略的记录，进行归档；然后根据主表、副表中记录业务ID值的关联，定位到副表中与这笔业务相关的所有记录，归档副表中的记录。本发明解决了传统的简单基于时间的归档方式的不足，既能及时按照时间要求归档，又能完整的归档同一业务中的所有记录，向报表查询程序提供完整一致的数据。

Description

一种基于快递业务逻辑的数据库归档方法

技术领域

本发明属于数据处理技术领域，尤其涉及基于业务逻辑和时间的自动归档方法。

背景技术

随着快递业务的飞速发展，智能快递柜是随着快递业务不断发展新生的事物。智能快递柜的功能主要是协助快递员收寄快递，面对的用户是广大的快递员和收件人。作为24小时无人值守的快递暂存柜，通过物联卡与服务端交互，作为物联网技术在现代物流行业中的应用，智能快递柜是电子商务末端物流最后一公里最有效的解决方法，提高了快递员的派送效率，降低了派送成本，保障了用户的隐私和安全，逐步得到广泛认可和推广。

智能快递柜系统作为快递终端的服务端，提供了用户认证，配置，调度，监控，操作日志等数据服务，每天产生的数据量及其巨大，需要及时清理历史数据，在确保业务逻辑完整性的基础上，归档非热点数据，以减轻数据库的负担，保证数据库的响应速度。

业界目前已存在一些数据库归档方案，即简单的基于时间维度的归档。缺点在于没有考虑同一业务逻辑中的不同数据产生或更新的时间是不同的，简单根据时间归档，会导致查询某一笔交易时缺失某些数据。所以需要一种兼顾时间与业务逻辑的归档方法。

发明内容

针对上述技术问题，本发明提供一种基于快递业务逻辑的数据库归档方法。该方法涉及驱动表、被驱动表、归档表，包含了查询、复制、删除等归档动作，最终实现同一业务逻辑中所有交易数据都被同时归档。

为达到上述目的，本发明采用的技术方案为：一种基于快递业务逻辑的数据库归档方法，包括业务库、归档库；所述业务库包括主表、副表；主表中包括业务ID、创建时间、业务状态数据；副表中包括业务ID、创建时间；包括以下步骤：

设定数据归档策略，数据归档策略包括归档时间的设定值，业务状态数据中包括的数据条件；先查询主表，筛选出符合数据归档策略的记录，进行归档；然后根据主表、副表中记录业务ID值的关联，定位到副表中与这笔业务相关的所有记录，归档副表中的记录。

进一步的，所述业务库和所述归档库配置为主从架构，所述业务库中的业务表数据实时同步到所述归档库中；所述归档库中包括主表、副表、归档表。

进一步的，出于系统性能与数据安全考虑，业务库和归档库分别位于不同的服务器上。

进一步的，基于业务逻辑和时间的自动归档方法具体包括如下步骤：

S1，T日，在所述归档库的业务主表中查询出符合归档时间条件且业务状态判断为已完成的数据，并将这些数据插入到归档表中；

S2，在所述归档库的归档表中查询出当天归档的数据的业务ID，并存储在数组结构中，而后使用循环遍历数组，取出每一个ID，在所述业务库的主表删除ID对应的数据；

S3，使用循环遍历数组，取出每一个ID，在所述归档库的副表中查出相应ID的数据，并插入到归档表中；

S4，使用循环遍历数组，取出每一个ID，在所述业务库的副表删除ID对应的数据。

本发明具有以下有益效果：本发明在满足归档时间条件的同时，根据业务主表判定已经结束的业务，并根据业务ID关联副表中此业务中的所有记录，最后将主表和副表中此业务中的所有记录一起归档。解决了传统的简单基于时间的归档方式的不足，以统一的业务ID为纽带，串起了不同时间不同表中属于同一业务的数据，既能及时按照时间要求归档，又能完整的归档同一业务中的所有记录，向报表查询程序提供完整一致的数据。

附图说明

图1为存取件业务的快递员存件流程图。

图2为存取件业务的收件人没有取件流程图。

图3为存取件业务的收件人取件流程图。

图4为存取件业务的业务完成后主表和副表中的数据示意图。

图5为本发明实施例的基于快递业务逻辑的数据库归档方法数据库架构图。

图6为本发明实施例的基于快递业务逻辑的数据库归档方法主表归档流程图。

图7为本发明实施例的基于快递业务逻辑的数据库归档方法删除主表数据示意图。

图8为本发明实施例的基于快递业务逻辑的数据库归档方法副表归档流程图。

图9为本发明实施例的基于快递业务逻辑的数据库归档方法删除副表数据示意图。

具体实施方式

为了便于本领域技术人员的理解，下面结合实施例与附图对本发明作进一步的说明。

术语定义：

主表——一笔业务正常运行所需的数据存放的表。如果数据存放失败，则这笔业务失败。在一笔存取件业务中，记录存取件数据的表就是主表，如果记录失败，则存件或取件失败。

副表——一笔业务完整运行所需的数据存放的表。如果数据存放失败，这笔业务不会失败，但不完整，需要事后补录。在一笔存取件业务中，向取件人发送的取件码等消息就存在副表中，如果发送取件码失败，则可再次补发。

归档表——存放归档数据的表。

主表、副表中各有若干字段，且字段中包括业务ID，创建时间。

一笔存取件业务的基本流程如下：

1.T日，快递员存件，系统在主表中插入一条快件记录。这条记录的业务ID为A，状态为“已存件”，创建时间为T日。与此同时，系统同时向收件人发送取件码，在副表中插入一条向收件人发送验证码的记录，业务ID为A，创建时间为T日。(图1)

2.T+1日，收件人没有来取件，系统向收件人发送提醒短信，在副表中插入一条发送记录。这条记录的业务ID为A，创建时间为T+1日。(图2)

3.T+2日，收件人取件，系统在主表中更新业务ID为A的快件记录，将状态更新为“已取件”。与此同时，系统向收件人发送消息提醒，在副表中插入一条发送记录。这条记录的业务ID为A，消息内容为“快件已取”，创建时间为T+2日。(图3)

至此，这笔存取件业务结束，在主表和副表中产生的数据如下(图4)：

主表中有一条记录，业务ID为A，创建时间为T日。

副表中有三条记录，业务ID均为A，创建时间分别为T日、T+1日、T+2日。

传统的归档方案为简单的基于时间的归档，对这种情况无能为力。

例如，要求每日归档一次业务数据，数据保留策略为15天。按照传统方案，基于创建时间归档，那么在T+15日，只能归档主表的数据，以及副表的1条数据(创建时间均为T日)，而遗漏了副表属于同一笔业务的2条数据(创建时间分别为T+1日和T+2日)。导致报表程序在查询业务A的归档数据的时候，总是缺少这笔业务在副表的一部分数据。

基于这种情况，本实施例的一种基于业务逻辑和时间的自动归档方法，考虑到一笔业务的开始和结束以业务主表为准，所以新归档方案在归档时先查询业务主表，筛选出符合归档时间条件且这笔业务已经完全结束的记录，然后根据主副表记录业务ID值的关联，定位到副表中与这笔业务相关的所有记录，与主表中的记录一起归档。

图5展示了本专利技术方案的数据库架构。这样设计数据库架构的原因如下：

出于系统性能与数据安全考虑，业务数据库和归档数据库分别位于不同的服务器上。

业务库为存储实时交易数据的数据库，业务主表和副表都存放于业务库中。

归档库为存储归档数据的数据库，归档表存放于归档库中。

因为Mysql数据库的Innodb存储引擎不支持跨服务器操作，所以需要将业务库和归档库配置为主从架构，令业务库的所有数据都实时的同步到归档库中，以便于业务表和归档表之间的数据搬运操作。所以归档库中也存放有业务表的数据，并且随着业务库中数据的变化(增删改)而变化，时刻与业务库保持同步。

图6到9展示了归档流程与程序中数组结构的运用。

假设数据保留策略为15天，则具体归档流程如下：

1.T日，在归档库的业务主表中查询出符合归档时间条件(T-15日)且状态为“已取件”的数据，并将这些数据插入到归档表中。SQL语句为

insert into<归档表>select*from<业务主表>where<创建时间＝T-15日>and<状态＝“已取件”>

2.在归档库的归档表中查询出当天归档的数据的业务ID，并存储在程序的数组结构中，而后使用循环遍历数组，取出每一个ID，在业务库的业务主表删除ID对应的数据。至此，主表中的数据归档完毕。程序代码示意：

数组＝select id from<归档表>where<归档时间＝T日>

for i in数组

do

mysql-h<业务库>-u<账号>-p<密码>-Ne“delete from<业务主表>where id＝$i”

done

3.使用循环遍历数组，取出每一个ID，在归档库的业务副表中查出相应ID的数据，并插入到归档表中。程序代码示意：

for i in数组

do

mysql-h<归档库>-u<账号>-p<密码>-Ne“insert into<归档表>select*from<业务副表>where id＝$i”

done

4.使用循环遍历数组，取出每一个ID，在业务库的业务副表删除ID对应的数据。至此，副表中的数据归档完毕。程序代码示意：

for i in数组

do

mysql-h<业务库>-u<账号>-p<密码>-Ne“delete from<业务副表>where id＝$i”

done

本实施例的数据库归档方法具有以下效果：由于智能快递柜业务的特点，一次存取件业务会横跨多日，并且不但插入数据到业务主表(快件表)，也会插入数据到业务副表(消息表)，造成了同一笔业务产生的数据分布在不同的时间和空间中。面对这种情况，传统的单一以日期为标准的归档方式会造成归档数据的不完整。本技术解决了这一问题，以统一的业务ID为纽带，串起了不同时间不同表中属于同一业务的数据，既能及时按照时间要求归档，又能完整的归档同一业务中的所有记录，向报表查询程序提供完整一致的数据。

以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。

Claims (4)

1.一种基于快递业务逻辑的数据库归档方法，其特征在于：包括业务库、归档库；所述业务库包括主表、副表；主表中包括业务ID、创建时间、业务状态数据；副表中包括业务ID、创建时间；包括以下步骤：

设定数据归档策略，数据归档策略包括归档时间的设定值，业务状态数据中包括的数据条件；先查询主表，筛选出符合数据归档策略的记录，进行归档；然后根据主表、副表中记录业务ID值的关联，定位到副表中与这笔业务相关的所有记录，归档副表中的记录。

2.根据权利要求1所述的基于快递业务逻辑的数据库归档方法，其特征在于：所述业务库和所述归档库配置为主从架构，所述业务库中的业务表数据实时同步到所述归档库中；所述归档库中包括主表、副表、归档表。

3.根据权利要求1或2所述的基于快递业务逻辑的数据库归档方法，其特征在于：业务库和归档库分别位于不同的服务器上。

4.根据权利要求1所述的基于快递业务逻辑的数据库归档方法，其特征在于：具体包括如下步骤：

S1，T日，在所述归档库的业务主表中查询出符合归档时间条件且业务状态判断为已完成的数据，并将这些数据插入到归档表中；

S2，在所述归档库的归档表中查询出当天归档的数据的业务ID，并存储在数组结构中，而后使用循环遍历数组，取出每一个ID，在所述业务库的主表删除ID对应的数据；

S3，使用循环遍历数组，取出每一个ID，在所述归档库的副表中查出相应ID的数据，并插入到归档表中；

S4，使用循环遍历数组，取出每一个ID，在所述业务库的副表删除ID对应的数据。

Images