A data custom query and statistics method

Abstract

The present invention obtains a request message input according to a preset protocol; verifies the request message to obtain a verification result; when the verification result is a pass state, parses the request message and generates a query statement; performs data query according to the query statement and obtains query data; and encapsulates the query data into a message according to the preset protocol as output. The present invention shields the differences between different types of databases, provides a unified query method, solves the data security risks and ensures data security; enables users to focus only on their own business data; and provides a universal method to solve the problem that some databases are restricted by development languages.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of electronic information technology, and in particular to a method for self-defined data query and statistics. Background Art

[0002] At present, there are three types of database queries: querying through database management tools provided by the database software provider; querying through the development environment compiler, developers accessing the database in their own applications; query tools across database platforms. All of the above methods require direct connection to the database or connection through a database driver, which does not provide high data security protection. Operators need to be familiar with the query methods of different databases, the storage methods of database tables, and complex SQL query methods. Summary of the invention

[0003] In view of this, an embodiment of the present application provides a data custom query statistics method to at least partially solve the above problems.

[0004] In a first aspect, an embodiment of the present application provides a method for self-defined data query statistics, characterized by comprising:

[0005] Obtain a request message input according to a preset protocol;

[0006] Verify the request message and obtain the verification result;

[0007] When the verification result is passed, the request message is parsed and a query statement is generated;

[0008] Perform data query according to the query statement and obtain the query data;

[0009] The query data is encapsulated into a message according to the preset protocol and outputted.

[0010] Optionally, in an implementation manner, verifying the request message to obtain a verification result includes:

[0011] Perform syntax check and semantic check on the request message to obtain the check result.

[0012] Optionally, in one implementation, the syntax check includes:

[0013] Perform Json syntax check on the request message and perform syntax check on the fields of the request message;

[0014] The fields include: business data type fields and non-business data type fields.

[0015] Optionally, in one implementation, the semantic verification includes:

[0016] Perform semantic verification on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

[0017] Optionally, in one implementation, parsing the request message and generating a query statement includes:

[0018] Parse the request message to obtain the parsing result, and generate SQL verification statements based on the parsing result and the pre-defined field query mapping table and keyword function query mapping table;

[0019] When generating SQL query statements, the fields of the request message are converted into field names to achieve isolation between the business side and the data side.

[0020] In a second aspect, an embodiment of the present application provides a data custom query statistics device, characterized by comprising:

[0021] Service interface, validator, parser, executor, and wrapper;

[0022] A service interface is used to obtain a request message input according to a preset protocol;

[0023] A verifier is used to verify the request message and obtain a verification result;

[0024] The parser is used to parse the request message and generate a query statement when the verification result is a pass state;

[0025] Executor, used to query data according to query statements and obtain query data;

[0026] The encapsulator is used to encapsulate the query data into a message according to a preset protocol as output.

[0027] Optionally, in one implementation, the verifier is further used to perform syntax verification and semantic verification on the request message to obtain a verification result.

[0028] Optionally, in one implementation, the verifier is further used to perform a Json syntax check on the request message and perform a syntax check on the fields of the request message;

[0029] The fields include: business data type fields and non-business data type fields.

[0030] Optionally, in one implementation, the verifier is further used to perform semantic verification on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

[0031] Optionally, in one implementation, the parser is further used to parse the request message to obtain a parsing result, and generate an SQL check statement according to the parsing result and a predefined field query mapping table and a keyword function query mapping table;

[0032] When generating SQL query statements, the fields of the request message are converted into field names to achieve isolation between the business side and the data side.

[0033] The present invention obtains a request message input according to a preset protocol; verifies the request message to obtain a verification result; when the verification result is a pass state, parses the request message and generates a query statement; performs data query according to the query statement and obtains query data; and encapsulates the query data into a message according to the preset protocol as output. The present invention shields the differences between different types of databases, provides a unified query method, solves the data security risks and ensures data security; enables users to focus only on their own business data; and provides a universal method to solve the problem that some databases are restricted by development languages. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0035] Figure 1 A flowchart of a method for self-defined data query statistics according to an embodiment of the present application;

[0036] Figure 2 A structural diagram of a data custom query statistics device according to an embodiment of the present application;

[0037] Figure 3 A diagram of an electronic device according to an embodiment of the present application; DETAILED DESCRIPTION

[0038] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the embodiments of the present application should fall within the scope of protection of the embodiments of the present application.

