CN103577474B - 一种数据库的更新方法及系统 - Google Patents

Abstract

本申请提供了一种数据库的更新方法及系统，解决数据库更新过程中资源消耗大的问题。所述的方法包括：在全量数据表中建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；分别查询每个增量数据的状态；其中，若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

Description

一种数据库的更新方法及系统

技术领域

本申请涉及数据处理技术，特别是涉及一种数据库的更新方法及系统。

背景技术

数据库中的数据进行同步的过程中，即数据表的更新过程中，需要定时将业务数据表中的数据同步到增量数据表中，再将增量数据表中的数据合并到全量数据表中。

其中，将增量数据表中的数据合并到全量数据表采用的方法是insert update方式，即按照业务数据表的主键和更新时间，把增量数据表中增加的数据insert（插入）到全量数据表中，将增量数据表中修改的数据update（更新）到全量数据表中。

但是，采用insert update方式时，需要遍历全量数据表中的所有数据，才能确认增量数据表中的哪个数据是增加的，哪个数据是修改的，然后再执行插入或更新操作。

全量数据表中的数据是非常多的，并且其中的大部分数据都是不会再修改的，因此采用insert update方式，遍历全量数据表中的所有数据会消耗大量的资源。尤其是针对海量数据的处理时，全量数据表中的数据是数以亿计的，采用insert update方式会大大的增加资源的消耗，并且，数据处理的时间比较长，效率非常低。

发明内容

本申请提供一种数据库的更新方法及系统，以解决数据库的更新过程中资源消耗较大，数据处理的时间比较长，效率非常低的问题。

为了解决上述问题，本申请公开了一种数据库的更新方法，包括：

在全量数据表中建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

分别查询每个增量数据的状态；其中

若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；

若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

优选的，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

优选的，所述的方法还包括：

增量数据表定时接收业务数据表发送的增量数据；

获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。

优选的，在全量数据表的未结束表中添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的未结束表中建立所述接收时间对应的存储分区；

在所述接收时间对应的存储分区中添加所述增量数据的记录。

优选的，所述在全量数据表的结束表的末尾添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的结束表的末尾建立所述接收时间对应的存储分区；

在所述接收时间对应的存储分区中添加所述增量数据唯一的记录。

优选的，所述的方法还包括：

业务数据表中增加业务数据时，配置所述业务数据的状态为未完成；

根据业务的执行，修改业务数据表中对应的业务数据，直到业务执行完毕，配置所述业务数据的状态为完成。

优选的，所述的方法还包括：

业务数据表定时抽取增量数据发送给增量数据表，其中，所述增量数据包括增加的业务数据和修改的业务数据。

相应的，本申请还公开了一种数据库的更新系统，包括全量数据表和增量数据表，其中，所述全量数据表，包括：

建立模块，用于建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

接收模块，用于接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

查询模块，用于分别查询每个增量数据的状态；

第一添加模块，用于若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；

第二添加模块，用于若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

优选的，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

优选的，所述增量数据表，包括：

接收模块，用于定时接收业务数据表发送的增量数据；

获取并建立模块，用于获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

保存模块，用于将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。

与现有技术相比，本申请包括以下优点：

首先，本申请在全量数据表中建立结束表和未结束表，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据，因此完成表中保存了全量数据表的大部分业务数据，而未完成表中仅保存了全量数据表的小部分业务数据。因此针对增量数据表发送的增量数据，可以按照数据所处的状态分别存储。在对增量数据进行存储时，识别处于完成状态的增量数据为业务执行完毕的业务数据，则可以在全量数据表的结束表的末尾添加所述处于完成状态的增量数据的记录，此时不需要进行查找，节省了资源，提高了处理时间和效率。识别处于未完成状态的增量数据为业务执行中的业务数据，则在全量数据表的未结束表中添加所述处于未完成状态的增量数据的记录，由于未完成表中的业务数据仅占全量数据表中的小部分，因此在添加处于未完成状态的增量数据时，无论查找与否消耗的资源都是比较少的，处理的时间也比较快。总体来讲，在结束表和未结束表中增量数据的操作都比较节省时间和资源，提高了处理效率。

