跨时区运营数据库系统、数据查询方法、介质及服务器

摘要

本申请提供一种跨时区运营数据库系统、数据查询方法、介质及服务器，系统包括数据库对外接口库、用户信息库和至少一个业务数据库，用户信息库存储有用户信息，用户信息中包括用户的唯一ID和时区信息，所有业务数据库采用同一基准时区存储业务数据，方法应用于数据库对外接口库，包括：接收客户端发送的业务数据获取请求，其中包含用户的唯一ID、业务数据类型、业务数据时间；将唯一ID发送至用户信息库，接收用户信息库返回的用户时区；确定出用户时区与基准时区之间的时区转换关系，根据时区转换关系，将业务数据时间转换为基准时区下的数据访问时间；根据数据访问时间和业务数据类型，从业务数据库获取目标业务数据；将目标业务数据返回客户端。

说明书

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种跨时区运营数据库系统、数据查询方法、介质及服务器。

背景技术

随着应用程序的国际化应用，数据库系统也需要实现跨时区运营，以解决跨时区运营中的数据准确性问题。

目前，为了实现跨时区运营，许多软件运营商选择通过java(一种面向对象编程语言)或者PHP(Personal Home Page，超文本预处理器，后更名为Hypertext Preprocessor)等程序实现时区转换的问题，从而实现跨时区运营；此外，也有在多个地区对应设置数据库服务器的方式，解决时区转换的问题，实现跨时区运营。但这些方式，主要存在以下几个缺点：

(1)程序维护成本高：现有的方式案通过java、PHP等程序维护时区转换，程序维护更替的成本较高。

(2)数据管理成本高：现有的方式，数据库按照用户时区分时区存放数据库，导致数据库管理数据的成本增加，且不利于运营人员对软件整体的数据分析。

(3)软件用户体验差：由于软件数据库服务器和用户时区不同，实际中时区转换不准确，会导致用户获取到的数据往往不准确，从而给用户带来极差的体验。

(4)可扩展性差：现有的技术想要实现或者增加一个时区的运营，往往需要重新部署程序，修改程序等环节，实现起来较为复杂。

发明内容

本申请实施例的目的在于提供一种跨时区运营数据库系统、数据查询方法、介质及服务器，以低成本、高效率的方式实现跨时区运营。

为了实现上述目的，本申请的实施例通过如下方式实现：

第一方面，本申请实施例提供一种跨时区运营数据查询方法，跨时区运营数据库系统包括数据库对外接口库、用户信息库和至少一个业务数据库，所述数据库对外接口库分别与所述用户信息库、所述业务数据库、外部的客户端对接，所述用户信息库存储有用户信息，所述用户信息中包括用户的唯一ID和时区信息，所有所述业务数据库采用同一基准时区存储业务数据，所述方法应用于所述数据库对外接口库，包括：接收所述客户端发送的业务数据获取请求，其中，所述业务数据获取请求包含用户的唯一ID、业务数据类型、业务数据时间，所述业务数据时间为该用户所在时区的时间；将所述唯一ID发送至所述用户信息库，并接收所述用户信息库返回的用户时区，其中，所述用户时区与所述唯一ID对应同一用户；确定出所述用户时区与所述基准时区之间的时区转换关系，并根据所述时区转换关系，将所述业务数据时间转换为基准时区下的数据访问时间；根据所述数据访问时间和所述业务数据类型，从所述业务数据库获取目标业务数据，其中，所述目标业务数据与所述数据访问时间和所述业务数据类型相对应；将所述目标业务数据返回所述客户端。

