CN119311755B

CN119311755B - Database persistence method, terminal device and computer readable storage medium

Info

Publication number: CN119311755B
Application number: CN202411861987.6A
Authority: CN
Inventors: 周心通; 何振威; 曾昭德
Original assignee: Shenzhen Dengke Cloud Software Co ltd
Current assignee: Shenzhen Dengke Cloud Software Co ltd
Priority date: 2024-12-17
Filing date: 2024-12-17
Publication date: 2025-05-02
Anticipated expiration: 2044-12-17
Also published as: CN119311755A

Abstract

The application belongs to the technical field of databases, and particularly relates to a database persistence method, terminal equipment and a computer readable storage medium, which comprise traversing each first data model in a first data set to be persistence to obtain attribute information of each first data model; generating a storage script of a database of each first data model according to the attribute information meeting the first preset condition in each first data model, wherein the first preset condition comprises that the attribute information of the first data model is consistent with the attribute information of the first storage model, and persisting each first data model into the first storage model in the database according to the storage script of each first data model. By the method, the development cost and the maintenance cost of the database can be effectively reduced.

Description

Database persistence method, terminal device and computer readable storage medium

Technical Field

The present application relates to the field of database technologies, and in particular, to a database persistence method, a terminal device, and a computer readable storage medium.

Background

Data persistence is a generic term for converting a data model in memory to a storage model, and converting a storage model to a data model in memory. The data model is a model for storing data in the memory, and the storage model is a model for storing data in the database.

Existing persistence frameworks generally do not support the submission of multiple-table, bulk data, i.e., the submission of add-delete-change data for multiple tables at a time. In the case of processing multi-table or batch data, it is generally necessary to split the data and configure a large number of configuration files, mapping relationships, etc., so that the development workload is large and the subsequent maintenance cost of the persistence framework is high.

Disclosure of Invention

The embodiment of the application provides a database persistence method, terminal equipment and a computer readable storage medium, which can effectively reduce the development cost and maintenance cost of a database.

In a first aspect, an embodiment of the present application provides a data persistence method, including:

Traversing each first data model in a first data set to be persisted to obtain attribute information of each first data model, wherein the data model is a model for storing data in a memory;

Generating a storage script of a database of each first data model according to attribute information meeting a first preset condition in each first data model, wherein the first preset condition comprises that the attribute information of the first data model is consistent with the attribute information of a first storage model;

And persisting each first data model into a first storage model in the database according to the storage script of each first data model.

In the embodiment of the application, in the process of converting the data model in the memory into the storage model of the database, the storage script of the database can be generated according to the attribute information meeting the first preset condition, and because the storage script is dynamically generated, configuration files, mapping relations and the like between the storage model and the data model are not required to be preset, the development cost is greatly reduced, and in addition, after the fields of the database are changed, the configuration files, the mapping relations and the like are not required to be maintained, so that the maintenance cost of the database is greatly reduced.

In a possible implementation manner of the first aspect, the traversing each first data model in the first data set to be persisted to obtain attribute information of each first data model includes:

and traversing each second data model in the second data set to obtain the attribute information of each second data model if the attribute information of the first data model comprises a second data set, wherein the attribute information of the first data model comprises the attribute information of the second data model.

In the above embodiment, in the process of data persistence, all attribute information of the data set included in the data model is obtained by traversing the data model and the data set included in the data model. By the mode, the persistent processing of multi-table and batch data is facilitated. In addition, compared with the prior art, the method does not need to split multi-table and batch data before persistence, but only traverses attribute information in the persistence process, and the development workload can be effectively reduced.

In a possible implementation manner of the first aspect, the attribute information includes an attribute name and a data type, and the method further includes:

for each first data model, if the table name corresponding to the first data model is consistent with the table name corresponding to the first storage model in the database, judging whether a first name is consistent with a second name, wherein the first name is an attribute name in attribute information of the first data model, and the second name is an attribute name in attribute information of the first storage model;

If the first name is consistent with the second name, judging whether the data type corresponding to the first name is consistent with the data type corresponding to the second name;

and if the data type corresponding to the first name is consistent with the data type corresponding to the second name, judging that the first name meets the first preset condition.

