CN111813804B - Data query method and device, electronic equipment and storage medium - Google Patents

Data query method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN111813804B
CN111813804B CN201910289290.9A CN201910289290A CN111813804B CN 111813804 B CN111813804 B CN 111813804B CN 201910289290 A CN201910289290 A CN 201910289290A CN 111813804 B CN111813804 B CN 111813804B
Authority
CN
China
Prior art keywords
data
dimension
physical table
analysis request
physical
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.)
Active
Application number
CN201910289290.9A
Other languages
Chinese (zh)
Other versions
CN111813804A (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.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
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 Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN201910289290.9A priority Critical patent/CN111813804B/en
Publication of CN111813804A publication Critical patent/CN111813804A/en
Application granted granted Critical
Publication of CN111813804B publication Critical patent/CN111813804B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The invention discloses a data query method, a data query device, electronic equipment and a storage medium. Receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field; for each index data, determining whether preset logic metadata consistent with the current index data exists in at least one piece of logic metadata, if so, determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, and inquiring data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table; and splicing the queried data and returning the spliced data to the service end. By the technical scheme, the data management efficiency in the database is improved.

Description

Data query method and device, electronic equipment and storage medium
Technical Field
The embodiment of the invention relates to a big data management technology, in particular to a data query method, a device, electronic equipment and a storage medium.
Background
With the rapid development of information technology, more and more data needs to be managed in large data platform products, and the increasing amount of data makes management and use of such data more difficult.
Currently, database technology is commonly used to store and manage data. The service end can inquire the data in the database. For different service requirements/scenes (each service requirement/scene corresponds to a service model, the service model is used for representing data requiring query), different database tables (the database tables are called physical models corresponding to the service models and are used for representing a data source table where the data requiring query is located and association relations of the data source table) need to be established in advance respectively, and binding relations between the database tables and the service models are established for the service party to query. The fields contained in the established database table have a one-to-one correspondence with the fields which can be queried under the corresponding service requirement/scene, and the database table can be one of a plurality of data source tables or can be generated based on the plurality of data source tables. For example, fields that may be specified for a service end to query for a certain service requirement/scenario include: company ID, consumption, number of presentations and budget, assuming 4 data source tables, data source table 1 (account consumption table) includes the following fields: account ID and consumption; the data source table 2 (account presentation number table) includes the following fields: account ID and number of presentations; the data source table 3 (company and account association table) includes the following fields: company ID and account ID; the data source table 4 (company budget table) includes the following fields: company ID and budget; then, it is necessary to generate a database table including 4 fields of company ID, consumption, number of presentations, and budget by aggregating these 4 data source tables. After receiving a service analysis request from a service end, extracting service model data carried in the service analysis request, wherein the service model data comprises dimension data and index data, and the dimension data and the index data correspond to fields needing to be queried; according to the binding relation between the pre-established database table and the service model, determining the database table corresponding to the service model data carried in the service analysis request, then inquiring from the database table to obtain the required data, and returning the inquired data to the service end.
The scheme defect of the service end for inquiring the data in the database is as follows: the database tables are respectively pre-established for each service requirement/scene, and when the service requirement/scene is expanded, a new database table is required to be established and the binding relation is increased correspondingly, so that the expandability is poor, and the management and maintenance cost of the database is greatly increased; when there is an intersection between different business needs/scenarios, a database table needs to be repeatedly built for the data of the intersection part, resulting in poor flexibility of metadata.
Disclosure of Invention
The invention provides a data query method, a data query device, electronic equipment and a storage medium, so as to improve the data management efficiency in a database.
In a first aspect, an embodiment of the present invention provides a data query method, where the method includes:
receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field;
for each index data, determining whether preset logic metadata consistent with the current index data exists in at least one piece of logic metadata, if so, determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, and inquiring data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table;
And splicing the queried data and returning the spliced data to the service end.
In a second aspect, an embodiment of the present invention further provides a data query apparatus, where the apparatus includes:
the receiving module is used for receiving a user analysis request sent by the service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field;
the determining module is used for determining whether logic metadata consistent with the current index data exists in at least one preset logic metadata or not for each index data;
the query module is used for determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata when determining that the preset logic metadata consistent with the current index data exists in the preset at least one logic metadata, and querying data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table;
and the return module is used for splicing the queried data and returning the spliced data to the service end.
In a third aspect, an embodiment of the present invention further provides an electronic device, including:
one or more processors;
storage means for storing one or more programs,
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the data query method of any of claims 1-7.
In a fourth aspect, embodiments of the present invention also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a data query method as claimed in any of claims 1 to 7.
The method comprises the steps of receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field; for each index data, determining whether preset logic metadata consistent with the current index data exists in at least one piece of logic metadata, if so, determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, and inquiring data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table; finally, the technical means of splicing the queried data and returning the spliced data to the service end is realized, the service model (each service requirement/scene corresponds to a service model which is used for representing the data requiring query) and the physical model (the database table which is pre-established according to each service model and contains target data) are completely decoupled, the database table is not needed to be established by aggregation of the data source table, when the service model changes, the change of the database table is not caused, the flexibility and maintainability of the data are improved, the situation that each service requirement/scene corresponds to one database table is avoided by taking a field as a management unit, the reusability and expandability of the data are improved, and the data management efficiency in the database is improved.
Drawings
FIG. 1 is a flow chart of a data query method according to a first embodiment of the invention;
FIG. 2 is a schematic diagram showing a format of a user analysis request according to a first embodiment of the present invention;
FIG. 3 is a flow chart of a data query method in a second embodiment of the invention;
FIG. 4 is a schematic diagram of a target data query model according to a second embodiment of the present invention;
FIG. 5 is a schematic diagram of a target data query model in a specific business scenario in a second embodiment of the present invention;
FIG. 6 is a flow chart of a data query method in a third embodiment of the present invention;
fig. 7 is a schematic structural diagram of a data query device according to a fourth embodiment of the present invention;
fig. 8 is a schematic structural diagram of an electronic device according to a fifth embodiment of the present invention.
Detailed Description
The invention is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the structures related to the present invention are shown in the drawings.
Example 1
Fig. 1 is a flowchart of a data query method according to a first embodiment of the present invention, where the method may be applicable to a case of querying target data requested by a service end in a massive database resource, and the method may be performed by a data query device, where the data query device is generally integrated in a terminal, and typically, the terminal may be a server. Referring to fig. 1, the data query method specifically includes the following steps:
Step 110, receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field.
Specifically, referring to a schematic format of a user analysis request shown in fig. 2, the dimension data includes two primary key fields, which are respectively represented as a primary key field 1 and a primary key field 2. The user analysis request is formulated according to specific service requirements/scenes, and the user analysis request is different for different service requirements/scenes, for example, the service scenes are specifically: and counting consumption conditions of the first-class industry in the south China, wherein the corresponding user analysis request can be: consumption data of the first-class industry in south China. The dimension data refers to the angle of the service end requesting for inquiring data, the index data refers to specific data of the service end requesting for inquiring, for example, in the user analysis request 'consumption data of first-class industry in south China', the corresponding dimension data is: south China (which can be defined as a main key field 1), primary industry (which can be defined as a main key field 2), and corresponding index data are as follows: consumption data; in the user analysis request "budget of a company a", the corresponding dimension data is: the corresponding index data of the company are: budget. The field to be queried included in each index data may be each index data itself, for example, the index data is: consuming data, the fields to be queried may be: consuming; the index data are: budget, then the fields to be queried may be: budget. The primary key field included in the dimension data may be the dimension data itself, for example, when the dimension data is: when in company, the corresponding primary key fields are: companies.
Step 120, for each index data, determining whether preset logic metadata consistent with the current index data exists in at least one logic metadata, if so, determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, and inquiring data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table.
The physical table is a data source table storing various specific values in the database, and fields included in the physical table are meaning of data stored in the current physical table, for example, assuming that the current physical table is a table storing budgets of each company, the meaning of the data stored in the current physical table is: each company budget, corresponding fields may be "budget" and "company ID"; assuming that the current physical table is a table for storing the showing times of each account, the meaning of the data stored in the current physical table is as follows: the number of times each account is presented, and the corresponding fields can be the number of times of presentation and the account ID. The physical table bound with the logical metadata may be a physical table containing the same fields as the logical metadata and an association table representing the association between the fields contained in the physical table and other fields, for example, when the logical metadata is "consumed", the physical table bound with the logical metadata may include: account consumption tables and account and company association tables. The more data source tables, i.e. the physical tables, storing various specific values in the database, the more logic metadata are preset, and the more the database can provide query functions.
For each index data, determining whether logic metadata consistent with the current index data exists in preset logic metadata or not respectively, if so, determining a physical table matched with the dimension data from physical tables bound with the logic metadata, and inquiring data from the determined physical tables based on the current index data and the dimension data; for example, the user analysis request sent by the service end is: if the consumption of the company A exists in the preset logic metadata, and meanwhile, the physical tables bound with the logic metadata comprise a consumption table of each company and a consumption table of each region, the physical table matched with the company A (namely the consumption table of each company) is determined from the physical tables bound with the metadata (the consumption table of each company and the consumption table of each region) according to the dimension data of the company A in the user analysis request sent by the service end, and the data is queried from the determined physical tables of each company based on the current index data of the company A and the dimension data of the company A. If the preset logic metadata does not contain the logic metadata consistent with the current index data, returning the current index data, and prompting prompt information such as 'no inquiry' or 'no inquiry result' and the like; or directly jumps to the processing operation for the next index data.
And 130, splicing the queried data and returning the spliced data to the service end.
Specifically, if the user analysis request sent by the service end only includes one index data, the queried data is directly returned to the service end; if the user analysis request sent by the service end includes a plurality of index data, the queried data is spliced according to the request sequence and then returned to the service end, for example, the index data requested in the user analysis request sent by the service end is sequentially the consumption, the display times and the budget of the company A, and the queried data about the display times, the consumption and the budget of the company A is spliced in sequence according to the sequence of consumption-display times-budget and then returned to the service end, so that the user can conveniently review and the readability of the data is improved.
According to the technical scheme, the fields contained in the physical table are used as management units, binding relations between the fields and the physical table are pre-established, after a user analysis request comprising the fields to be queried sent by a service end is received, whether the preset fields which are the same as the fields to be queried exist or not is determined, if the preset fields exist, the physical table which is matched with dimension data corresponding to the fields to be queried is determined from the physical table bound with the preset fields, the data are queried from the determined physical table based on the fields to be queried and the corresponding dimension data, the fact that a service model (corresponding to one service model for each service requirement/scene and used for representing data requiring query) and a physical model (a database table which is pre-established according to each service model and contains target data) are completely decoupled is achieved, aggregation of the physical table is not needed to be performed to establish the database table, when the service model changes, the change of the database table is not caused, the flexibility and the maintainability of the data are improved, the situation that the service requirement/scene is corresponding to each service requirement/scene is used as management units is used for querying the determined, the data in the determined, the database is further improved, and the data multiplexing efficiency is improved.
Example two
Fig. 3 is a flowchart of a data query method according to a second embodiment of the present invention, where, based on the foregoing embodiment, the step of determining, from at least one physical table bound with the logical metadata, a physical table matching with the dimension data is optimized, and the benefit of the optimization is that accurate matching of a target physical table can be achieved, so that quick query of target data is achieved. Referring to fig. 3, the data query method specifically includes the following steps:
step 310, receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field.
Step 320, for each index data, determining whether there is logic metadata consistent with the current index data in at least one preset logic metadata, and if so, continuing to execute step 330, where each logic metadata is a field included in at least one existing physical table.
Step 330, if there is a physical table with dimension data consistent with dimension data contained in the user analysis request in at least one physical table bound with the logical metadata, determining the physical table with dimension data consistent with dimension data contained in the user analysis request as a physical table matched with dimension data contained in the user analysis request; the dimension data of each physical table corresponds to a primary key field in the physical table.
Specifically, referring to fig. 4, a schematic diagram of a target data query model may be shown, where a user analysis request 410 sent by a service end includes: the dimension data 411 and at least one index data 412, the preset logical metadata are fields contained in at least one existing physical table, and the physical table further includes dimension data, where the dimension data corresponds to a primary key field in the physical table. After receiving the user analysis request sent by the service end, determining whether logic metadata consistent with the current index data exists in preset logic metadata (assumed that the current index data is 412) respectively, if so (assumed that the logic metadata consistent with the current index data 412 is 421), further judging whether a physical table consistent with the dimension data 411 contained in the user analysis request exists in a physical table bound with the logic metadata 421, and if so (assumed that the dimension data 431 of the physical table 430 is consistent with the dimension data 411), determining the physical table 430 as a physical table matched with the dimension data 411 contained in the user analysis request. Further, referring to a schematic diagram of a target data query model in a specific service scenario shown in fig. 5, it is assumed that dimension data included in a user analysis request sent by a service end is: company ID, including index data of: the consumption, the showing times and the budget are respectively as follows: each company consumption table, each company display order table and each company budget table, and corresponding preset logic metadata are respectively: the consumption, the number of times of presentation and the budget, the physical table bound to the logical metadata "consumption" includes the consumption table of each company, the physical table bound to the logical metadata "number of times of presentation" includes the budget table of each company, according to the operations of steps 320-330, for each index data (consumption, number of times of presentation, budget), it is determined whether there is logical metadata consistent with the current index data in the preset logical metadata (consumption, number of times of presentation, budget), if there is, it is further determined whether there is a physical table consistent with the dimension data (company) contained in the user analysis request in the physical table bound to the logical metadata, in this example, the dimension data of the physical table bound to the logical metadata is consistent with the dimension data contained in the user analysis request, therefore, the physical table consistent with the dimension data contained in the user analysis request is determined as a physical table matching the dimension data contained in the user analysis request, and finally, it is possible to match the physical table matching each consumption table, each company and each budget, based on the target ID of the physical table contained in the user analysis request.
And 340, generating a database query statement based on the current index data, the dimension data contained in the user analysis request and the determined physical table, and querying the data by executing the database query statement.
Specifically, for example, the dimension data included in the user analysis request is: company ID, for example, company a, current index data is: the consumption, the determined physical table is the consumption table of each company, and the generated database query statement is: and inquiring the consumption data of the company A in the consumption tables of the companies, and executing the database inquiry statement to obtain target data.
And 350, splicing the queried data and returning the spliced data to the service end.
The index data included in the user analysis request sent by the service end is assumed to be: and (3) the consumption, the showing times and the budget, and then the queried data are spliced according to the order of consumption, showing times and budget and returned to the service end.
According to the technical scheme, the fields contained in the physical table are used as management units, binding relations between the fields and the physical table are established in advance, after a user analysis request comprising a field to be queried sent by a service end is received, whether a preset field identical to the field to be queried exists or not is determined, if so, whether a physical table with dimension data consistent with the dimension data contained in the user analysis request exists in at least one physical table bound with the preset field or not is determined, if so, the physical table with dimension data consistent with the dimension data contained in the user analysis request is determined to be the physical table matched with the dimension data contained in the user analysis request, and therefore accurate matching of a target physical table is achieved, rapid query of the target data is achieved, and further data management efficiency in a database is improved.
Example III
Fig. 6 is a flowchart of a data query method according to a third embodiment of the present invention, where, based on the foregoing embodiment, the step of determining, from at least one physical table bound with the logical metadata, a physical table matching the dimension data is further optimized, and referring to fig. 6, the data query method specifically includes the following steps:
step 610, receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field.
Step 620, for each index data, determining whether there is logic metadata consistent with the current index data in at least one preset logic metadata, and if so, continuing to execute step 630, where each logic metadata is a field included in at least one existing physical table.
Step 630, if there is no physical table with dimension data consistent with the dimension data contained in the user analysis request in the at least one physical table bound with the logic metadata, acquiring a dimension level of each physical table bound with the logic metadata, and screening one physical table from each physical table bound with the logic metadata based on the dimension level as a physical table matched with the dimension data contained in the user analysis request.
The dimension level specifically refers to an upper relationship and a lower relationship between dimensions, for example, the dimension level of a company is greater than the dimension level of an account, each company can have a plurality of accounts, the company is an upper concept of the account, and the account is a lower concept of the company; for another example, the dimension level of the "primary industry" is greater than the dimension level of the "secondary industry", and the primary industry includes multiple classes of secondary industries. The dimension level of each physical table may be defined and marked manually when importing the corresponding physical table.
Illustratively, the filtering a physical table from the physical tables bound to the logical metadata based on the dimension level as a physical table matching dimension data contained in the user analysis request includes:
based on the dimension level, screening out physical tables with dimension level lower than the dimension level corresponding to the dimension data contained in the user analysis request from the physical tables bound with the logic metadata;
if one physical table is screened out, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
if a plurality of physical tables are screened, a physical table with the smallest difference between the dimension level and the dimension level corresponding to the dimension data contained in the user analysis request is screened out from the screened physical tables again;
If one physical table is screened again, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
and if the plurality of physical tables are screened again, selecting the physical table with the smallest data quantity from the screened physical tables as the physical table matched with the dimension data contained in the user analysis request.
The above process of screening out physical tables matching the dimension data contained in the user analysis request from among the physical tables bound to the logical metadata based on the dimension level is exemplified:
suppose that the dimension data contained in the user analysis request is: the client comprises the following index data: consuming; each physical table bound with the preset logic metadata consumption is respectively: tables 1 and 2, wherein the dimension data and fields of tables 1-2 are:
TABLE 1 Account, consumption
TABLE 2 geographical and Consumer consumption
The user analysis request is: customer, consumption
The dimension level of the dimension data 'region' of the table 2 is higher than the dimension level of the dimension data 'client' in the user analysis request, so that the target data of the user request cannot be queried from the table 2, the table 2 is filtered out, and the dimension level of the dimension data 'account' of the table 1 is lower than the dimension level of the 'client' in the user analysis request, and only the table 1 is used as a physical table matched with the dimension data 'client' contained in the user analysis request.
Suppose again that the dimension data contained in the user analysis request is: the index data contained in the client and the primary industry are as follows: consuming; each physical table bound with the preset logic metadata consumption is respectively: table 1, table 2, table 3 and table 4, wherein the dimension data and fields of table 1 to table 4 are respectively:
TABLE 1 Account, primary industry, consumption
Table 2 customer, secondary industry, consumption
TABLE 3 Account, secondary industry, consumption
TABLE 4 territory, primary industry, consumption
The user analysis request is: customer, primary industry, consumption
Because the dimension level of the dimension data 'region' of the table 4 is higher than the dimension level of the dimension data 'client' in the user analysis request, the target data of the user request cannot be queried from the table 4, and the table 4 is filtered; because the dimension level of the dimension data 'account' of the table 1 is lower than the dimension level of the 'client' in the user analysis request, the dimension level of the dimension data 'primary industry' of the table 1 is equal to the dimension level of the 'primary industry' in the user analysis request, so that the dimension level of the dimension data of the table 1 is lower than the dimension level of the dimension data in the user analysis request as a whole, and therefore the table 1 is reserved; the dimension level of the dimension data "client" in the table 2 is equal to the dimension level of the dimension data "client" in the user analysis request, while the dimension level of the dimension data "secondary industry" in the table 2 is lower than the dimension level of the dimension data "primary industry" in the user analysis request, so that the dimension level of the dimension data of the table 2 is lower than the dimension level of the dimension data in the user analysis request as a whole, and therefore, the table 2 is reserved; the dimension level of the dimension data "account" of table 3 is lower than the dimension level of the "client" in the user analysis request, and the dimension level of the dimension data "secondary industry" of table 3 is lower than the dimension level of the "primary industry" in the user analysis request, so the dimension level of the dimension data of table 3 is lower than the dimension level of the dimension data in the user analysis request as a whole, and thus table 3 is reserved.
Through the first round of screening, a plurality of physical tables (table 1, table 2 and table 3) are screened out; further, the physical table with the smallest difference between the dimension level and the dimension level corresponding to the dimension data contained in the user analysis request is screened out from the screened physical tables, and through the screening process of the first round, it is known that only one dimension data "account" in table 1 is lower than the dimension level of the "client" in the user analysis request, only one dimension data "secondary industry" in table 2 is lower than the dimension level of the "primary industry" in the user analysis request, and two dimension data "account" and "secondary industry" in table 3 are respectively lower than the dimension levels of the "client" and the "primary industry" in the user analysis request, so compared with table 1 and table 2, the difference between the dimension level of table 3 and the dimension level corresponding to the dimension data contained in the user analysis request is the largest, and table 3 is filtered out.
Through the second round of screening, a plurality of physical tables (table 1 and table 2) are screened again, so that the physical table with the smallest data amount is required to be selected from the physical tables (table 1 and table 2) screened again as the physical table matched with the dimension data contained in the user analysis request, assuming that the data amount in table 1 has 100 pieces and the data amount in table 2 has 300 pieces, table 2 is filtered out, table 1 is reserved, and finally table 1 is determined as the physical table matched with the dimension data (client, first-class industry) contained in the user analysis request.
Step 640, determining a dimension table, where the fields of the dimension table include a primary key field corresponding to the dimension data included in the user analysis request and a primary key field of a physical table matched with the dimension data included in the user analysis request.
Continuing with the above example, assume that the dimension data contained in the user analysis request is: the primary key fields corresponding to the client industry and the primary industry are as follows: customer, primary industry; the physical table matching the dimension data contained in the user analysis request is table 1, and the primary key field of table 1 is: account, primary industry. The fields of the determined dimension table include: the corresponding relation between the client and the account can be determined and marked manually or automatically by calling the association table between the client and the account.
Step 650, generating a database query statement based on the dimension table, the physical table matched with the dimension data contained in the user analysis request, the current index data and the dimension data contained in the user analysis request, and querying data by executing the database query statement.
Continuing with the above example, the generated database query statement is: and determining an account corresponding to the current customer in the dimension table, and inquiring consumption data of the primary industry of the account corresponding to the current customer in the table 1.
Step 660, the queried data is spliced and returned to the service end.
According to the technical scheme, the physical tables matched with the dimension data contained in the user analysis request are screened out from the physical tables bound with the logic metadata based on the dimension level of the physical tables, so that the target physical tables are quickly and accurately searched, and the target data is quickly searched.
Further, the dimension data included in the user analysis request may further include a first query range of a primary key field corresponding to the field to be queried, and the current index data further includes a second query range of the corresponding field to be queried;
correspondingly, the generating a database query statement based on the dimension table, the physical table matched with the dimension data contained in the user analysis request, the current index data, and the dimension data contained in the user analysis request includes:
generating a third database query sentence obtained by connecting the first database query sentence and the second database query sentence, wherein,
a first database query statement, configured to query, in the dimension table, field content data of a primary key field of the matched physical table, with a primary key field and a first query range corresponding to dimension data included in the user analysis request as query conditions;
And the second database query statement is used for searching the field content data of the field to be queried corresponding to the current index data in the matched physical table by taking the field content data queried by the first database query statement and the second query range as query conditions.
For example, the primary key field corresponding to the dimension data included in the user analysis request is: the client, the current index data is: consumption, the fields to be queried included in the current index data are as follows: the main key field corresponding to the consumption of the field to be queried is as follows: a customer; the first query range of the primary key field (client) corresponding to the field to be queried (consumption) is as follows: clients in North China; the second query range of the corresponding field to be queried (consumption) included in the current index data (consumption) is as follows: consumption data with a consumption amount greater than 1000; for the user analysis request, generating a database query statement based on the dimension table, a physical table matched with dimension data included in the user analysis request, current index data, and dimension data included in the user analysis request includes: generating a third database query statement obtained by connecting a first database query statement and a second database query statement, wherein the first database query statement is used for searching accounts corresponding to all clients in North China in the dimension table, and the second database query statement is used for querying consumption data with the consumption amount larger than 1000 of each account corresponding to all clients in North China in a matched physical table; the user analysis request comprises a main key field (client) corresponding to dimension data, a first query range (North China) is a query condition of a first database query statement, and an account corresponding to each client in the North China is field content data of the main key field of the matched physical table queried in the dimension table; the field content data 'accounts corresponding to all clients in North China' which are queried by the first database query statement 'consumption data with consumption amount larger than 1000' in the second query range is the query condition of the second database query statement, and the field content data 'consumption data with consumption amount larger than 1000 of all accounts corresponding to all clients in North China' is the field content data of the field to be queried corresponding to the current index data which is searched in the matched physical table. The account information corresponding to each client in the North China recorded in the dimension table can be input manually, and can also be obtained by calling the related clients and accounts and carrying out information aggregation on the association tables between the clients and the regions.
Example IV
Fig. 7 is a schematic structural diagram of a data query device according to a fourth embodiment of the present invention, and referring to fig. 7, the data query device includes: a receiving module 710, a determining module 720, a querying module 730, and a returning module 740;
the receiving module 710 is configured to receive a user analysis request sent by a service end, where the user analysis request includes dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field; a determining module 720, configured to determine, for each of the index data, whether there is logic metadata consistent with the current index data in at least one preset logic metadata; a query module 730, configured to, when determining that there is logic metadata consistent with the current index data in at least one preset logic metadata, determine a physical table matching the dimension data from at least one physical table bound with the logic metadata, and query data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table; and the return module 740 is configured to splice the queried data and return the spliced data to the service end.
Further, the query module 730 includes:
a determining unit, configured to determine, if a physical table in which dimension data is consistent with dimension data included in the user analysis request exists in at least one physical table bound to the logical metadata, a physical table in which dimension data is consistent with dimension data included in the user analysis request as a physical table matched with dimension data included in the user analysis request; the dimension data of each physical table corresponds to a main key field in the physical table;
and the query unit is used for generating a database query statement based on the current index data, the dimension data contained in the user analysis request and the determined physical table, and querying the data by executing the database query statement.
Further, the query module 730 further includes:
a dimension level obtaining unit, configured to obtain a dimension level of each physical table bound to the logical metadata if there is no physical table in which dimension data is consistent with dimension data included in the user analysis request in at least one physical table bound to the logical metadata;
and the screening unit is used for screening one physical table from the physical tables bound with the logic metadata based on the dimension level, and taking the physical table as the physical table matched with the dimension data contained in the user analysis request.
Further, the screening unit is specifically configured to:
based on the dimension level, screening out physical tables with dimension level lower than the dimension level corresponding to the dimension data contained in the user analysis request from the physical tables bound with the logic metadata;
if one physical table is screened out, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
if a plurality of physical tables are screened, a physical table with the smallest difference between the dimension level and the dimension level corresponding to the dimension data contained in the user analysis request is screened out from the screened physical tables again;
if one physical table is screened again, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
and if the plurality of physical tables are screened again, selecting the physical table with the smallest data quantity from the screened physical tables as the physical table matched with the dimension data contained in the user analysis request.
Further, the device further comprises: the dimension table determining module is used for determining a dimension table after determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, wherein the fields of the dimension table comprise a primary key field corresponding to the dimension data contained in the user analysis request and a primary key field of the physical table matched with the dimension data contained in the user analysis request;
Correspondingly, the query module 730 is specifically configured to generate a database query statement based on the dimension table, the physical table matched with the dimension data included in the user analysis request, the current index data, and the dimension data included in the user analysis request, and execute the database query statement to query data.
Further, the dimension data contained in the user analysis request further comprises a first query range of a main key field corresponding to the field to be queried, and the current index data further comprises a second query range of the corresponding field to be queried;
correspondingly, the query module 730 is specifically configured to generate a third database query sentence obtained by connecting the first database query sentence and the second database query sentence, where,
the first database query statement is used for querying field content data of the main key field of the matched physical table in the dimension table by taking a main key field and a first query range corresponding to the dimension data contained in the user analysis request as query conditions;
and the second database query statement is used for searching the field content data of the field to be queried corresponding to the current index data in the matched physical table by taking the field content data queried by the first database query statement and the second query range as query conditions.
According to the technical scheme, the fields contained in the physical table are used as management units, binding relations between the fields and the physical table are pre-established, after a user analysis request comprising the fields to be queried sent by a service end is received, whether the preset fields which are the same as the fields to be queried exist or not is determined, if the preset fields exist, the physical table which is matched with dimension data corresponding to the fields to be queried is determined from the physical table bound with the preset fields, the data are queried from the determined physical table based on the fields to be queried and the corresponding dimension data, the fact that a service model (corresponding to one service model for each service requirement/scene and used for representing data requiring query) and a physical model (a database table which is pre-established according to each service model and contains target data) are completely decoupled is achieved, aggregation of the physical table is not needed to be performed to establish the database table, when the service model changes, the change of the database table is not caused, the flexibility and the maintainability of the data are improved, the situation that the service requirement/scene is corresponding to each service requirement/scene is used as management units is used for querying the determined, the data in the determined, the database is further improved, and the data multiplexing efficiency is improved.
The data query device provided by the embodiment of the invention can execute the data query method provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
Example five
Fig. 8 is a schematic structural diagram of an electronic device according to a fifth embodiment of the present invention. Fig. 8 illustrates a block diagram of an exemplary device 12 suitable for use in implementing embodiments of the present invention. The device 12 shown in fig. 8 is merely an example and should not be construed as limiting the functionality and scope of use of embodiments of the present invention.
As shown in fig. 8, device 12 is in the form of a general purpose computing device. Components of device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, a bus 18 that connects the various system components, including the system memory 28 and the processing units 16.
Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, micro channel architecture (MAC) bus, enhanced ISA bus, video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
Device 12 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by device 12 and includes both volatile and nonvolatile media, removable and non-removable media.
The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM) 30 and/or cache memory 32. Device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from or write to non-removable, nonvolatile magnetic media (not shown in FIG. 8, commonly referred to as a "hard disk drive"). Although not shown in fig. 8, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In such cases, each drive may be coupled to bus 18 through one or more data medium interfaces. Memory 28 may include at least one program product having a set of program modules (e.g., a receiving module 710, a determining module 720, a querying module 730, and a returning module 740) configured to perform the functions of embodiments of the present invention.
Program/utility 40 having a set (receiving module 710, determining module 720, querying module 730, and returning module 740) of program modules 42 may be stored, for example, in memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment. Program modules 42 generally perform the functions and/or methods of the embodiments described herein.
Device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), one or more devices that enable a user to interact with device 12, and/or any devices (e.g., network card, modem, etc.) that enable device 12 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 22. Also, device 12 may communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet, via network adapter 20. As shown, network adapter 20 communicates with other modules of device 12 over bus 18. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with device 12, including, but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.
The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, for example, implementing the data query method provided by the embodiment of the present invention.
Example six
The sixth embodiment of the present invention further provides a computer readable storage medium, on which a computer program is stored, where the program when executed by a processor implements the data query method according to the embodiment of the present invention.
The computer storage media of embodiments of the invention may take the form of any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.