在本申请实施例中，通过跨时区运营数据库系统包括数据库对外接口库、用户信息库和至少一个业务数据库。用户信息库存储有用户信息(包括用户的唯一ID和时区信息)，可以使得用户信息集中存储，一方面省事可靠，另一方面便于管理，实现起来也简单。所有业务数据库采用同一基准时区存储业务数据，这使得所有的业务数据库具有统一的存储标准，能够避免不同数据库按照不同用户时区存储数据的弊端：数据存储或转换过程不准确导致数据不准确的问题。并且，业务数据库存储业务数据的时间统一，不必考虑用户多时区问题，这样使业务数据库的数据管理更加简单高效。以及，用户信息库和业务数据库分开管理，通过用户信息库获取时区等基本信息，通过业务数据库获取业务数据，这样可以保证数据库的一致性。而数据库对外接口库接收客户端发送的业务数据获取请求(包含用户的唯一ID、业务数据类型、业务数据时间)，将唯一ID发送至用户信息库，确定出对应的用户时区。确定出用户时区与基准时区之间的时区转换关系，从而将业务数据时间转换为基准时区下的数据访问时间；以从业务数据库获取目标业务数据，将目标业务数据返回客户端。这样的方式，客户端与数据库服务器之间的时间时区是相互独立的，可以简化客户端的工程，对于面向用户的客户端来说，不需要关心用户时区转换问题，有利于提高用户软件体验。对于数据库服务器来说，可以为管理人员、运营人员提供具有统一时区的数据，对数据管理、软件运营的效率能够有极大的提升。与此同时，还能够降低软件维护成本，与传统方案使用java或者PHP不同，本方案采用数据库存储过程的方式，极大地简化了代码，使得代码更易理解，程序维护成本更低。此外，使用数据库存储的方案，在修改存储过程时候，可以不停机维护，程序修改维护对于用户是无感知的，这样使得软件体验更加友好。

结合第一方面，在第一方面的第一种可能的实现方式中，所述时区转换关系在数据库存储过程写入，所述时区转换关系为：基准时区下的时间＝用户时区下的时间+时区时间差，其中，所述时区时间差为所述基准时区与所述用户时区之差，且至少两个用户时区对应的所述时区时间差不同。

在该实现方式中，通过在数据库存储过程写入时区转换关系：基准时区下的时间＝用户时区下的时间+时区时间差，一方面便于高效且准确地将用户时区下的业务数据时间转换为基准时区下的数据访问时间；另一方面，业务数据库可以根据不同的业务需要增加或者减少，而时区的转换也可以根据实际需要(跨时区运营的范围)进行新增或减少，只需要在数据库对外接口库的存储里增加或者减少对应的分支即可，不必根据用户时区新设业务数据库，也不必在业务发生地新建数据库，能够极为简单地实现业务的扩展。

结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述时区转换关系为数据库存储过程写入的语句：set time_zone＝‘A’，其中，A为所述时区时间差。

在该实现方式中，利用在数据库存储过程写入的语句：settime_zone＝‘A’，A为时区时间差，即可简单准确地实现用户时区与基准时区之间的转化，将用户时区下的业务数据时间转换为基准时区下的数据访问时间，新增分支时，只需对应增加新的用户时区及对应的A值即可，便于扩展和维护，还可以不停机维护，能够在用户无感知的情况下实现新用户时区业务的开展。

结合第一方面，在第一方面的第三种可能的实现方式中，所述业务数据库的数量为多个，且至少两个所述业务数据库存储不同类型的业务数据，所述根据所述数据访问时间和所述业务数据类型，从所述业务数据库获取目标业务数据，包括：从多个所述业务数据库中确定出存储有所述业务数据类型对应的业务数据的目标数据库；将所述数据访问时间发送至所述目标数据库，并接收所述目标数据库返回的所述目标业务数据。

在该实现方式中，业务数据库的数量为多个，至少两个业务数据库存储不同类型的业务数据，可以按照业务类型的不同采用不同的业务数据库存储。而在数据库对外接口库访问业务数据时，能够根据需要的业务数据的类型确定相应的业务数据库进行访问，获取对应的数据，更有利于管理和维护。