[0039] The specific implementation of the embodiment of the present application is further explained below in conjunction with the accompanying drawings of the embodiment of the present application.

[0040] Embodiment 1

[0041] The present application provides a method for self-defined data query statistics. Figure 1 As shown, the method can be run on a background server, and specifically includes the following steps:

[0042] Step 101: Obtain a request message input according to a preset protocol;

[0043] It should be noted that the preset protocol here is a data protocol using the Json protocol format. JSON (JavaScript Object Notation, JS object notation) is a lightweight data exchange format. It is based on a subset of ECMAScript (js specification developed by the European Computer Association) and uses a text format that is completely independent of the programming language to store and represent data. The concise and clear hierarchical structure makes JSON an ideal data exchange language. It is easy for people to read and write, and it is also easy for machines to parse and generate, and effectively improves network transmission efficiency. Message refers to the data unit exchanged and transmitted in the network, that is, the data block to be sent by the site at one time. The message contains the complete data information to be sent, and its length is very inconsistent, the length is unlimited and variable, and the request message here can be an http request message. By providing a database query method based on the Json protocol with unified syntax to the outside world, users do not have to deal with the differences between different types of databases and the differences in query methods.

[0044] The preset protocol here includes but is not limited to the following requirements, including: business / data type fields, SQL semantic fields, and other fields. Among them, the business / data type field, also known as the business data type field, is used to identify the business data type that needs to be queried, which can be one or more and can be expanded according to actual needs. The SQL semantic field is used to indicate the database operation to be performed. The SQL semantic fields specifically include the following: query / statistics fields, used to support different query / statistics types, such as query, count, sum, etc.; condition fields, used to support different conditional queries, including range, enumeration, equality, fuzzy matching and other conditions; grouping fields: used to explain the display method of query results; sorting: used to explain the sorting basis and sorting method of query results; restriction fields: used to explain the limit on the number of query results. The number of business data involved in the above-mentioned SQL specific fields is dynamically variable within the scope authorized to the user for query, and the custom function of data query / statistics can be realized. Other fields refer to fields that are not directly related to data query, that is, fields that do not participate in the assembly of SQL statements, and can be expanded.

[0045] Below is a protocol format that complies with the preset protocol:

[0046]

[0047] The following is an explanation of the specific fields of the preset protocol: 1. The data item "cxlx" indicates the query type, which is an int type data with a data length of 1 byte. It is a required preset protocol data item used to indicate the type of query data, for example, 0: Class A data, 1: Class B data, 2: Class C data, 4: Class D data, etc. 2. The data item "fjh" indicates the extension number, which is a Varchar type data with a data length of 5 bytes. It is a required preset protocol data item, and its range is an integer from 0 to 29999. 3. The data item "certpwd" indicates the certificate password of the tax control device, which is a Varchar type data with a data length of 20 bytes. It is a required preset protocol data item. 4. The data item "select" indicates the statistics / query item, which is a Json array type data and a required preset protocol data item. In the array, a json object is used to represent the data to be counted / queried. The json object cannot be empty and must have at least one key-value pair. 5. The data item "type" indicates the statistical / query type. It is a Varchar type data with a data length of 1 byte. It is a required preset protocol data item. Among them, type has 3 cases: count: indicates that the following field names need to be counted; sum: indicates that the following field names need to be summed and counted; query: indicates that the following field names need to be queried. 6. The data item "select_field" indicates the "field name" list. It is a Json array type data and a required preset protocol data item. Among them, when the "statistical / query type" is count: the fields in the array are not deduplicated. 7. The data item "where" indicates the statistical / query conditions. It is a Json array type data and a required preset protocol data item. When the user does not need conditions, enter it in the following format: "where":[]. In addition, in the where condition, the conditions represented by different json objects are in an "and" relationship. 8. The data item "type" indicates the condition type. It is a Varchar type data with a data length of 5 bytes. It is a required preset protocol data item. The value of type can be the following three: range: query by range; enum: query by enumeration; like: fuzzy query. 9. The data item "field" indicates the condition field name. It is a Varchar type data and a required preset protocol data item.10. The data item "value" represents the "field value" list, which is a Json array type data and a required preset protocol data item. When the user counts / queries by range, the "field value" input format is as follows, ["value1", "value2"]. When value1≠"", value2="", it means value1≤field value. When value1="", value2≠"", it means field value≤value2. When value1≠"", value2≠"", and value1≤value2, it means: value1≤field value≤value2; when the user counts / queries by enum or like: the number in the "field value" list is not limited. The fields in the "field value" list are in an "or" relationship. For example, if the conditional value passed in is empty ([""]), it includes both null and "" in the database. 11. The data item "group_by" indicates grouping, is a Json array type data, and is a required preset protocol data item. It is used to enter the following format when the user does not need grouping: "group_by":[]. 12. The data item "group_field" indicates the "group field name" list, is a Varchar type data, and is a non-required preset protocol data item. 13. The data item "order_by" indicates sorting, is a Json array type data, and is a required preset protocol data item. It is used to enter the following format when the user does not need sorting: "order_by":[]. 14. The data item "order_field" indicates the "condition field name" list, is a Varchar type data, and is a non-required preset protocol data item. When the user enters the field to be sorted: if ascending / descending sorting is required, add the sorting method after the field name: "asc / desc". The format is ["field name sorting method"]. If the user does not specify the sorting method for the field name, the relevant fields are sorted and output in ascending order by default. 15. The data item "limit" indicates the number of returned messages. It is a Varchar type data with a data length of 1 byte. It is a non-essential preset protocol data item, in which the limit node may or may not be present.