In the implementation manner, the table names, the attribute names and the data types are sequentially compared, so that the attribute information of the data model and the attribute information of the storage model can be more accurately matched, and the reliability of data persistence can be improved. In addition, by the method, the attribute information of the data model and the attribute information of the storage model can be automatically and dynamically matched in the data persistence process, multiple tables or batch data are not required to be split before the data persistence, and development workload of a persistence framework is effectively reduced.

In a possible implementation manner of the first aspect, the attribute information includes a data state and a data value corresponding to each attribute name;

the generating a storage script of the database of each first data model according to the attribute information meeting the first preset condition in each first data model comprises the following steps:

generating a script template according to the data state in the attribute information of the first data model;

and generating a storage script of a database of the first data model according to the script template and the data value corresponding to the attribute name meeting the first preset condition in the first data model.

According to the implementation mode, the database script is dynamically generated according to the data state in the data persistence process, and the script does not need to be written in advance before the data persistence, so that the development workload of a persistence framework is greatly reduced. In addition, because the database script is dynamically generated, when the database field is changed, the database script can also be dynamically changed, a large number of scripts are not required to be maintained, and the maintenance cost of the persistence framework is greatly reduced.

In a possible implementation manner of the first aspect, the method further includes:

generating a query script of the database according to a query instruction sent by an application program;

Acquiring a third data set from the database according to the query script of the database, wherein the third data set comprises at least one second storage model;

obtaining attribute information of a third data model according to the model type corresponding to the query script, wherein the third data model is used for generating a query result corresponding to the query instruction;

And converting the attribute information meeting a second preset condition in each second storage model of the third data set to obtain a third data model, wherein the second preset condition comprises that the attribute information of the second storage model is consistent with the attribute information of the third data model.

In the embodiment of the application, in the data persistence process, the attribute information of the data model and the storage model can be automatically matched, configuration files, mapping relations and the like between the storage model and the data model are not required to be preset, and the development cost is greatly reduced. In addition, through the method, all storage models associated with the query script can be obtained, so that comprehensive query information is obtained, multi-table or batch data query is realized, and the accuracy of data query can be effectively improved.

In a possible implementation manner of the first aspect, the obtaining, according to a query script of the database, a third data set from the database includes:

Acquiring a second storage model corresponding to the query script from the database to obtain first data;

And obtaining a second storage model associated with the first data from the database to obtain second data, wherein the third data set comprises the first data and the second data.

By the method, comprehensive data related to the query script can be obtained, the condition of missing data detection is reduced, and the accuracy of data query can be effectively improved.

In a possible implementation manner of the first aspect, the attribute information includes an attribute name and a data value corresponding to the attribute name;

The generating the third data model according to the attribute information meeting the second preset condition in each second storage model of the third data set includes:

For each second storage model, if a third name is consistent with a fourth name, judging whether the data type corresponding to the third name is consistent with the data type corresponding to the fourth name, wherein the third name is an attribute name in attribute information of the second storage model, and the fourth name is an attribute name in attribute information of the third data model;

And if the third name is consistent with the fourth name, assigning the data value corresponding to the third name in the second storage model to the member corresponding to the fourth name in the third data model.

By the method, in the data persistence process, the attribute information of the data model and the storage model can be automatically matched, configuration files, mapping relations and the like between the storage model and the data model are not required to be preset, and development cost is greatly reduced.

and after obtaining the query result corresponding to the query instruction, disconnecting the application program from the database.

By disconnecting the application from the database in time, the operating pressure of the database can be reduced.

In a second aspect, an embodiment of the present application provides a data persistence apparatus, including:

The data processing unit is used for processing the first data set to be processed, and obtaining attribute information of each first data model according to the attribute information, wherein the data model is a model for storing data in a memory.

The generation unit is used for generating a storage script of the database of each first data model according to the attribute information meeting the first preset condition in each first data model, wherein the first preset condition comprises that the attribute information of the first data model is consistent with the attribute information of a first storage model, and the storage model is a model for storing data in the database.

And the persistence unit is used for persistence of each first data model into a first storage model in the database according to the storage script of each first data model.

In a third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the data persistence method according to any one of the first aspects when the computer program is executed by the processor.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which, when executed by a processor, implements a data persistence method as in any one of the first aspects above.

In a fifth aspect, an embodiment of the present application provides a computer program product, which, when run on a terminal device, causes the terminal device to perform the data persistence method of any of the first aspects described above.