Claims (14)

1. A method of querying data, comprising:
receiving a user analysis request sent by a service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field;
for each index data, determining whether preset logic metadata consistent with the current index data exists in at least one piece of logic metadata, if so, determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, and inquiring data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table; wherein querying data from the determined physical table based on the current index data and the dimension data comprises: generating a database query statement based on the current index data, the dimension data contained in the user analysis request and the determined physical table, and querying the data by executing the database query statement;
And splicing the queried data and returning the spliced data to the service end.
2. The data query method of claim 1, wherein determining a physical table that matches the dimension data from at least one physical table bound to the logical metadata comprises:
if at least one physical table bound with the logic metadata has a physical table with dimension data consistent with the dimension data contained in the user analysis request, determining the physical table with dimension data consistent with the dimension data contained in the user analysis request as a physical table matched with the dimension data contained in the user analysis request; the dimension data of each physical table corresponds to a primary key field in the physical table.
3. The data query method of claim 1, wherein determining a physical table that matches the dimension data from at least one physical table bound to the logical metadata comprises:
and if at least one physical table bound with the logic metadata does not have a physical table with dimension data consistent with the dimension data contained in the user analysis request, acquiring the dimension level of each physical table bound with the logic metadata, and screening one physical table from each physical table bound with the logic metadata based on the dimension level to serve as a physical table matched with the dimension data contained in the user analysis request.
4. A data query method as claimed in claim 3, wherein, based on said dimension level, selecting a physical table from among the physical tables bound to said logical metadata as a physical table matching dimension data contained in said user analysis request, comprises:
based on the dimension level, screening out physical tables with dimension level lower than the dimension level corresponding to the dimension data contained in the user analysis request from the physical tables bound with the logic metadata;
if one physical table is screened out, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
if a plurality of physical tables are screened, a physical table with the smallest difference between the dimension level and the dimension level corresponding to the dimension data contained in the user analysis request is screened out from the screened physical tables again;
if one physical table is screened again, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
and if the plurality of physical tables are screened again, selecting the physical table with the smallest data quantity from the screened physical tables as the physical table matched with the dimension data contained in the user analysis request.
5. The data query method of claim 3 or 4, wherein after determining a physical table matching the dimension data from at least one physical table bound to the logical metadata, the method further comprises:
determining a dimension table, wherein the fields of the dimension table comprise a primary key field corresponding to dimension data contained in the user analysis request and a primary key field of a physical table matched with the dimension data contained in the user analysis request;
the querying data from the determined physical table based on the current index data and the dimension data comprises:
and generating a database query statement based on the dimension table, the physical table matched with the dimension data contained in the user analysis request, the current index data and the dimension data contained in the user analysis request, and querying data by executing the database query statement.
6. The data query method according to claim 5, wherein the dimension data included in the user analysis request further includes a first query range of a primary key field corresponding to the field to be queried, and the current index data further includes a second query range of the corresponding field to be queried;
Correspondingly, the generating a database query statement based on the dimension table, the physical table matched with the dimension data contained in the user analysis request, the current index data, and the dimension data contained in the user analysis request includes:
generating a third database query sentence obtained by connecting the first database query sentence and the second database query sentence, wherein,
a first database query statement, configured to query, in the dimension table, field content data of a primary key field of the matched physical table, with a primary key field and a first query range corresponding to dimension data included in the user analysis request as query conditions;
and the second database query statement is used for searching the field content data of the field to be queried corresponding to the current index data in the matched physical table by taking the field content data queried by the first database query statement and the second query range as query conditions.
7. A data query device, comprising:
the receiving module is used for receiving a user analysis request sent by the service end, wherein the user analysis request comprises dimension data and at least one index data; each index data comprises a field to be queried, and the dimension data comprises a primary key field;
The determining module is used for determining whether logic metadata consistent with the current index data exists in at least one preset logic metadata or not for each index data;
the query module is used for determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata when determining that the preset logic metadata consistent with the current index data exists in the preset at least one logic metadata, and querying data from the determined physical table based on the current index data and the dimension data; wherein each of the logical metadata is a field contained in at least one existing physical table; the query module further includes: the query unit is used for generating a database query statement based on the current index data, the dimension data contained in the user analysis request and the determined physical table, and querying the data by executing the database query statement;
and the return module is used for splicing the queried data and returning the spliced data to the service end.
8. The data querying device of claim 7, wherein the querying module comprises:
a determining unit, configured to determine, if a physical table in which dimension data is consistent with dimension data included in the user analysis request exists in at least one physical table bound to the logical metadata, a physical table in which dimension data is consistent with dimension data included in the user analysis request as a physical table matched with dimension data included in the user analysis request; the dimension data of each physical table corresponds to a primary key field in the physical table.
9. The data querying device of claim 7, wherein the querying module comprises:
a dimension level obtaining unit, configured to obtain a dimension level of each physical table bound to the logical metadata if there is no physical table in which dimension data is consistent with dimension data included in the user analysis request in at least one physical table bound to the logical metadata;
and the screening unit is used for screening one physical table from the physical tables bound with the logic metadata based on the dimension level, and taking the physical table as the physical table matched with the dimension data contained in the user analysis request.
10. The data query device according to claim 9, wherein the screening unit is specifically configured to:
based on the dimension level, screening out physical tables with dimension level lower than the dimension level corresponding to the dimension data contained in the user analysis request from the physical tables bound with the logic metadata;
if one physical table is screened out, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
if a plurality of physical tables are screened, a physical table with the smallest difference between the dimension level and the dimension level corresponding to the dimension data contained in the user analysis request is screened out from the screened physical tables again;
If one physical table is screened again, the screened physical table is used as a physical table matched with the dimension data contained in the user analysis request;
and if the plurality of physical tables are screened again, selecting the physical table with the smallest data quantity from the screened physical tables as the physical table matched with the dimension data contained in the user analysis request.
11. The data querying device of claim 9 or 10, further comprising: the dimension table determining module is used for determining a dimension table after determining a physical table matched with the dimension data from at least one physical table bound with the logic metadata, wherein the fields of the dimension table comprise a primary key field corresponding to the dimension data contained in the user analysis request and a primary key field of the physical table matched with the dimension data contained in the user analysis request;
correspondingly, the query module is specifically configured to: and generating a database query statement based on the dimension table, the physical table matched with the dimension data contained in the user analysis request, the current index data and the dimension data contained in the user analysis request, and querying data by executing the database query statement.
12. The data query device according to claim 11, wherein the dimension data contained in the user analysis request further comprises a first query range of a primary key field corresponding to the field to be queried, and the current index data further comprises a second query range of the corresponding field to be queried;
correspondingly, the query module is specifically configured to generate a third database query sentence obtained by connecting the first database query sentence and the second database query sentence, where,
the first database query statement is used for querying field content data of the main key field of the matched physical table in the dimension table by taking a main key field and a first query range corresponding to the dimension data contained in the user analysis request as query conditions;
and the second database query statement is used for searching the field content data of the field to be queried corresponding to the current index data in the matched physical table by taking the field content data queried by the first database query statement and the second query range as query conditions.
13. An electronic device, the electronic device comprising:
one or more processors;
storage means for storing one or more programs,
The one or more programs, when executed by the one or more processors, cause the one or more processors to implement the data query method of any of claims 1-6.
14. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements a data query method as claimed in any one of claims 1-6.
CN201910289290.9A 2019-04-11 2019-04-11 Data query method and device, electronic equipment and storage medium Active CN111813804B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910289290.9A CN111813804B (en) 2019-04-11 2019-04-11 Data query method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910289290.9A CN111813804B (en) 2019-04-11 2019-04-11 Data query method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN111813804A CN111813804A (en) 2020-10-23
CN111813804B true CN111813804B (en) 2023-08-15