[0048] It should be noted that the key names, i.e. data items, in the above Json protocol message format can also be named differently during the specific implementation process, as long as the specifications provided to the user are the same as the names used in the system. For example, "select" can also be called by other names, such as "choice". For the sake of generality, some keywords of the database are borrowed here. In addition, whether it is the SQL semantic field or other fields in the protocol, they are all variable and extensible, allowing users to customize their own query methods and data, providing users with a flexible way to query / statistics.

[0049] Step 102: Verify the request message and obtain a verification result;

[0050] It should be noted that the verification here is a data verification performed by the system on the legality of the request data entered by the user in accordance with the above protocol format. The verification results are divided into pass status and fail status, which are used to indicate whether the request message meets the requirements of the preset protocol.

[0051] Optionally, in an embodiment, verifying the request message to obtain a verification result includes:

[0052] Perform syntax check and semantic check on the request message to obtain the check result.

[0053] It should be noted that syntax and semantic verification are required when verifying the request message. Preferably, range verification can also be performed, that is, extracting user feature data from the request data and obtaining the authorized field range from the cloud to determine whether the requested field is within the authorized range. By performing syntax and semantic verification on the request message, it is ensured that the request message meets the requirements of the preset protocol.

[0054] Optionally, in one embodiment, the syntax check includes:

[0055] Perform Json syntax check on the request message and perform syntax check on the fields of the request message;

[0056] The fields include: business data type fields and non-business data type fields.

[0057] It should be noted that the syntax check here is to perform a Json syntax check on the entire request message. The fields here include syntax checks on the business / data type field and other fields, specifically the data item name, type, length, and whether it must be checked. Through the above syntax check, it is preliminarily determined whether the syntax of the request message meets the preset protocol requirements, which improves the verification efficiency.

[0058] Optionally, in one embodiment, the semantic verification includes:

[0059] Perform semantic verification on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

[0060] It should be noted that the semantic verification here refers to the verification of part or all of the content of the business / data type fields and other fields according to the specific fields of the above-mentioned preset protocol. The SQL field here refers to the semantic verification of each node, object, list, key-value pair, etc. involved in the "SQL semantic field" to check whether the input request message meets the specified format and combination, and whether it can assemble a complete SQL statement. SQL semantic fields are provided, including: query / statistical fields, condition fields, grouping fields, sorting, restriction and other fields, and the usage of each field is explained, so that even people without SQL basics can understand and enable users to focus on the business data query they need. Through the above semantic verification, it is determined whether the request message can realize the data query function, avoiding problems in subsequent data queries.

[0061] Step 103: When the verification result is in a passed state, the request message is parsed and a query statement is generated;

[0062] It should be noted that when the verification result is a failed state, an error prompt message is returned. Here, parsing the request message and generating a query statement can be expressed as parsing the format and content of the request message, and generating a query statement based on the parsed result.

[0063] Optionally, the request message is parsed and a query statement is generated, including:

[0064] Parse the request message to obtain the parsing result, and generate an SQL verification statement based on the parsing result and the pre-defined field query mapping table and keyword function query mapping table; when generating the SQL query statement, convert the field name of the field of the request message to achieve isolation between the business side and the data side.

[0065] It should be noted that when generating SQL statements, all fields in the request message, that is, fields open to users, need to be converted into field names for internal use. This is to isolate the business side from the data side and ensure data security. The field name conversion of the fields in the request message here includes the following steps.

[0066] The first step is to define the field query mapping table; the field query mapping table includes two parts: open data and internal data. The open data part includes the request field name, and the internal data part includes the internal field name, internal field type, query table name, field value conversion, internal function name, return field processing method, and associated fields. For each data open to users for query, there is an internal mapping relationship as above. The mapping relationship of all open data is the field mapping table. The meaning of each field is as follows: Request field name: a combination field containing data fields open to users for query and "query / statistical field" information. Internal field name: the field name used by the internal database. For some request fields, it may correspond to a combination of multiple internal fields, that is, multiple internal data fields need to be queried to obtain the data required by the user. Internal field type: the type of database table field. Query table name: in the SQL statement, the table name after from can be a subquery. Field value conversion: for data with the same meaning, the data value open to users and the internal data value will be different. Here it is used to indicate the conversion / mapping relationship between them. Internal function name: for some fields, the database internal function needs to be used to participate in the implementation of the SQL statement query. Processing method of returned fields: Indicates whether the query data of this field needs special processing before being returned to the user, including but not limited to aggregation processing: According to business requirements, data from different sources are aggregated to obtain the business data required by the user. Associated fields: Indicates that the requested field requires other internal data fields to participate in the query. The second step is to define the "keyword-function query" mapping table, which can also be called the keyword function query mapping table; that is, for the keywords involved in the protocol specifications open to users, such as different query types (sum, count, query), different condition types (range, enum, like), grouping and sorting, there are corresponding function operations. The function completes the encapsulation of the corresponding SQL clause under the keyword based on the fields input in the request message and combined with the "field query mapping table". The third step is to parse the Json request message and assemble a complete SQL query statement. Specifically, the Json message is parsed, and when different keywords are parsed, the corresponding function is automatically called to generate the corresponding SQL clause. When the Json message is parsed, all SQL clauses are also generated. Finally, according to the syntax of the database SQL query, the SQL clauses are combined into a complete SQL statement, and the target data source is determined according to the requested field. It can be read from the hardware or through the software database. Through the above specific steps, when the SQL check statement is generated according to the parsing results and the pre-defined field query mapping table and keyword function query mapping table, the field name of the request message field is converted, which realizes the isolation of the business side and the data side and ensures the security of the data.

[0067] Step 104: perform data query according to the query statement and obtain query data;

[0068] It should be noted that the query statement here may include a business identification field, a target data source, a database version, an SQL statement, etc. The business identification field here is used to determine whether data needs to be obtained from a hardware device or a software database, or both; the target data source here is used to obtain data from the corresponding target data source, where the target data source includes a hardware device and a software database; the database version here is used to execute different query logics. In addition, if data is read from a software database, an SQL statement query is executed. After the data is queried according to the query statement, the data obtained from different target data sources are assembled and merged as the final query data.

[0069] Step 105: Encapsulate the query data into a message according to a preset protocol as output.

[0070] It should be noted that the query data is encapsulated in a message according to the preset protocol here, and as output, it means parsing and processing the query data, encapsulating the message according to the preset protocol provided to the external docking specification, and using the encapsulated message as output, and finally returning it to the user. Specifically, according to the preset protocol, the preset protocol here can be an internal protocol, that is, a communication protocol between the executor and the encapsulator, the query data is parsed, the number name and data value of the query data are obtained, and then some special processing is performed on the query data: such as valid bits, data length, calculation of associated fields, how to return different permissions, data aggregation processing, etc. Finally, the internal field name is converted into the request field name of the preset protocol, and the message is encapsulated and returned to the user call as output. The following is an achievable message encapsulation format: [

[0072] {"field1":"value","field2":"value","field3":"value",…},

[0073] {"field1":"value","field2":"value","field3":"value",…},

[0074] {"field1":"value","field2":"value","field3":"value",…}, ... ]

[0077] Here, the data items of the message encapsulation format are explained: 1. The data item "field" represents the field name, which is a Varchar type data and a required preset protocol data item, including the field names of statistics / query and grouping; 2. The data item "value" represents the field value, which is a Varchar type data and a required preset protocol data item. It returns an object in the Json array, representing a row in the data query record.