第二方面，本申请实施例提供一种跨时区运营数据库系统，包括数据库对外接口库、用户信息库和至少一个业务数据库，所述数据库对外接口库分别与所述用户信息库、所述业务数据库、外部的客户端对接，所述数据库对外接口库，用于接收所述客户端发送的业务数据获取请求，并将所述业务数据获取请求中用户的唯一ID发送至所述用户信息库，其中，所述业务数据获取请求包含用户的唯一ID、业务数据类型、业务数据时间，所述业务数据时间为该用户所在时区的时间；所述用户信息库，用于接收所述唯一ID，确定出所述唯一ID对应的目标用户信息，基于所述目标用户信息确定出该唯一ID对应的用户时区，并将所述用户时区发送给所述数据库对外接口库，其中，所述用户信息库存储有用户信息，所述用户信息中包括用户的唯一ID和时区信息；所述数据库对外接口库，还用于根据所述时区转换关系，将所述业务数据时间转换为基准时区下的数据访问时间；以及，将所述数据访问时间发送给与所述业务数据类型对应的业务数据库；所述业务数据库，用于根据所述数据访问时间，确定出目标业务数据，并将所述目标业务数据发送给所述数据库对外接口库，其中，所有所述业务数据库均采用所述基准时区存储业务数据；所述数据库对外接口库，还用于接收所述业务数据库返回的所述目标业务数据，并将所述目标业务数据返回给所述客户端。

结合第二方面，在第二方面的第一种可能的实现方式中，所述时区转换关系为数据库存储过程写入的语句：settime_zone＝‘A’，其中，A为所述基准时区与所述用户时区之间的时区时间差，其中，至少两个用户时区对应的所述时区时间差不同。

结合第二方面，在第二方面的第二种可能的实现方式中，所述业务数据库的数量为多个，且至少两个所述业务数据库存储不同类型的业务数据，所述数据库对外接口库，具体用于：从多个所述业务数据库中确定出存储有所述业务数据类型对应的业务数据的目标数据库；将所述数据访问时间发送至所述目标数据库，并接收所述目标数据库返回的所述目标业务数据。

结合第二方面，在第二方面的第三种可能的实现方式中，所述数据库对外接口库还与后台对接，所述数据库对外接口库，还用于：接收所述后台发送的新增指令，其中，所述新增指令用于指示所述数据库对外接口库新增时区分支，所述新增指令中包含新增时区的时区转换关系；根据所述新增时区的时区转换关系，在所述数据库存储过程写入语句：settime_zone＝‘b’，其中，b为所述基准时区与所述新增时区之间的时区时间差。

在该实现方式中，通过这样的方式能够简单、快速、高效且低成本地实现业务的新增。

第三方面，本申请实施例提供一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行第一方面或第一方面的可能的实现方式中任意一项所述的跨时区运营数据查询方法。

第四方面，本申请实施例提供一种服务器，包括存储器和处理器，所述存储器用于存储包括程序指令的信息，所述处理器用于控制程序指令的执行，所述程序指令被处理器加载并执行时实现第一方面或第一方面的可能的实现方式中任意一项所述的跨时区运营数据查询方法。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种跨时区运营数据库系统的示意图。

图2为本申请实施例提供的一种服务器的结构框图。

图3为本申请实施例提供的一种跨时区运营数据库系统运行的时序图。

图4为本申请实施例提供的一种应用于数据库对外接口库的跨时区运营数据查询方法的流程图。

图标：100-跨时区运营数据库系统；110-数据库对外接口库；120-用户信息库；130-业务数据库；200-服务器；210-存储器；220-通信模块；230-总线；240-处理器。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

请参阅图1，图1为本申请实施例提供的一种跨时区运营数据库系统100的示意图。在本实施例中，跨时区运营数据库系统100可以包括数据库对外接口库110、用户信息库120和至少一个业务数据库130，数据库对外接口库110可以分别与用户信息库120、业务数据库130、外部的客户端对接。