Family

ID=72844463

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910289290.9A Active CN111813804B (en) 2019-04-11 2019-04-11 Data query method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN111813804B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112905627B (en) * 2021-03-23 2022-04-29 金岭教育科技(北京)有限公司 Data processing method, data processing device, computer equipment and storage medium
CN113220687A (en) * 2021-05-21 2021-08-06 中国农业银行股份有限公司 Rule processing method, device and equipment
CN114356965B (en) * 2022-03-18 2022-06-14 杭州湖畔网络技术有限公司 Method, system, server and storage medium for generating dynamic form
CN115658728B (en) * 2022-11-16 2023-06-13 荣耀终端有限公司 Query method, electronic equipment and storage medium
CN117151555B (en) * 2023-11-01 2024-02-02 青岛文达通科技股份有限公司 Smart city service system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8108431B1 (en) * 2008-03-24 2012-01-31 Autotelika, Incorporated Two-dimensional data storage system
CN103577590A (en) * 2013-11-12 2014-02-12 北京润乾信息系统技术有限公司 Data query method and system
CN108804460A (en) * 2017-05-03 2018-11-13 北京润乾信息系统技术有限公司 A kind of query language based on SQL
CN109408535A (en) * 2018-09-28 2019-03-01 中国平安财产保险股份有限公司 Big data quantity matching process, device, computer equipment and storage medium

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8108431B1 (en) * 2008-03-24 2012-01-31 Autotelika, Incorporated Two-dimensional data storage system
CN103577590A (en) * 2013-11-12 2014-02-12 北京润乾信息系统技术有限公司 Data query method and system
CN108804460A (en) * 2017-05-03 2018-11-13 北京润乾信息系统技术有限公司 A kind of query language based on SQL
CN109408535A (en) * 2018-09-28 2019-03-01 中国平安财产保险股份有限公司 Big data quantity matching process, device, computer equipment and storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
一种基于元数据静动态数据联合查询方法的研究与实现;曾艳梅;成长生;陆忠良;苏厚勤;;计算机应用与软件(01) *