It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a persistent framework provided by an embodiment of the present application;

FIG. 2 is a flow chart of a data persistence method provided by an embodiment of the application;

FIG. 3 is a flow chart of a method for data persistence provided by an embodiment of the present application;

FIG. 4 is a block diagram of a data persistence device provided by an embodiment of the application;

Fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".

Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise.

For example, in the case where the data model is an object model and the storage model is a relationship model, data persistence refers to conversion between the object model and the relationship model. One of the storage features of the relational database is to search out related information by associating other tables with external keys, so in order to avoid data redundancy, service documents generally only store codes of basic data, for example, orders store commodity codes only from tables, commodity names, specifications, units and other information are searched out by associating commodity tables. The data model presented to the user is different from the storage model, and often the data model presented to the user has more field data of the association table, such as information of commodity names, specifications, units and the like.

The data persistence framework is an important tool for interaction between the application system and the database, and is mainly used for realizing operations such as inquiring, adding, modifying and deleting data. In actual persistent framework program development, it is often necessary to process multiple tables or batches of data. For example, the storage of a purchase order requires storage of not only data of a master form purchase order number, a supplier, and the like, but also a plurality of pieces of data of a slave form purchase goods and the like, and involves operations such as addition, deletion, and modification of these pieces of data.

The existing object-oriented programming language data persistence frameworks, such as Hibernate, myBatis, myBatis-Plus, SPRING DATA JPA of the Jave platform, the Entity Framework, dapper, NHibernate of the Net platform, SQLALCHEMY, tortoise ORM, django ORM of the Python platform, and the like, do not generally support the submission of multi-table, batch data, i.e., the submission of add-delete-change data of multiple tables at a time. For example, existing persistence frameworks split submitted data into additions, modifications, and deletions based on data state, and store them in batches into a database, which greatly increases development difficulty and workload.

In the case of processing multiple tables or batch data, the existing persistence framework needs a large number of configuration files, one database table may correspond to a plurality of configuration files, each configuration file includes a large number of scripts such as adding, deleting, modifying, checking and the like and various parameters needed by the scripts, a developer needs a large amount of configuration work, debugging is very difficult, and use efficiency is low. In order to achieve the conversion between data models and relational models, existing persistence frameworks need to map the mapping between the attributes of the data model and the fields of the storage model, which requires a significant amount of repetitive development effort.

In addition, after the database field is changed, the configuration file, the mapping relation and the like need to be adjusted, and the subsequent maintenance workload is large.

Based on the above, the embodiment of the application provides a persistence framework, which does not need to set configuration files, mapping relations and the like, and can reduce the development cost and subsequent maintenance cost of the persistence framework.

Referring to fig. 1, a schematic structural diagram of a persistence frame according to an embodiment of the present application is provided. By way of example and not limitation, as shown in FIG. 1, the persistence framework may include an interface layer 11 and a data processing layer 12. The interface layer 11 is used for providing a calling interface of the persistence method, such as receiving an object model list and receiving an object model list returned by the query script. The data processing layer 12 is configured to implement the data persistence method provided by the embodiment of the present application, for example, interpret the data model list to generate a database script for adding or deleting, execute the database script to store data into the database, execute the database query script to obtain a result set returned by the database, and convert the result set into the data model list and return the data model list to the memory.

The data processing layer 12 may include a first processing module 121 for storing a method and a second processing module 122 for querying a method. Accordingly, the interface layer 11 may include a first interface 111 for storing methods and a second interface 112 for querying methods.

For example, in a data persistence process of storing memory data to a database, the memory calls a storage method that calls the first processing module 121 of the data processing layer 12 through the first interface 111 of the interface layer 11. Accordingly, the first processing module 121 executes the data persistence method of the embodiment of fig. 2 described below, interprets the data model of the memory to generate a pruned database script, and executes the database script through the database operating component to save the data to the database, so as to realize the conversion from the data model to the storage model.

For another example, during data persistence of query data from the database, the memory invokes a query method that invokes the second processing module 122 of the data processing layer 12 through the second interface 112 of the interface layer 11, sending a query instruction to the second processing module 122. Accordingly, the second processing module 122 executes the data persistence method of the embodiment of fig. 3 after receiving the query instruction, generates a query script of the database according to the query instruction, executes the query script through the database operating component to obtain the storage model from the database, converts the storage model into the data model, and finally returns the data model to the memory.