在本实施例中，数据库对外接口库110可以视为一个交互中心，分别与用户信息库120、业务数据库130、客户端对接，实现数据库对外接口库110与用户信息库120的交互、数据库对外接口库110与业务数据库130的交互，以及数据库对外接口库110与客户端的交互。数据库对外接口库110可以是一个独立的数据库，可以收发数据，实现数据查询，可以设有MySQL(一种关系型数据库管理系统)存储过程等，此处不作限定。此处的存储过程，表示在大型数据库系统中一组为了完成特定功能的SQL(Structured Query Language，结构化查询语言)语句集，它存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。

在本实施例中，用户信息库120可以为一个独立的数据库，可以用于存储用户信息，用户信息中包括用户的唯一ID(Identity document，身份证标识号)和时区信息，当然，还可以包括用户的其他信息，例如：用户的地区、用户的身份信息(性别、年龄等)，此处不作限定。

在本实施例中，业务数据库130用于存储业务数据。业务数据库130的数量可以为一个，也可以为多个，可以根据实际需要设置(例如实际中需要存储不同类型的业务数据，为了便于管理可以分别针对不同类型的业务数据选用多个业务数据库类分别进行存储，此处不作限定)。无论业务数据库130的数量为一个还是多个，所有业务数据库130均采用同一基准时区存储业务数据。

至于外部的客户端，则可以理解为软件运营商的用户所使用的客户端程序，当用户想要获取数据时，即可通过客户端发送业务数据获取请求，以便用户获取相应的业务数据。

在本实施例中，跨时区运营数据库系统100的数据库对外接口库110、用户信息库120和至少一个业务数据库130，均可以利用服务器实现。请参阅图2，图2为本申请实施例提供的一种服务器200的结构框图。

在本实施例中，服务器200可以为云服务器、数据库服务器、服务器集群等，此处不作限定。

示例性的，服务器200可以包括：通过网络与外界连接的通信模块220、用于执行程序指令的一个或多个处理器240、总线230和不同形式的存储器210，例如，磁盘、ROM(Read-Only Memory，只读存储器)、或RAM(Random Access Memory，随机存取存储器)，或其任意组合。存储器210、通信模块220、处理器240之间可以通过总线230连接。

示例性的，存储器210中存储有程序。处理器240可以从存储器210调用并运行这些程序，从而便可以通过运行程序而实现相应的方法步骤：例如，服务器200为数据库对外接口库110，那么，通过运行其内置的程序可以实现跨时区运营数据查询方法；服务器200为用户信息库120，则可以通过运行其内置的程序实现用户时区的确定；服务器200为业务数据库130，则可以通过运行其内置的程序实现业务数据的确定，以及将确定的业务数据返回给数据库对外接口库。

为了便于对本方案的理解，以下将结合跨时区运营数据查询方法对跨时区运营数据库系统进行详细的介绍。请参阅图3，图3为本申请实施例提供的一种跨时区运营数据库系统运行的时序图，示出了跨时区运营数据库系统在整体上的运行过程。

在本实施例中，为了获取需要的业务数据，客户端可以基于用户的操作，向数据库对外接口库发送业务数据获取请求。此处，业务数据获取请求中可以包含用户的唯一ID、业务数据类型、业务数据时间(通常是一个时间范围)，由于涉及到跨时区运营，因此，不同用户所在的时区可能会存在不同，例如，甲地用户使用的时区为东八区，乙地用户使用的时区为东九区。而业务数据时间，则是指该用户所在时区的时间。

由于本申请实施例中提供的跨时区运营数据查询方法，应用于数据库对外接口库，因此，涉及到数据库对外接口库的执行过程，以跨时区运营数据查询方法中的方法步骤为基础描述，以便理解跨时区运营数据查询方法在跨时区运营数据库系统的整个运行过程中的顺序和作用。

请结合参阅图3和图4，图4为本申请实施例提供的一种应用于数据库对外接口库的跨时区运营数据查询方法的流程图。在本实施例中，跨时区运营数据查询方法可以包括步骤S10、步骤S20、步骤S30、步骤S40和步骤S50。