其次，本申请按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。因此在接收到增量数据后，可以获取接收时间，再建立所述接收时间对应的存储分区，并将所述增量数据添加到接收时间对应的存储分区中。操作非常的简单，进一步的节省了资源且减少了处理时间。

附图说明

图1是本申请实施例所述一种数据库的更新方法流程图；

图2是本申请优选实施例所述一种数据库的更新方法中业务数据表的操作流程图；

图3是本申请优选实施例所述一种数据库的更新方法中增量数据表的操作流程图；

图4是本申请实施例所述一种数据库的更新系统结构图；

图5是本申请优选实施例所述一种数据库的更新系统第一种结构图；

图6是本申请优选实施例所述一种数据库的更新系统第二种结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

服务器中业务的执行过程中会产生业务数据，保存到业务数据表中，业务数据表中的业务数据最终要保存到全量数据表中。

现有技术采用insert update方式，即按照业务数据表的主键和更新时间，把增量数据表中增加的业务数据insert（插入）到全量数据表中，将增量数据表中修改的业务数据update（更新）到全量数据表中。其中，所述主键即主关键字(primary key)是数据表中的一个或多个字段，它的值用于惟一的标识数据表中的某一条记录。

具体实施中，针对增量数据表中增加的业务数据，需要首先获取该增加的业务数据的主键，然后需要遍历全量数据表，从全量数据表第一个业务数据的主键开始查找，直到查找到所述增加的业务数据的主键对应的位置，将所述增加的业务数据插入到该位置。

针对增量数据表中修改的业务数据，同样要获取所述修改的业务数据的主键，然后遍历所述全量数据表，查找所述主键在全量数据表中的位置，然后将修改的业务数据更新到该位置。

但是，上述的insert update的过程中，遍历全量数据表中的业务数据会消耗大量的资源。尤其是针对海量数据的处理时，全量数据表中的业务数据是数以亿计的，采用insert update方式会大大的增加资源的消耗，并且，数据处理的时间比较长，效率非常低。

本申请提供一种数据库的更新方法，针对增量数据表发送的增量数据，可以按照数据所处的状态分别存储，并且，在对增量数据进行存储时，仅在结束表和未结束表中添加相应的记录即可，因此本申请资源消耗较低，数据处理的时间比较短，效率非常高。

参照图1，给出了本申请实施例所述一种数据库的更新方法流程图。

步骤11，在全量数据表中建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

全量数据表用于保存业务数据，其中，所述业务数据可能是已经将业务执行完毕的数据，这些数据是不会再进行修改的；也可能是业务正在执行中的数据，这些数据是有可能会修改的。

因此，本申请考虑业务执行中的特点，在全量数据表中建立了结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据。因此，业务数据一旦存入到结束表以后，就不会再进行修改了，而业务数据存入到未结束表以后，还可能会发生变化，进行修改。

步骤12，接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

业务每天的执行中，可能会增加一些业务数据，也可能会对一些业务数据进行修改，这些增加和修改的业务数据会构成增量数据存储到增量数据表中，全量数据表会保存所有的业务数据，因此增量数据表中的增量数据还会保存到全量数据表中。

全量数据表可以接收增量数据表发送的增量数据，其中所述增量数据可能包含多个，可能包括处于完成状态的业务数据和处于未完成状态的业务数据，也可能仅包括处于完成状态的业务数据，或仅包括处于未完成状态的业务数据。

本申请中考虑业务执行中的特点，为业务数据配置了状态，包括完成状态和未完成状态，其中，若业务数据处于完成状态，则所述业务数据的业务执行完毕了，若业务数据处于未完成状态，则所述业务数据的业务正在执行中。

步骤13，分别查询每个增量数据的状态；

若所述增量数据的状态为完成，则执行步骤14；若所述增量数据的状态为未完成，则执行步骤15。