Based on the above-mentioned persistence framework, the data persistence method provided by the embodiment of the application is described below. As described above, data persistence may include the process of converting a data model in memory to a storage model, and converting a storage model to a data model in memory. The two processes of data persistence are described separately below.

Referring to fig. 2, a flowchart of a data persistence method according to an embodiment of the present application is shown. By way of example and not limitation, fig. 2 illustrates a process of converting a data model into a storage model, i.e., storing in-memory data into a database, the method may include the steps of:

S201, traversing each first data model in the first data set to be durable to obtain attribute information of each first data model.

The data model is a model for storing data in the memory. The types of data models may include a value Object model VO (Value Object), a persistence Object model PO (Persistent Object), a business Object model BO (Business Object), a data transfer Object model DTO (DATA TRANSFER Object), and so on.

In the embodiment of the application, a value object model can be adopted as a data model. Wherein the attribute information of the value object model may include a database connection identifier, a table name, and a data state. Because the value object model contains more data attributes and more comprehensive information, the value object model is adopted as the data model, so that the conversion process among multiple models can be reduced, and the development workload can be reduced.

The attribute information of the data model may include attribute names, data types, data states, and data values corresponding to each attribute name. Illustratively, as shown in the following table, is an example of a data model.

XX

In the data model shown above, "XX" is a table name. The information in the first column to the third column of the first row in the "XX" table is attribute names, i.e., the data model includes 3 attribute names, respectively "product name", "number", and "unit price". The information of the first column, the second row and the fourth row is a data value corresponding to a product name, the information of the second column, the second row and the fourth row is a data value corresponding to a quantity, and the information of the third column, the second row and the fourth row is a data value corresponding to a unit price. The information from the second row to the fourth row in the fourth column indicates the data state corresponding to the data value of the corresponding row, for example, "new" in the second row in the fourth column indicates that the data value of the second row is newly added data, "modified" in the third row in the fourth column indicates that the data value of the third row is modified data, and "deleted" in the fourth row in the fourth example indicates that the data value of the fourth row is deleted.

It should be noted that, the data model is shown in a table form, and in practical application, the data model may also take other forms, which are not particularly limited in the embodiment of the present application.

In one implementation, S201 includes:

traversing the rows and columns of the first data model, and acquiring attribute information of the first data model.

For example, as in the "XX" table described above, attribute information of the table can be obtained by traversing the rows and columns of the table, wherein attribute names in the attribute information include "product name", "number", and "unit price".

In practice, the first data model may not be a single data model, which may be a collection of other data models. In another implementation, S201 includes:

and traversing each second data model in the second data set to obtain the attribute information of each second data model if the attribute information of the first data model comprises the second data set, wherein the attribute information of the first data model comprises the attribute information of the second data model.

Illustratively, the following table shows an example of another data model.

YY

As shown in the above table, "YY" is the table name. The information "unit price" of the third column of the first row in the "YY" table is an attribute name. The information of the second row to the fourth row of the third column is a data value corresponding to "unit price". However, as can be seen from the above table, each data value corresponding to "unit price" is a table name (each table name corresponds to a data model), the data value of the second row and the third column corresponds to "Y1" table, the data value of the third row and the third column corresponds to "Y2" table, and the data value of the fourth row and the third column corresponds to "Y3" table. In other words, the data model of the "YY" table includes three data models of the "Y1" table, the "Y2" table, and the "Y3" table.

In this case, it is necessary to traverse not only the rows and columns in the "YY" table but also the rows and columns in the "Y1" table, the "Y2" table, and the "Y3" table included in the "YY" table.

Taking the "Y1" table as an example, assume that the "Y1" table is as follows:

Y1

The attribute names whose attribute information is obtained by traversing the "Y1" table include "product number" and "unit price". The attribute information of the "YY" table includes not only the attribute names "product name", "number", and "unit price" in the first row of the "YY" table but also the attribute name "product number" in the first row of the "Y1" table.

After traversing the rows and columns in the "Y1" table, the "Y2" table, and the "Y3" table included in the "YY" table, the attribute names of the attribute information of the "YY" table include the attribute names in the first row of the "YY" table, the attribute names in the "Y1" table, the attribute names in the "Y2" table, and the attribute names in the "Y3" table.