在客户端向数据库对外接口库发送业务数据获取请求后，数据库对外接口库可以执行步骤S10。

步骤S10：接收所述客户端发送的业务数据获取请求，其中，所述业务数据获取请求包含用户的唯一ID、业务数据类型、业务数据时间，所述业务数据时间为该用户所在时区的时间。

示例性的，数据库对外接口库可以接收客户端发送的业务数据获取请求。

接收业务数据获取请求后，数据库对外接口库可以执行步骤S20。

步骤S20：将所述唯一ID发送至所述用户信息库，并接收所述用户信息库返回的用户时区，其中，所述用户时区与所述唯一ID对应同一用户。

在本实施例中，数据库对外接口库可以将业务数据获取请求中的唯一ID发送至用户信息库，以便通过用户信息库查询该用户对应的用户时区。

而用户信息库接收唯一ID后，可以确定出该唯一ID对应的目标用户信息(前文已经介绍过，用户信息中包括唯一ID和时区信息，那么，通过唯一ID可以确定出对应的用户信息)。确定出目标用户信息后，用户信息库可以通过该用户信息中的时区信息进一步确定出该用户的用户时区。确定出该唯一ID对应的用户时区后，用户信息库可以将用户时区发送给数据库对外接口库。

因此，数据库对外接口库可以接收用户信息库返回的用户时区，而此用户时区与该唯一ID对应同一用户。

确定出用户时区后，数据库对外接口库可以执行步骤S30。

步骤S30：确定出所述用户时区与所述基准时区之间的时区转换关系，并根据所述时区转换关系，将所述业务数据时间转换为基准时区下的数据访问时间。

在本实施例中，数据库对外接口库可以基于接收的用户时区，确定出该用户时区与基准时区(即业务数据库存储业务数据时采用的统一的基准时区)之间的时区转换关系。

示例性的，此处的时区转换关系为预设的，以便于数据库对外接口库基于用户时区确定。示例性的，时区转换关系可以为：基准时区下的时间＝用户时区下的时间+时区时间差，此处的时区时间差为预设的，时区时间差为基准时区与用户时区之差。例如，基准时区为东八区，用户所在地为东京，则用户时区为东九区，而东八区与东九区之间的时区时间差为“-1：00”，那么，若用户时区下的时间为某日12：00，那么，可以通过时区转换关系得到基准时区下的时间为：12：00+(-1：00)＝11：00，即基准时区下的时间为同日的11：00。当然，此处仅是举例说明，不应视为对本申请的限定，另外，关于跨日期的时间转换，也可以通过同样的方式可以得到，确定出的时间为负数，而后通过转换为正常数值(例如24小时制)的时间，确定为前一日的时间即可，此处不再赘述。

利用预设的时区转换关系，即可将业务数据时间转换为基准时区下的数据访问时间。

通过在数据库存储过程写入时区转换关系：基准时区下的时间＝用户时区下的时间+时区时间差，一方面便于高效且准确地将用户时区下的业务数据时间转换为基准时区下的数据访问时间；另一方面，业务数据库可以根据不同的业务需要增加或者减少，而时区的转换也可以根据实际需要(跨时区运营的范围)进行新增或减少，只需要在数据库对外接口库的存储里增加或者减少对应的分支即可，不必根据用户时区新设业务数据库，也不必在业务发生地新建数据库，能够极为简单地实现业务的扩展。

进一步的，结合到数据库对外接口库，可以通过将时区转换关系写入数据库存储过程，以便简单方便地实现转换。例如，时区转换关系可以为数据库存储过程写入的语句：settime_zone＝‘A’，其中，A为时区时间差。由此，即可实现时区快速准确地转换。