现有技术中不考虑业务的执行状态，将增量数据包括业务执行中和业务执行完毕的业务数据共同保存在全量数据表中，依据业务的实际进行，在所述全量数据表中的业务数据时海量的，并且其中大部分数据是业务执行完毕的业务数据，即不会进行修改的业务数据。其中，增量数据中可以包括增加的业务数据和修改的业务数据。

以一条修改的业务数据为例，依据所述修改的业务数据主键查找全量数据表时，其中大部分的业务数据是业务执行完毕的，即会进行修改的业务数据，则这些业务数据也不可能是所述修改的业务数据要查找的，现有技术在查找业务数据时，浪费了大量的资源，并且浪费了很多时间。

本申请将全量数据表分为完成表和未完成表，然后依据增量数据的状态分表存储，其中大部分的业务数据是业务执行完毕的，小部分是业务执行中的，因此完成表中保存了全量数据表的大部分业务数据，而未完成表中仅保存了全量数据表的小部分业务数据。具体如下：

步骤14，识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；

本申请中若所述增量数据的状态为完成，则可以识别出所述增量数据为业务执行完毕的业务数据，即所述业务数据不会再进行修改了。因此可以将所述处于完成状态的增量数据存入全量数据表的结束表中，具体实施中，不需要依据增量数据的主键从头查找全量数据表，而是可以直接在全量数据表的结束表的最后添加对应的记录，所述记录中存储的内容为所述处于完成状态的增量数据，此时不需要进行查找，节省了资源。

步骤15，识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

若所述增量数据的状态为未完成，则可以识别所述增量数据为业务执行中的业务数据，即所述业务数据可能会再进行修改，因此可以将处于未完成状态的增量数据存入全量数据表的未结束表中，具体实施中，不需要依据增量数据的主键从头查找全量数据表，可以直接在未结束表的最后添加对应的记录，所述记录中存储的内容为所述处于未完成状态的增量数据，也可以依据主键查找到所述处于未完成状态的增量数据的位置，执行插入或更新操作。

本申请中由于未完成表中的业务数据仅占全量数据表中的小部分，因此在添加处于未完成状态的增量数据时，无论查找与否消耗的资源都是比较少的，处理的时间也比较快。

综上所述，本申请在全量数据表中建立结束表和未结束表，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据，因此完成表中保存了全量数据表的大部分业务数据，而未完成表中仅保存了全量数据表的小部分业务数据。因此针对增量数据表发送的增量数据，可以按照数据所处的状态分别存储。在对增量数据进行存储时，识别处于完成状态的增量数据为业务执行完毕的业务数据，则可以在全量数据表的结束表的末尾添加所述处于完成状态的增量数据的记录，此时不需要进行查找，节省了资源，提高了处理时间和效率。识别处于未完成状态的增量数据为业务执行中的业务数据，则在全量数据表的未结束表中添加所述处于未完成状态的增量数据的记录，由于未完成表中的业务数据仅占全量数据表中的小部分，因此在添加处于未完成状态的增量数据时，无论查找与否消耗的资源都是比较少的，处理的时间也比较快。总体来讲，在结束表和未结束表中添加增量数据的操作都比较节省时间和资源，提高了处理效率。

参照图2，给出了本申请优选实施例所述一种数据库的更新方法中业务数据表的操作流程图。

优选的，所述的方法还包括：

步骤21，业务数据表中增加业务数据时，配置所述业务数据的状态为未完成；

业务的执行过程中会产生业务数据，因此建立了一个业务数据表来存储业务数据。并且，考虑到后续的数据处理过程，业务数据表中的数据最终要存储到全量数据表中。考虑业务执行的特点，在业务数据表中增加一条业务数据时，可以配置所述业务数据的状态为未完成。

例如，在电子商务平台中，一条购物数据可能包括的过程为创建订单、付款、确认收货。则在创建订单后会生成对应的业务数据，采用主键唯一标识，此时会在业务数据表中添加对应的业务数据，此时配置所述业务数据的状态为未完成。

步骤22，根据业务的执行，修改业务数据表中对应的业务数据，直到业务执行完毕，配置所述业务数据的状态为完成。