It will be appreciated that in the above example, the "YY" table may be considered a first data model, and the "Y1" table, the "Y2" table, and the "Y3" table may be considered a second data model.

S202, generating a storage script of a database of each first data model according to the attribute information meeting the first preset condition in each first data model.

The storage model is a model of storing data in a database.

The first preset condition comprises that attribute information of the first data model is consistent with attribute information of the first storage model.

More attribute information is typically presented to the user than to the storage model. Illustratively, the following table shows an example of a storage model.

ZZ

As shown in the above table, "ZZ" is the table name. The "ZZ" table includes first behavioral attribute names, including "product name" and "unit price". The attribute names of the "ZZ" tables lack "quantity" compared to the "XX" tables described above.

In some judging modes of the first preset condition, only whether the first name is consistent with the second name or not can be compared, and if the first name is consistent with the second name, the first name is judged to meet the first preset condition. The first name is an attribute name in the attribute information of the first data model, and the second name is an attribute name in the attribute information of the first storage model.

In other implementations of the first preset condition, the method may include:

For each first data model, if the table name corresponding to the first data model is consistent with the table name corresponding to the first storage model in the database, judging whether the first name is consistent with the second name, wherein the first name is the attribute name in the attribute information of the first data model, and the second name is the attribute name in the attribute information of the first storage model;

Alternatively, table names may be identical, or the same. For example, the table name of the first data model is "XX", the table name of the first storage model is "ZZ", and the table names are different, but the table names are related to each other, that is, the data of the "XX" table in the memory is stored as the "ZZ" table in the database.

Alternatively, the first name and the second name are identical, and may refer to the first name and the second name being identical, or refer to the first name and the second name being identical. For example, a first name is "product name" and a second name is "product name", both referring to the same, the first name is consistent with the second name.

As an example of judging the first preset condition, assume that the "XX" table is the first data model and the "ZZ" table is the first storage model. The attribute name "product name" in the "XX" table is identical to the "product name" in the "ZZ" table, and the attribute name "product name" in the "XX" table satisfies the first preset condition. The "number of attribute names" does not exist in the "ZZ" table, namely, the "number of attribute names" in the "XX" table does not satisfy the first preset condition. The attribute name "unit price" in the "XX" table coincides with the "unit price" in the "ZZ" table, and the attribute name "unit price" in the "XX" table satisfies the first preset condition.

After judging the first preset condition, generating a storage script according to the determined first name which meets the first preset condition, namely the data value and the data state corresponding to the product name and the unit price respectively.

In one implementation, S202 may include:

Continuing with the above example, the data state of the second row in the "XX" table is "new" to generate a script template corresponding to "new", such as pseudo code "Insert into orderdtl (matecode, inprince) values ('product name', 'unit price')", and then adding the data values corresponding to each of the "product name" and the "unit price" in the second row to the corresponding locations in the script template to obtain a stored script, such as pseudo code "Insert into orderdtl (0001, 2) values ('product name', 'unit price')".

The data state of the third row in the XX table is "modification", a script template corresponding to the "modification" is generated, such as pseudo code "Update orderdtl set matecode = 'product name', inprice = 'unit price', where id= 'primary key'", and then the data values corresponding to the "product name" and the "unit price" in the third row are added to corresponding positions in the script template, so as to obtain a stored script, such as pseudo code "Update orderdtl set matecode =0002, input=3, and where id=3. Where a "primary key" is a unique identification of a row in a table.

Under the deletion operation, data of a certain line may be deleted entirely. For example, the data state of the fourth line in the "XX" table is "delete", a script template corresponding to "delete" is generated, such as pseudo code "Delete from orderdtl where id = 'primary key'", and then a storage script is generated according to the attribute information of the fourth line, such as pseudo code "Delete from orderdtl where id = '4'". It can be understood that, under the deleting operation, only the data value under a certain attribute name in a certain line of data may be deleted, and in this case, the process of generating the storage script is the same as the above-described "modification" and "addition" example principles, which are not described herein.

It should be noted that, the examples of the script templates and the pseudo code of the stored scripts in the above examples are only used for illustrating examples, and the code forms of the script templates and the stored scripts in the embodiments of the present application are not particularly limited.