[0078] The present invention obtains a request message input according to a preset protocol; verifies the request message to obtain a verification result; when the verification result is a pass state, parses the request message and generates a query statement; performs data query according to the query statement and obtains query data; and encapsulates the query data into a message according to the preset protocol as output. The present invention shields the differences between different types of databases, provides a unified query method, solves the data security risks and ensures data security; enables users to focus only on their own business data; and provides a universal method to solve the problem that some databases are restricted by development languages.

[0079] Embodiment 2

[0080] Embodiment 2 of the present application provides a data self-defined query statistics device, referring to Figure 2 As shown, it is characterized by comprising:

[0081] Service interface, validator, parser, executor, and wrapper;

[0082] The service interface is used to obtain the request message input according to the preset protocol; the verifier is used to verify the request message and obtain the verification result; the parser is used to parse the request message and generate a query statement when the verification result is a pass state; the executor is used to query data according to the query statement and obtain the query data; the encapsulator is used to encapsulate the query data into a message according to the preset protocol as output.

[0083] It should be noted that the above service interface, verifier, parser, wrapper, and executor can be directly deployed on the same computer or on different computers using network communication to meet the query requirements of different business query scenarios and different performance requirements. The executor can automatically identify the business data and target data source to be queried based on the incoming data, execute related data queries to obtain data, abstract the query logic for different target data sources, and execute it uniformly, so as to return the queried data to the wrapper according to the internal protocol specifications to ensure data isolation and security. The encapsulator can use different protocols for internal and external communication, parse the internally obtained data, and perform automatic special processing on the returned fields according to the "return field processing method" in the "field query mapping table", and then encapsulate the returned data in accordance with the return format of the docking specification; through different internal and external protocols and the "field query mapping table", the business logic is separated from the data query, data security is ensured, and information aggregation query is realized, and complex SQL statement queries such as multi-database query, multi-table union, field association, SQL function operation, etc. are shielded from users. The invention automatically implements these complex operations and aggregates data from different sources to obtain the data required by users, so that users only focus on data closely related to the business.

[0084] Optionally, in one embodiment, the verifier is further used to perform syntax verification and semantic verification on the request message to obtain a verification result.

[0085] It should be noted that the validator can flexibly control the data range of authorized users by configuring authorization fields in the cloud, implement data legitimacy verification through local field range verification, and ensure data security from the entry point; perform syntax verification on the requested data to ensure that the syntax is correct, and perform semantic verification on the requested data to ensure that the data requested by the user can be assembled into a valid SQL statement.

[0086] Optionally, in one embodiment, the verifier is further used to perform Json syntax verification on the request message and perform syntax verification on the fields of the request message;

[0087] The fields include: business data type fields and non-business data type fields.

[0088] Optionally, in one embodiment, the verifier is further used to perform semantic verification on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

[0089] Optionally, in one embodiment, the parser is further used to parse the request message to obtain a parsing result, and generate an SQL check statement according to the parsing result and a predefined field query mapping table and a keyword function query mapping table;

[0090] When generating SQL query statements, the fields of the request message are converted into field names to achieve isolation between the business side and the data side.

[0091] It should be noted that the parser realizes the assembly of SQL statements for each field requested by the user through the "field query mapping table", and realizes the automatic assembly of corresponding SQL query clauses for different SQL keywords through the "keyword-function query". Based on the above two points, the complete SQL statement is automatically assembled by parsing the request Json message and traversing the relevant SQL nodes. It is also possible to use different names for open data and internal data and establish mapping relationships through the "field query mapping table" to achieve data isolation and ensure data query security.

[0092] Embodiment 3

[0093] Combined with the data self-defined query statistics method described in the above embodiment 1, refer to Figure 3 As shown, the third embodiment of the present application provides an electronic device, including: a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus;

[0094] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute operations corresponding to the data self-defined query statistics method described in the first embodiment above.

[0095] Embodiment 4

[0096] In combination with the data customized query statistics method described in the above embodiment 1, embodiment 4 of the present application provides a computer storage medium on which a computer program is stored. When the program is executed by a processor, the data customized query statistics method described in the above embodiment 1 is implemented.

[0097] Embodiment 5