业务的执行过程中，会进行业务的各个流程，因此相应的就会修改业务数据表中对应的业务数据，一直到业务执行完毕后，配置业务数据表中对应的业务数据的状态为完成。

如上例中，业务过程由创建订单执行到付款，此时业务数据会进行修改，通过业务主键可以查找到业务数据表中的业务数据，然后对所述业务数据进行修改，此时所述业务数据的状态仍然是未完成。直到业务过程进行到确认收货，此时业务已经执行完毕，通过业务主键可以查找到业务数据表中的业务数据，然后对所述业务数据进行修改，然后配置所述业务数据的状态为完成。

步骤23，业务数据表定时抽取增量数据发送给增量数据表，其中，所述增量数据包括增加的业务数据和修改的业务数据。

每天会增加新的业务数据，并且会根据业务的执行过程对业务数据修改，由于业务数据表中的业务数据最终要保存到全量数据表中，为了减少不必要的操作，节省资源，因此仅需要将发生变化的业务数据，即增加的业务数据和修改的业务数据保存到全量数据表中即可。因此，将增加的业务数据和修改的业务数据作为增量数据。

业务数据表定时抽取增量数据，然后将所述增量数据发送给增量数据表，例如，每天0时抽取一次增量数据。

优选的，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

本申请中针对增量数据表和全量数据表，可以按照业务数据的接收时间来划分存储分区。例如，增量数据表和全量数据表每天执行一次更新，则可以在增量数据表和全量数据表中按天来建立存储分区。

参照图3，给出了本申请优选实施例所述一种数据库的更新方法中增量数据表的操作流程图。

优选的，增量数据表的操作过程包括：

步骤31，增量数据表定时接收业务数据表发送的增量数据；

增量数据表定时接收到业务数据表发送的增量数据，例如，每天接收一次增量数据。所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据。

步骤32，获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

接收业务数据表发送的增量数据后，可以获取所述增量数据的接收时间，例如，若按天划分存储分区，在2011-6-100:00获取到业务数据表发送的增量数据，则确定接收时间为2011-6-1，并所述增量数据表中建立2011-6-1对应的存储分区，如将接收时间作为存储分区的标识。

当然针对接收时间还可以精确到小时或分钟，可以视具体的业务需求而定，本申请对此不做限定。

步骤33，将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。

上述在增量数据表中建立了接收时间对应的存储分区后，可以将所述增量数据存储到所述接收时间对应的存储分区中。

例如，所述增量数据中x-001为增加的业务数据，状态为未完成，x-002为修改的业务数据，状态为未完成，x-003为修改的业务数据，状态为完成。

如上例建立了2011-6-1对应的存储分区，则将增量数据x-001、x-002和x-003都存入到所述2011-6-1对应的存储分区中。

步骤34，发送所述增量数据给全量数据表。

优选的，所述在全量数据表的未结束表中添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的未结束表中建立所述接收时间对应的存储分区；在所述接收时间对应的存储分区中添加所述增量数据的记录。

全量数据表接收到增量数据后，会查询每个增量数据的状态，若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据。

则获取所述业务执行中的业务数据的接收时间，在并在全量数据表的未结束表中建立所述接收时间对应的存储分区。其中，按照接收时间在未结束表中建立存储分区时，则每次接收时的接收时间都是最近的，因此可以在未结束表中所有存储分区的末尾添加一个所述接收时间的存储分区。然后在所述接收时间对应的存储分区中添加对应所述增量数据的记录，可以在所述存储分区中仅添加在所述接收时间获取的未完成状态的增量数据，当然也可以将全量数据表中其他未完成状态的增量数据也添加到所述存储分区中，本申请对此不做限定。

如上例中，x-001为增加的业务数据，状态为未完成，则识别x-001为业务执行中的业务数据。按天划分存储分区，则在全量数据表的未完成表中建立接收时间2011-6-1对应的存储分区，在所述存储分区中添加对应的记录，所述记录的内容为增加的业务数据x-001。