S203, persisting each first data model into a first storage model in the database according to the storage script of each first data model.

In one implementation, as in the persistence framework shown in fig. 1, after the first processing module 121 obtains the storage script, the storage script may be executed by the database operating component to persist the first data model to the first storage model, thereby implementing storing the memory data into the database.

In the embodiment of fig. 2, the database script can be dynamically generated in the data persistence process, so that configuration files, mapping relations and the like between the storage model and the data model are not required to be preset, the development cost is greatly reduced, and in addition, after the database field is changed, the configuration files, the mapping relations and the like are not required to be maintained, so that the maintenance cost of the database is greatly reduced.

Referring to fig. 3, a flowchart of a data persistence method according to an embodiment of the present application is shown. By way of example and not limitation, fig. 3 illustrates a process of converting a storage model into a data model, i.e., reading stored data of a database into memory, the method may include the steps of:

s301, generating a query script of the database according to a query instruction sent by the application program.

In some implementations, as shown in the persistence framework of fig. 1, the user may input the query information through interaction with the application program, and accordingly, the application program receives the query information input by the user, generates a query instruction according to the query information, invokes the second interface 112 to issue the query instruction to the second processing module 122, and the second processing module 122 receives the query instruction and generates a query script according to the query instruction.

Alternatively, the process of generating the query script according to the query instruction may be that the query instruction is converted into a database language, so as to obtain the query script. For example, the query instruction is in C language or JAVA language, and the query instruction is converted into SQL language of the database to obtain the query script.

S302, acquiring a third data set from the database according to the query script of the database.

Wherein the third data set comprises at least one second storage model.

In an embodiment of the present application, the query script may include a table name.

In one implementation, a storage model matching the table name of the query script is obtained from the database as a second storage model.

As can be seen from the above examples of the "YY" table, in practical applications, there may be a correlation between the data model and the data model. Accordingly, there may be an association between storage models in the database, i.e., some attribute information in one storage model may be a table name of another storage model. For example, as shown in the following table, is an example of a storage model.

AA

As shown in the above table, "AA" is the table name. The "AA" table includes the first behavioral attribute names, including "product name" and "unit price". Each data value corresponding to "unit price" is a table name (each table name corresponds to a storage model), the data value of the second row and the second column corresponds to an "A1" table, the data value of the third row and the second column corresponds to an "A2" table, and the data value of the fourth row and the second column corresponds to an "A3" table. In other words, the "AA" tables are associated with the "A1" table, the "A2" and the "A3" tables, respectively.

In this case, if only the storage model matching with the table name of the query script is acquired, some data may be missed, and the accuracy of the query result may be reduced.

To solve the above problem, in another implementation, S302 may include:

For example, the "YY" table is stored in the database as an "AA" table. When the table name of the query script is 'YY', the corresponding storage model is an 'AA' table, namely first data, then the storage model associated with the 'AA' table, such as an 'A1' table, an 'A2' table and an 'A3' table, is acquired, and second data comprises an 'A1' table, an 'A2' table and an 'A3' table. The third data combination corresponding to the query script includes an "AA" table, an "A1" table, an "A2" table, and an "A3" table.

S303, obtaining attribute information of the third data model according to the model type corresponding to the query script.

The third data model is used for generating a query result corresponding to the query instruction. It can be appreciated that the third data model is query data obtained by the application program, and the application program can convert the third data model into interactive information (i.e. query results) which can be viewed by the user and display the interactive information to the user.

Continuing with the example above, assuming that the table name of the query script is "YY", the "YY" table may be traversed to obtain attribute information in the "YY" table, such as attribute names and the like. It can be understood that the process of obtaining the attribute information of the third data model is the same as the process of obtaining the attribute information of the first data model in step S201, and specifically, reference may be made to the description in the embodiment of S201, which is not repeated herein.

S304, converting the attribute information meeting the second preset condition in each second storage model of the third data set to obtain a third data model.

The second preset condition includes that attribute information of the second storage model is consistent with attribute information of the third data model.

In one implementation, S304 may include:

For each second storage model, if the third name is consistent with the fourth name, judging whether the data type corresponding to the third name is consistent with the data type corresponding to the fourth name, wherein the third name is the attribute name in the attribute information of the second storage model, and the fourth name is the attribute name in the attribute information of the third data model;