Also Published As

Publication number Publication date
CN111813804A (en) 2020-10-23

Similar Documents

Publication Publication Date Title
CN111813804B (en) Data query method and device, electronic equipment and storage medium
CN109558525B (en) Test data set generation method, device, equipment and storage medium
CN110750654A (en) Knowledge graph acquisition method, device, equipment and medium
CN103810212A (en) Automated database index creation method and system
CN109597640B (en) Account management method, device, equipment and medium for application program
CN105530272A (en) Method and device for application data synchronization
CN110975293A (en) Method, device, server and medium for establishing resource reference relation table
CN113626223A (en) Interface calling method and device
CN110502506B (en) Data processing method, device, equipment and storage medium
CN116383193A (en) Data management method and device, electronic equipment and storage medium
CN113971037A (en) Application processing method and device, electronic equipment and storage medium
CN114281663A (en) Test processing method, test processing device, electronic equipment and storage medium
CN110941547A (en) Automatic test case library management method, device, medium and electronic equipment
CN110287338B (en) Industry hotspot determination method, device, equipment and medium
CN116594683A (en) Code annotation information generation method, device, equipment and storage medium
CN116048987A (en) Processing method, device, electronic equipment, system and storage medium for flow business
CN116069725A (en) File migration method, device, apparatus, medium and program product
US20080307432A1 (en) Method and apparatus for exchanging data using data transformation
CN114253922A (en) Resource directory management method, resource management method, device, equipment and medium
CN114357967A (en) Bill file parsing method and device
CN113742225B (en) Test data generation method, device, equipment and storage medium
CN117076515B (en) Metadata tracing method and device in medical management system, server and storage medium
CN113111120B (en) Service data verification method and device
CN117271554A (en) Distributed database view processing method, device, equipment and storage medium
CN113687881A (en) Metadata calling method and device, electronic equipment and storage medium

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
GR01 Patent grant
GR01 Patent grant