x-002为修改的业务数据，状态为未完成，同样识别为业务执行中的业务数据。因此在全量数据表的未完成表中，所述接收时间2011-6-1对应的存储分区中添加对应的记录，所述记录的内容为修改的业务数据x-002。

实际处理中，一条业务数据可以采用主键唯一标识，对全量数据表的未完成表中是按照接收时间来划分存储分区的，因此在不同的存储分区中存储的业务数据的主键可能相同。如上例中的购物数据005，在全量数据表的未完成表中，创建订单产生的业务数据x-005可能存储2011-5-1对应的存储分区中，付款对应修改的业务数据x-005可能存储2011-5-10对应的存储分区中。

优选的，所述在全量数据表的结束表的末尾添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的结束表的末尾建立所述接收时间对应的存储分区；在所述接收时间对应的存储分区中添加所述增量数据唯一的记录。

全量数据表接收到增量数据后，会查询每个增量数据的状态，若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据。

则获取所述业务执行完毕的业务数据的接收时间，在并在全量数据表的结束表中建立所述接收时间对应的存储分区。其中，每次接收时的接收时间都是最近的，因此可以在结束表中所有存储分区的末尾添加一个所述接收时间的存储分区。然后在所述接收时间对应的存储分区中添加对应所述增量数据的记录。

如上例中，x-003为修改的业务数据，状态为完成，则识别x-003为业务执行完毕的业务数据。按天划分存储分区，则在全量数据表的完成表中建立接收时间2011-6-1对应的存储分区，在所述存储分区中添加对应的记录，所述记录的内容为修改的业务数据x-003。

实际处理中，业务数据只有在处于完成状态，即业务执行完毕后才会添加到全量数据表的完成表中，因此在全量数据表的完成表中，一条业务数据只能存储在一个存储分区中。

实际处理中，为了进一步的节省时间，业务数据可以一批一起进行处理。因此，可以使未完成表中每一个存储分区中都保存有，截止到对应接收时间为止所有未完成状态的业务数据。例如，按天存储，若本次接收时间为2012-1-13，则上一个接收时间为2012-1-12，则未完成表中2012-1-12对应存储分区中保存有，截止到2012-1-12所有未完成的业务数据。

针对本次接收的增量数据，可以获取未完成表中上一个接收时间的存储分区中的业务数据，通过主键将所述增量数据和所述存储分区中的业务数据进行全外连接，即将两份数据通过主键连接在一起。然后采用修改的业务数据更新所述存储分区中主键一致的业务数据，将增加的业务数据按照主键排列并存放到对应位置。

本次接收的增量数据（本次增加的业务数据和修改的业务数据）可以包括完成状态和未完成状态，则通过上述操作最终可以得到：1、本次接收的完成状态的业务数据；2、截止到本次接收所有未完成状态的业务数据（包括：本次修改的业务数据、本次增加的业务数据和之间的未完成状态的业务数据）。

然后可以过滤出完成状态的业务数据添加到完成表中本次接收时间的存储分区内，过滤出未完成状态的业务数据添加到未完成表中本次接收时间的存储分区内。

则完成表中本次接收时间的存储分区内包括：本次接收的完成状态的业务数据；未完成表中本次接收时间的存储分区内包括：截止到本次接收时间所有未完成状态的业务数据。

综上所述，本申请按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。因此在接收到增量数据后，可以获取接收时间，再建立所述接收时间对应的存储分区，并将所述增量数据添加到接收时间对应的存储分区中。操作非常的简单，进一步的节省了资源且减少了处理时间。

参照图4，给出了本申请实施例所述一种数据库的更新系统结构图。

相应的，本申请还提供了一种数据库的更新系统，包括全量数据表12和增量数据表11，其中：

所述全量数据表12，包括：

建立模块121，用于建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

接收模块122，用于接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

查询模块123，用于分别查询每个增量数据的状态；

第一添加模块124，用于若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；

第二添加模块125，用于若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

参照图5，给出了本申请优选实施例所述一种数据库的更新系统第一种结构图。

优选的，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

优选的，所述增量数据表11，包括：

接收模块111，用于定时接收业务数据表发送的增量数据；