[0098] In combination with the data customized query statistics method described in the above embodiment 1, embodiment 5 of the present application provides a computer program product, including computer instructions, which instruct a computing device to perform operations corresponding to the data customized query statistics method described in the above embodiment 1.

[0099] The above implementation modes are only used to illustrate the embodiments of the present application, and are not intended to limit the embodiments of the present application. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the spirit and scope of the embodiments of the present application. Therefore, all equivalent technical solutions also belong to the scope of the embodiments of the present application, and the scope of patent protection of the embodiments of the present application should be defined by the claims. The systems, devices, modules or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0100] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0101] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0102] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0103] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0104] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0105] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0106] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0107] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0108] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0109] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0110] The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific transactions or implement specific abstract data types. The present application may also be practiced in distributed computing environments where transactions are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0111] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. A data self-defined query and statistics method, characterized in that: include: Obtain a request message input according to a preset protocol; Verifying the request message to obtain a verification result; When the verification result is a pass state, the request message is parsed and a query statement is generated; Perform data query according to the query statement and obtain query data; Encapsulating the query data into a message according to the preset protocol as output; The parsing of the request message and generating a query statement includes: parsing the request message to obtain a parsing result, generating an SQL query statement according to the parsing result and a predefined field query mapping table and a keyword function query mapping table; when generating the SQL query statement, performing field name conversion on the fields of the request message to achieve isolation between the business side and the data side; The converting of the field names of the fields of the request message includes: The first step is to define the field query mapping table. The field query mapping table includes two parts: open data and internal data. The open data part includes the request field name; the internal data part includes: internal field name, internal field type, query table name, field value conversion, internal function name, return field processing method, and related fields. The second step is to define a "keyword-function query" mapping table, also known as a keyword function query mapping table; The third step is to parse the Json request message and assemble a complete SQL query statement, specifically: parse the Json message into different keywords, query the mapping table in combination with the keyword function, and generate corresponding SQL clauses; when the Json message is parsed, combine the SQL clauses into a complete SQL statement according to the syntax of the SQL query.

2. The data self-defined query and statistics method according to claim 1 is characterized in that: The verifying the request message to obtain a verification result includes: The request message is subjected to syntax check and semantic check respectively to obtain a check result.

3. The data self-defined query and statistics method according to claim 2 is characterized in that: The grammar check includes: Performing a Json syntax check on the request message and performing a syntax check on the fields of the request message; The fields include: a business data type field and a non-business data type field.

4. The data self-defined query and statistics method according to claim 2 is characterized in that: The semantic verification includes: A semantic check is performed on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

5. A data self-defined query and statistics device, characterized in that: include: Service interface, validator, parser, executor, and wrapper; The service interface is used to obtain a request message input according to a preset protocol; The verifier is used to verify the request message and obtain a verification result; The parser is used to parse the request message and generate a query statement when the verification result is a pass state; The executor is used to perform data query according to the query statement and obtain query data; The encapsulator is used to encapsulate the query data into a message according to the preset protocol as output; The executor is further used to parse the request message to obtain a parsing result, and generate an SQL query statement according to the parsing result and a predefined field query mapping table and a keyword function query mapping table; when generating the SQL query statement, the field name of the request message is converted to achieve isolation between the business side and the data side; The converting of the field names of the fields of the request message includes: The first step is to define the field query mapping table. The field query mapping table includes two parts: open data and internal data. The open data part includes the request field name; the internal data part includes: internal field name, internal field type, query table name, field value conversion, internal function name, return field processing method, and related fields. The second step is to define the "keyword-function query" mapping table; The third step is to parse the Json request message and assemble a complete SQL query statement, specifically: parse the Json message into different keywords, query the mapping table in combination with the keyword function, and generate corresponding SQL clauses; when the Json message is parsed, combine the SQL clauses into a complete SQL statement according to the syntax of the SQL query.

6. The data self-defined query and statistics device according to claim 5, characterized in that: The verifier is also used to perform syntax verification and semantic verification on the request message to obtain verification results.

7. The data self-defined query and statistics device according to claim 6, characterized in that: The verifier is also used to perform Json syntax verification on the request message and perform syntax verification on the fields of the request message; The fields include: a business data type field and a non-business data type field.

8. The data self-defined query and statistics device according to claim 6, characterized in that: The verifier is also used to perform semantic verification on the SQL field of the request message to determine whether the request message can form a complete SQL statement.

Images