The third data model is illustratively a "YY" table including attribute names of "product name"

"Quantity", "product number" and "unit price". The second storage model included in the third data set has an "AA" table, an "A1" table, an "A2" table, and an "A3" table. The attribute names included in the "AA" table include "product name" and "unit price", the attribute names included in the "A1" table include "product number" and "unit price", the attribute names included in the "A2" table include "product number" and "unit price", and the attribute names included in the "A3" table include "product number" and "unit price", that is, the attribute names included in the "AA" table include "product name", "unit price" and "product number".

The data values of one column of the product name in the 'AA' table are assigned to one column of the product name in the 'YY' table, the data values of one column of the product number in the 'AA' table are assigned to one column of the product number in the 'YY' table, and the data values of one column of the unit price in the 'AA' table are assigned to one column of the unit price in the 'YY' table.

Of course, it is understood that the data of each row need to correspond to each other during the assignment process. For example, if the data in the column of the "product name" in the "AA" table is assigned to the second to fourth rows in the column of the "product name" in the "YY" table, the data in the column of the "unit price" in the "AA" table is also assigned to the second to fourth rows in the column of the "unit price" in the "YY" table, so as to ensure that the data corresponds.

In the embodiment shown in fig. 3, in the data persistence process, the attribute information of the data model and the storage model can be automatically matched, and configuration files, mapping relations and the like between the storage model and the data model do not need to be preset, so that development cost is greatly reduced. In addition, through the method, all storage models associated with the query script can be obtained, so that comprehensive query information is obtained, multi-table or batch data query is realized, and the accuracy of data query can be effectively improved.

In one embodiment, the method further comprises:

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.

Corresponding to the data persistence method described in the above embodiments, fig. 4 is a block diagram of a data persistence device according to an embodiment of the present application, and for convenience of explanation, only a portion related to the embodiment of the present application is shown.

Referring to fig. 4, the apparatus 4 includes:

And the traversing unit 41 is configured to traverse each first data model in the first data set to be persisted to obtain attribute information of each first data model, where the data model is a model for storing data in a memory.

And the generating unit 42 is configured to generate a storage script of the database of each first data model according to attribute information that satisfies a first preset condition in each first data model, where the first preset condition includes that the attribute information of the first data model is consistent with the attribute information of a first storage model, and the storage model is a model of data stored in the database.

A persistence unit 43, configured to persistence each of the first data models into a first storage model in the database according to a storage script of each of the first data models.

Optionally, the traversing unit 41 is further configured to:

Optionally, the generating unit 42 is further configured to:

Optionally, the apparatus 4 further comprises:

A query unit 44, configured to generate a query script of the database according to a query instruction sent by an application program;

Optionally, the querying unit 44 is further configured to:

It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein.

In addition, the data persistence device shown in fig. 4 may be a software unit, a hardware unit, or a unit combining soft and hard, which are built in an existing terminal device, may be integrated into the terminal device as an independent pendant, or may exist as an independent terminal device.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

Fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 5, the terminal device 5 of this embodiment comprises at least one processor 50 (only one is shown in fig. 5), a memory 51 and a computer program 52 stored in said memory 51 and executable on said at least one processor 50, said processor 50 implementing the steps in any of the respective data persistence method embodiments described above when said computer program 52 is executed.

The terminal equipment can be computing equipment such as a desktop computer, a notebook computer, a palm computer, a cloud server and the like. The terminal device may include, but is not limited to, a processor, a memory. It will be appreciated by those skilled in the art that fig. 5 is merely an example of the terminal device 5 and is not meant to be limiting as the terminal device 5, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.

The Processor 50 may be a central processing unit (Central Processing Unit, CPU), the Processor 50 may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), off-the-shelf Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 51 may in some embodiments be an internal storage unit of the terminal device 5, such as a hard disk or a memory of the terminal device 5. The memory 51 may in other embodiments also be an external storage device of the terminal device 5, such as a plug-in hard disk provided on the terminal device 5, a smart memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD) or the like. Further, the memory 51 may also include both an internal storage unit and an external storage device of the terminal device 5. The memory 51 is used for storing an operating system, application programs, boot Loader (Boot Loader), data, other programs, etc., such as program codes of the computer program. The memory 51 may also be used to temporarily store data that has been output or is to be output.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, performs the steps of the respective method embodiments described above.