获取并建立模块112，用于获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

保存模块113，用于将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。

优选的，第二添加模块125，包括：

获取并建立子模块1251，用于获取接收时间，并在全量数据表的未结束表中建立所述接收时间对应的存储分区；

添加子模块1252，用于在所述接收时间对应的存储分区中添加所述增量数据的记录。

优选的，所述第一添加模块124，包括：

获取并建立子模块1241，用于获取接收时间，并在全量数据表的结束表的末尾建立所述接收时间对应的存储分区；

添加子模块1242，用于在所述接收时间对应的存储分区中添加所述增量数据唯一的记录。

参照图6，给出了本申请优选实施例所述一种数据库的更新系统第二种结构图。

优选的，所述的系统还包括业务数据表10；

所述业务数据表10，包括：

增加数据模块101，用于业务数据表中增加业务数据时，配置所述业务数据的状态为未完成；

修改数据模块102，用于根据业务的执行，修改业务数据表中对应的业务数据，直到业务执行完毕，配置所述业务数据的状态为完成；

发送模块103，用于业务数据表定时抽取增量数据发送给增量数据表，其中，所述增量数据包括增加的业务数据和修改的业务数据。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种数据库的更新方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (9)

1.一种数据库的更新方法，其特征在于，包括：

在全量数据表中建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

分别查询每个增量数据的状态；其中

若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据，在全量数据表的结束表的末尾添加所述增量数据的记录；

若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录；

其中，所述在全量数据表的结束表的末尾添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的结束表的末尾建立所述接收时间对应的存储分区；

在所述接收时间对应的存储分区中添加所述增量数据唯一的记录。

2.根据权利要求1所述的方法，其特征在于，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

3.根据权利要求2所述的方法，其特征在于，还包括：

增量数据表定时接收业务数据表发送的增量数据；

获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。

4.根据权利要求2所述的方法，其特征在于，在全量数据表的未结束表中添加所述增量数据的记录，包括：

获取接收时间，并在全量数据表的未结束表中建立所述接收时间对应的存储分区；

在所述接收时间对应的存储分区中添加所述增量数据的记录。

5.根据权利要求1所述的方法，其特征在于，还包括：

业务数据表中增加业务数据时，配置所述业务数据的状态为未完成；

根据业务的执行，修改业务数据表中对应的业务数据，直到业务执行完毕，配置所述业务数据的状态为完成。

6.根据权利要求5所述的方法，其特征在于，还包括：

业务数据表定时抽取增量数据发送给增量数据表，其中，所述增量数据包括增加的业务数据和修改的业务数据。

7.一种数据库的更新系统，其特征在于，包括全量数据表和增量数据表，其中，所述全量数据表，包括：

建立模块，用于建立结束表和未结束表，其中，结束表中存储业务执行完毕的业务数据，未结束表中存储业务执行中的业务数据；

接收模块，用于接收增量数据表发送的增量数据，其中，所述增量数据包括处于完成状态的业务数据和/或处于未完成状态的业务数据；

查询模块，用于分别查询每个增量数据的状态；

第一添加模块，用于若所述增量数据的状态为完成，则识别所述增量数据为业务执行完毕的业务数据；获取接收时间，并在全量数据表的结束表的末尾建立所述接收时间对应的存储分区；在所述接收时间对应的存储分区中添加所述增量数据唯一的记录；

第二添加模块，用于若所述增量数据的状态为未完成，则识别所述增量数据为业务执行中的业务数据，在全量数据表的未结束表中添加所述增量数据的记录。

8.根据权利要求7所述的系统，其特征在于，按照业务数据的接收时间划分增量数据表和全量数据表的存储分区。

9.根据权利要求8所述的系统，其特征在于，所述增量数据表，包括：

接收模块，用于定时接收业务数据表发送的增量数据；

获取并建立模块，用于获取所述增量数据的接收时间，并在增量数据表中建立所述接收时间对应的存储分区；

保存模块，用于将所述增量数据存储到增量数据表中所述接收时间对应的存储分区中。