利用在数据库存储过程写入的语句：settime_zone＝‘A’，A为时区时间差，即可简单准确地实现用户时区与基准时区之间的转化，将用户时区下的业务数据时间转换为基准时区下的数据访问时间，新增分支时，只需对应增加新的用户时区及对应的A值即可，便于扩展和维护，还可以不停机维护，能够在用户无感知的情况下实现新用户时区业务的开展。

将用户时区下的业务数据时间转换为基准时区下的数据访问时间后，数据库对外接口库可以执行步骤S40。

步骤S40：根据所述数据访问时间和所述业务数据类型，从所述业务数据库获取目标业务数据，其中，所述目标业务数据与所述数据访问时间和所述业务数据类型相对应。

在本实施例中，数据库对外接口库可以根据数据访问时间和业务数据类型，从业务数据库获取目标业务数据(获取的目标业务数据与数据访问时间和业务数据类型相对应)。

示例性的，数据库对外接口库可以将数据访问时间发送给与业务数据类型对应的业务数据库。例如，在业务数据库的数量为多个(至少两个业务数据库存储不同类型的业务数据)时，数据库对外接口库可以从多个业务数据库中确定出存储有业务数据类型对应的业务数据的目标数据库。从而将数据访问时间发送至目标数据库(针对业务数据库存储不止一种类型业务数据的情况，数据库对外接口库也可以将数据访问时间和业务数据类型一起发送给目标数据库，以实际需要为准，此处不作限定)。当然，在业务数据库的数量为一个时，数据库对外接口库即可将数据访问时间和业务数据类型一起发送给目标数据库。

另外，针对业务数据类型同时有多种的情况，可以针对每种业务数据类型，将其与数据访问时间以同发送给该类型对应的目标数据库，以获取目标业务数据，此处不作限定。

任一业务数据库在接收到数据访问时间(或者，接收到数据访问时间和业务数据类型)后，可以基于数据访问时间(或者，接收到数据访问时间和业务数据类型)确定出目标业务数据。确定出目标业务数据后，可以将目标业务数据返回给数据库对外接口库。

接收到业务数据库返回的所有目标业务数据后，数据库对外接口库可以执行步骤S50。

步骤S50：将所述目标业务数据返回所述客户端。

在本实施例中，数据库对外接口库可以将接收到的目标业务数据返回给客户端，从而完成客户端对业务数据的查询。

通过跨时区运营数据库系统包括数据库对外接口库、用户信息库和至少一个业务数据库。用户信息库存储有用户信息(包括用户的唯一ID和时区信息)，可以使得用户信息集中存储，一方面省事可靠，另一方面便于管理，实现起来也简单。所有业务数据库采用同一基准时区存储业务数据，这使得所有的业务数据库具有统一的存储标准，能够避免不同数据库按照不同用户时区存储数据的弊端：数据存储或转换过程不准确导致数据不准确的问题。并且，业务数据库存储业务数据的时间统一，不必考虑用户多时区问题，这样使业务数据库的数据管理更加简单高效。以及，用户信息库和业务数据库分开管理，通过用户信息库获取时区等基本信息，通过业务数据库获取业务数据，这样可以保证数据库的一致性。而数据库对外接口库接收客户端发送的业务数据获取请求(包含用户的唯一ID、业务数据类型、业务数据时间)，将唯一ID发送至用户信息库，确定出对应的用户时区。确定出用户时区与基准时区之间的时区转换关系，从而将业务数据时间转换为基准时区下的数据访问时间；以从业务数据库获取目标业务数据，将目标业务数据返回客户端。这样的方式，客户端与数据库服务器之间的时间时区是相互独立的，可以简化客户端的工程，对于面向用户的客户端来说，不需要关心用户时区转换问题，有利于提高用户软件体验。对于数据库服务器来说，可以为管理人员、运营人员提供具有统一时区的数据，对数据管理、软件运营的效率能够有极大的提升。与此同时，还能够降低软件维护成本，与传统方案使用java或者PHP不同，本方案采用数据库存储过程的方式，极大地简化了代码，使得代码更易理解，程序维护成本更低。此外，使用数据库存储的方案，在修改存储过程时候，可以不停机维护，程序修改维护对于用户是无感知的，这样使得软件体验更加友好。