The embodiments of the present application provide a computer program product enabling a terminal device to carry out the steps of the method embodiments described above when the computer program product is run on the terminal device.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium can include at least any entity or device capable of carrying computer program code to an apparatus/terminal device, a recording medium, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other manners. For example, the apparatus/terminal device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The foregoing embodiments are merely illustrative of the technical solutions of the present application, and not restrictive, and although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that modifications may still be made to the technical solutions described in the foregoing embodiments or equivalent substitutions of some technical features thereof, and that such modifications or substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing data persistence of multiple tables, characterized by comprising:

Traverse the rows and columns of each first data model in the first data set to be persisted, and obtain the attribute information of each first data model; wherein the data model is a model for storing data in memory; the attribute information of the data model includes attribute name, data type, data state and data value corresponding to each attribute name; the data state includes three operation types: adding, modifying and deleting; the first data model is a collection of multiple data models;

Generate a storage script for the database of each first data model according to the attribute information in each first data model that meets the first preset condition; wherein the first preset condition includes that the attribute information of the first data model is consistent with the attribute information of the first storage model; the storage model is a model for storing data in the database;

Persisting each of the first data models as a first storage model in the database according to the storage script of each of the first data models;

The traversing each first data model in the first data set to be persisted to obtain the attribute information of each first data model includes:

If the attribute information of the first data model includes a second data set, traversing each second data model in the second data set to obtain the attribute information of each second data model; wherein the attribute information of the first data model includes the attribute information of the second data model;

The step of generating a storage script for the database of each first data model according to the attribute information satisfying the first preset condition in each first data model comprises:

Generate a script template corresponding to the data state in the attribute information of the first data model;

A storage script for a database of the first data model is generated according to the script template and data values corresponding to attribute names in the first data model that meet a first preset condition.

2. The method for processing multi-table data persistence according to claim 1, wherein the attribute information includes an attribute name and a data type; the method further comprises:

For each of the first data models, if the table name corresponding to the first data model is consistent with the table name corresponding to the first storage model in the database, determine whether the first name is consistent with the second name; wherein the first name is the attribute name in the attribute information of the first data model, and the second name is the attribute name in the attribute information of the first storage model;

If the first name is consistent with the second name, determining whether the data type corresponding to the first name is consistent with the data type corresponding to the second name;

If the data type corresponding to the first name is consistent with the data type corresponding to the second name, it is determined that the first name meets the first preset condition.

3. The method for processing multi-table data persistence according to claim 1 or 2, characterized in that the method further comprises:

Generate a query script for the database according to the query instruction sent by the application;

Acquire a third data set from the database according to a query script of the database; wherein the third data set includes at least one second storage model;

Obtaining attribute information of a third data model according to the model type corresponding to the query script; wherein the third data model is used to generate a query result corresponding to the query instruction;

The third data model is obtained by converting the attribute information that satisfies a second preset condition in each of the second storage models of the third data set; wherein the second preset condition includes that the attribute information of the second storage model is consistent with the attribute information of the third data model.

4. The method for processing multi-table data persistence according to claim 3, characterized in that the step of obtaining a third data set from the database according to a query script of the database comprises:

Acquire a second storage model corresponding to the query script from the database to obtain first data;

A second storage model associated with the first data is acquired from the database to obtain second data; wherein the third data set includes the first data and the second data.

5. The method for processing multi-table data persistence according to claim 3, characterized in that the attribute information includes an attribute name and a data value corresponding to the attribute name;

The step of generating the third data model according to the attribute information satisfying the second preset condition in each of the second storage models of the third data set comprises:

For each of the second storage models, if the third name is consistent with the fourth name, determine whether the data type corresponding to the third name is consistent with the data type corresponding to the fourth name; wherein the third name is the attribute name in the attribute information of the second storage model, and the fourth name is the attribute name in the attribute information of the third data model;

If the third name is consistent with the fourth name, the data value corresponding to the third name in the second storage model is assigned to the member corresponding to the fourth name in the third data model.

6. The method for processing multi-table data persistence according to claim 3, characterized in that the method further comprises:

After obtaining the query result corresponding to the query instruction, the connection between the application and the database is disconnected.

7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 6 when executing the computer program.

8. A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1 to 6.