以上是对跨时区运营数据库系统的运行过程的介绍，以下，将对跨时区运营数据库系统进行进一步的补充介绍。

在本实施例中，跨时区运营数据库系统具有很好的扩张性，且能够通过极为简单的方式实现新增时区的运营。

示例性的，数据库对外接口库还可以接收后台发送的新增指令，其中，新增指令用于指示数据库对外接口库新增时区分支，新增指令中包含新增时区的时区转换关系。而根据新增时区的时区转换关系，数据库对外接口库可以在数据库存储过程写入语句：settime_zone＝‘b’，此处，b为基准时区与该新增时区之间的时区时间差。通过这样的方式能够简单、快速、高效且低成本地实现业务的新增，而不必重新部署程序，修改程序等，可以节省大量的工作，提升运营效率。

另外，针对跨时区运营数据库系统的数据存储方式，也会有适应性的改变。

示例性的，在业务数据库对数据进行存储时，可以先确定数据产生的用户时区，而后可以基于预设的时区转换关系将该用户时区下的时间产生的业务数据转换为基准时区下的时间所对应的业务数据，再进行存储。

因此，客户端与数据库服务器之间的时间时区是相互独立的，可以简化客户端的工程，客户端不需要关心用户时区转换问题，有利于提高用户软件体验。并且，这样可以保证业务数据库中存储的数据的时区一致性，可以为管理人员、运营人员提供具有统一时区的数据，对数据管理、软件运营的效率能够有极大的提升。

本申请实施例还提供一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时，控制所述存储介质所在设备(即数据库对外接口库)执行本实施例中所述的跨时区运营数据查询方法。

综上所述，本申请实施例提供一种跨时区运营数据库系统、数据查询方法、介质及服务器，通过跨时区运营数据库系统包括数据库对外接口库、用户信息库和至少一个业务数据库。用户信息库存储有用户信息(包括用户的唯一ID和时区信息)，可以使得用户信息集中存储，一方面省事可靠，另一方面便于管理，实现起来也简单。所有业务数据库采用同一基准时区存储业务数据，这使得所有的业务数据库具有统一的存储标准，能够避免不同数据库按照不同用户时区存储数据的弊端：数据存储或转换过程不准确导致数据不准确的问题。并且，业务数据库存储业务数据的时间统一，不必考虑用户多时区问题，这样使业务数据库的数据管理更加简单高效。以及，用户信息库和业务数据库分开管理，通过用户信息库获取时区等基本信息，通过业务数据库获取业务数据，这样可以保证数据库的一致性。而数据库对外接口库接收客户端发送的业务数据获取请求(包含用户的唯一ID、业务数据类型、业务数据时间)，将唯一ID发送至用户信息库，确定出对应的用户时区。确定出用户时区与基准时区之间的时区转换关系，从而将业务数据时间转换为基准时区下的数据访问时间；以从业务数据库获取目标业务数据，将目标业务数据返回客户端。这样的方式，客户端与数据库服务器之间的时间时区是相互独立的，可以简化客户端的工程，对于面向用户的客户端来说，不需要关心用户时区转换问题，有利于提高用户软件体验。对于数据库服务器来说，可以为管理人员、运营人员提供具有统一时区的数据，对数据管理、软件运营的效率能够有极大的提升。与此同时，还能够降低软件维护成本，与传统方案使用java或者PHP不同，本方案采用数据库存储过程的方式，极大地简化了代码，使得代码更易理解，程序维护成本更低。此外，使用数据库存储的方案，在修改存储过程时候，可以不停机维护，程序修改维护对于用户是无感知的，这样使得软件体验更加友好。

在本申请所提供的实施例中，应该理解到，所揭露系统和方法，可以通过其它的方式实现。在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

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