Database middleware development method and system based on reverse ORM

Abstract

The invention discloses a database middleware development method based on reverse ORM. Database middleware is divided into a relational data structure management RSM module and a relational data operation engine ROE module. And when a business level needs to access a certain relational data table, if the structure of the relational data table does not exist in the memory, the RSM module is connected with and queries table establishment information of the relational data table, and updates the table establishment information to the universal relational data structure in the memory, and the structure of the relational data table is dynamically generated in the memory after updating. And the ROE module automatically converts an operation statement of a business level into a security standard SQL statement, and the generated SQL statement executes an operation on the underlying database. According to the application, hard coding of the object structure and the relational data structure in the software code is avoided when the business is changed or newly added every time.

Description

Technical Field

[0001] The present application relates to a software development method, and in particular to a database middleware development method. Background Art

[0002] A database consists of one or more tables. A table contains one or more rows of data, each row of data is called a record. A record contains one or more fields, and a field is a column in the table.

[0003] Traditional software development methods based on ORM (Object Relation Mapping) map data tables to classes, records to objects, and fields to object attributes. A class is a template for an object, and an object is an instance of a class. Object attributes are variables that record the object's properties and state.

[0004] For example, to implement the addition, deletion, modification, and query of a company's basic information data in the business, the existing ORM-based software development method includes the following steps, such as Figure 1 shown.

[0005] Step S11: Count the various attributes of the enterprise, such as enterprise name, unified social credit code, legal person name, etc. This step is to design the object structure.

[0006] Step S12: Based on the various attributes of the enterprise, multiple columns (multiple fields) are set in the relational data table, and each field records the various attributes of the enterprise to construct a data table. This step is to design the relational data structure based on the object structure.

[0007] Step S13: Write the mapping relationship between the enterprise's attributes and the fields of the data table in the software code. This step is to configure the mapping relationship between the object structure and the relational data structure.

[0008] Step S14: Write in the software code how the operations on "enterprise" (add, delete, modify, check) correspond to the corresponding operations in the database. This step is to convert the user's operations on the object into operations on the relational data in the database.

[0009] When the business is expanded or changed, it is often necessary to correspondingly adjust the existing mapping relationship from the object structure to the relational data structure or establish a new mapping relationship, that is, repeat the operations of the above steps S11 to S13.

[0010] As the examples above demonstrate, the existing ORM-based software development approach prioritizes the object structure over the relational data structure of the database table. During the software development phase, these two structures are hard-coded in the code, forming a mapping between the two and ultimately generating business data operation statements. This development model gives software developers excessive control over database tables, such as creating tables and adding new fields.

[0011] Furthermore, existing ORM-based software development methods lack convenient support for "join" operations on relational data. Join operations (also known as table joins) involve linking data from two or more tables. For example, Table A contains company information, and Table B contains company branches. To query a company's branches, existing ORM-based software development methods generally offer the following two approaches.

[0012] The first implementation method is step-by-step query. First, query the company information from Table A, then query the company's branches from Table B based on the company information, and finally combine the company information and branch information.

[0013] The second implementation method is a joint table query. This method requires first defining a new object structure with "enterprise + branch" attributes in the software code, then designing a new data structure based on this new object structure. Finally, using this new data structure, a join operation is performed on Table A and Table B, allowing the data in both tables to be queried.

[0014] Based on the above analysis, existing ORM-based software development methods have the following two main shortcomings. First, changes to relational data structures require not only modifying the object structure but also the mapping between the object structure and the relational data structure. Second, business development becomes more complex when joining multiple tables.

[0015] With the rapid growth of enterprise business scale, it is more reasonable to delegate the management of the underlying database to professional DBAs (Database Administrators). Software developers should focus more on business-level logic and business-level databases, thereby isolating the underlying database (i.e., the basic database) from the business layer to prevent the entire basic database from becoming unavailable due to a business development error. Therefore, a reverse ORM development model is needed, which allows software developers to automatically obtain the database table structure from the software level, rather than hard-coding the object structure before the software runs (during the development process), making the developed software more automated and controllable.

[0016] The underlying database is typically accessed by multiple departments, and a separate middleware layer is typically implemented in the technical architecture. Database middleware acts as a proxy between the application and the database, allowing applications to access the database through the middleware without having to communicate directly with the database. This facilitates unified management of CRUD (Create, Read, Update, Delete) operations across the underlying database. On the one hand, to ensure the legality and standardization of SQL (Structured Query Language), field types must be converted accordingly. On the other hand, some fields also require legality checks, such as length limits. Therefore, the middleware layer must possess the structural information of each database table during the service process. Typically, software developers configure the software code based on this database table structure information, which is inefficient. Summary of the Invention

[0017] The technical problem to be solved by this application is: how to build a more automated, more secure, more flexible and controllable database middleware service based on the reverse ORM development model.

[0018] To address the above-mentioned technical problems, the present application proposes a database middleware development method based on reverse ORM, comprising the following steps. Step S21: The database middleware is divided into two parts: a relational data structure management (RSM) module and a relational data operation engine (ROE) module; the RSM module is used to manage a set of universal relational data structures in memory. Step S22: When the business layer needs to access a relational data table, the RSM module queries the memory for the structure of the relational data table. If the relational data table structure is not already in memory, the RSM module connects to and queries the table creation information of the relational data table, and updates it to the universal relational data structure in memory. After the update, the relational data table structure is dynamically generated in memory, and the business layer accesses the generated relational data table structure in memory. If the relational data table structure is already in memory, the business layer accesses the generated relational data table structure in memory. Step S23: The ROE module performs a validity check and formats the business layer input data for each field of the data table structure dynamically generated in memory by the RSM module. Step S24: The ROE module receives business-level operation statements written by software developers using a chain of SQL-like function calls, specifically targeting the data table structure dynamically generated in memory by the RSM module. Step S25: The ROE module automatically converts the business-level operation statements into safe and compliant SQL statements, connects to the underlying database that the business level needs to access, and executes the generated SQL statements on the underlying database.

[0019] Furthermore, in step S1, the general relational data structure includes at least four fields: field name, field type, field length, and field index information; wherein the field index information refers to whether the relational database creates an index on the field.

[0020] Furthermore, in step S21, the universal relational data structure encompasses various relational data structures and has universality.

[0021] Furthermore, in step S22, the table creation information of the relational data table that needs to be accessed at the business level includes field name, field type, field length, and field index information.

[0022] Furthermore, in step S22, the delay concept of copy-on-write (COW) is adopted.

[0023] Furthermore, in step S24, the ROE module also constructs a corresponding object structure based on the data table structure dynamically generated in the memory by the RSM module; the operation statement at the business level is an operation on the object structure at the business level.

[0024] Furthermore, in step S24, all business-level operation statements written by software developers are written for the data table structure dynamically generated in the memory.

[0025] Furthermore, when there are expansions or changes at the business level, software developers only develop the data table structure dynamically generated in memory by the RSM module at the database middleware level, and cannot modify the underlying database content.

[0026] Furthermore, when a business query requires a table join operation, the join function is called to pass in the information required for the table join, and the SQL statement for the table join operation is automatically generated, without the need to describe the object structure and relational data structure in the software code.

[0027] The present application also proposes a database middleware development system based on reverse ORM, which includes two parts: an RSM module and an ROE module. The RSM module is used to manage a set of general relational data structures in memory; when the business level needs to access a certain relational data table, the RSM module queries whether the structure of the relational data table exists in the memory. If it is found that the structure of the relational data table does not exist in the memory, the RSM module connects and queries the table creation information of the relational data table, and updates it to the general relational data structure in the memory. After the update, the structure of the relational data table is dynamically generated in the memory, and the business level accesses the structure of the relational data table generated in the memory; if it is found that the structure of the relational data table already exists in the memory, the business level accesses the structure of the relational data table generated in the memory. The ROE module performs a validity check and formatting process on the business-level input data of each field of the data table structure dynamically generated in the memory by the RSM module; the ROE module also receives business-level operation statements written by software developers through a function call chain of SQL-like syntax, which are only for the data table structure dynamically generated in the memory by the RSM module; the ROE module also automatically converts the business-level operation statements into safe and standardized SQL statements, and connects to the underlying database that the business level needs to access, and the generated SQL statements perform operations on the underlying database.

[0028] The technical effect achieved by this application is: avoiding the need to hard-code object structures and relational data structures in software code every time a business is changed or added, thereby greatly improving the system's adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a flowchart of the existing ORM-based software development method.

[0030] Figure 2 This is a flowchart of the database middleware development method based on reverse ORM proposed in this application.

[0031] Figure 3 This is a schematic diagram of the structure of the database middleware development system based on reverse ORM proposed in this application.

[0032] Description of reference numerals in the figure: RSM module 31, ROE module 32. DETAILED DESCRIPTION

[0033] See also Figure 2 The database middleware development method based on reverse ORM proposed in this application includes the following steps.

[0034] Step S21: Divide the database middleware into two parts: an RSM (relation data structure management) module and a ROE (relation data operation engine) module.

[0035] The RSM module is used to manage a set of common relational data structures in memory.

[0036] Existing ORM-based software development methods design corresponding relational data structures for each object structure during the software development phase, based on one or more business-level object structures. For example, a company (object 1) has four attributes (object structure 1): company name, unified social credit code, legal representative, and registered capital. The relational data structure of Table 1 is composed of four fields: company name, unified social credit code, legal representative, and registered capital. A natural person (object 2) has three attributes (object structure 2): name, ID card, and gender. The relational data structure of Table 2 is composed of three fields: name, ID card, and gender.

[0037] The general relational data structure proposed in this application includes at least four fields: field name, field type, field length, and field index information. Among them, field index information refers to whether the relational database has created an index on the field. In a relational database, fields with indexes can be used as filter conditions for query, which is more efficient; fields without indexes cannot be used as filter conditions for query. For example, the field index information has the following four values: K represents a unique key (with index), U represents a unique index, I represents a normal index, and N represents no index.

[0038] The universal relational data structure proposed in this application can encompass various relational data structures and is universal, which will be illustrated below through several examples.

[0039] Example 1: Table 1 has a field called "Company Name." In a common relational data structure, this field can be represented by the following row of data: field name "Company Name," field type "String," field length (e.g., 100 bytes), and field index "1."

[0040] Example 2: A field in Table 1 is "Unified Social Credit Code." In a common relational data structure, this field can be represented by the following row of data: field name: "Unified Social Credit Code," field type: numeric, field length: three bytes, for example, and field index: U.

[0041] Example 3: Table 2 has a field called "gender." In a common relational data structure, this field can be represented by the following row of data: field name "gender," field type Boolean, field length (e.g., two bytes), and field index information (N).

[0042] Step S22: When the business layer needs to access a certain relational data table C, the RSM module queries whether the structure of the relational data table C (ie, the relational data structure) exists in the memory.

[0043] If the structure of relational data table C is not found in the memory, the RSM module connects to and queries the table creation information (field name, field type, field length, and field index information) of relational data table C, and updates it to the universal relational data structure in the memory. After the universal relational data structure is updated, the structure of relational data table C is dynamically generated in the memory, and the business layer accesses the generated structure of relational data table C in the memory.

[0044] If it is found that the structure of the relational data table C already exists in the memory, the business layer accesses the structure of the relational data table C generated in the memory.

[0045] This step does not require preloading the structure of the relational data table C in the memory, but adopts a delay concept similar to COW (copy on write).

[0046] Step S23: The ROE module performs a validity check and formats the business-level input data (e.g., query data, write data, etc.) for each field of the data table structure dynamically generated in memory by the RSM module. For example, the validity check involves checking whether the business-level input data for each field complies with the corresponding field type and field length constraints. Formatting involves formatting the business-level input data for each field to meet the requirements.

[0047] For example, at the business level, the data "January 1, 2025" needs to be written into the "Date" field of a certain table. The RSM module formats the received written data "January 1, 2025" in this field and converts it into "2025-01-01".

[0048] For example, at the business level, the data "Company A" needs to be written into the "Company Name" field of Table 1. The RSM module formats the received data "Company A" written into the field and adds single quotes to obtain "'Company A'".

[0049] Step S24: The ROE module constructs a corresponding object structure based on the data table structure (i.e., relational data structure) dynamically generated in the memory by the RSM module. Software developers write business-level operation statements for operations on the object structure through a function call chain of SQL-like syntax (instead of directly writing native SQL statements). The business-level operation statements only perform various operations on the data table structure dynamically generated in the memory by the RSM module. This step uses native SQL-like operations, which has a good guarantee for development efficiency and flexibility. In addition, all software developers write operation statements for the data table structure dynamically generated in the memory (essentially for the general relational data structure), which can avoid different software developers writing different styles of business-level operation statements.

[0050] For example, for each relational data operation in the data table structure dynamically generated in memory by the RSM module, the business-level operation statement creates an operation object through the create() and other functions of the ORM class, and at the same time completes the information filling of the operation process by calling the function chain of SQL-like syntax, and finally calls the save() and other submission operation functions to complete the specific relational data operation.

[0051] Step S25: The ROE module automatically converts the business-level operation statements into safety-standard SQL statements, and connects to the corresponding underlying relational database C. The generated SQL statements perform operations on the underlying relational database C.

[0052] Business-level operations are written using a chain of SQL-like function calls, targeting only the data table structure dynamically generated in memory by the RSM module. After conversion by the ROE module, these statements become secure, standardized SQL statements targeting the underlying relational database C. This mitigates the security risk of SQL injection at the engine level and ensures data security in the underlying database.

[0053] See also Figure 3 The database middleware development system based on reverse ORM proposed in this application includes two parts: RSM module 31 and ROE module 32.

[0054] The RSM module 31 is used to manage a set of universal relational data structures in memory. When the business layer needs to access a certain relational data table, the RSM module 31 queries the memory to see whether the structure of the relational data table C exists. If the structure of the relational data table C is not found in the memory, the RSM module 31 connects and queries the table creation information of the relational data table C, and updates the table creation information to the universal relational data structure in the memory. After the update, the structure of the relational data table C is dynamically generated in the memory, and the business layer accesses the structure of the relational data table C that has been generated in the memory. If the structure of the relational data table C is found to already exist in the memory, the business layer accesses the structure of the relational data table C that has been generated in the memory.

[0055] The ROE module 32 performs validity checks and formatting on the business-level input data for each field of the data table structure dynamically generated in memory by the RSM module 31. The ROE module 32 also constructs a corresponding object structure based on the data table structure dynamically generated in memory by the RSM module 31. It also receives business-level operation statements written by software developers using SQL-like function call chains, specifically targeting the data table structure dynamically generated in memory by the RSM module. The ROE module 32 also automatically converts the business-level operation statements into safe and compliant SQL statements, connects to the corresponding underlying relational database C, and executes the generated SQL statements on the underlying relational database C.

[0056] The database middleware development method based on reverse ORM proposed in this application has the following beneficial effects.

[0057] First, when there are expansions or changes at the business level, software developers only need to develop the data table structure dynamically generated in memory by the RSM module at the database middleware level, and cannot modify the underlying database content, thereby isolating the underlying database from the business level and ensuring the data security of the underlying database.

[0058] Second, the existing software development method based on ORM requires defining a new object structure in the software code before performing a joint table operation, and designing a new data structure through the new object structure. This application provides a join operation function for the scenario of joint table operation. In this application, since the relational data structure of each specific data table is dynamically generated based on a general relational data structure, when a business query requires a joint table operation, the information required for the joint table is passed in by calling the join function, and the SQL statement for the joint table operation can be automatically generated. Regardless of whether it is for a single table or for a joint table operation scenario, this application does not need to describe the object structure and relational data structure in the software code, and truly achieves dynamic on-demand loading and flexible access.

[0059] Third, the existing ORM-based software development method is to first have an object structure and then a relational data structure associated with the object structure. However, this application weakens the concept of object structure. The business level does not need to predetermine the object structure, but instead achieves "take it when needed", which is a manifestation of reverse thinking. This application uses a universal relational data structure to uniformly manage various data table structures, and then passes in various existing relational data structures as parameters of the universal relational data structure, thereby dynamically generating the structures of the underlying databases in memory, and ultimately solving the various inconveniences brought about by the existing ORM-based software development method.

[0060] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A database middleware development method based on reverse ORM, characterized by: The method includes the following steps: Step S21: The database middleware is divided into two parts: a relational data structure management (RSM) module and a relational data operation engine (ROE) module; the RSM module is used to manage a set of common relational data structures in memory; Step S22: When the business layer needs to access a certain relational data table, the RSM module queries whether the structure of the relational data table exists in the memory; If it is found that the structure of the relational data table does not exist in the memory, the RSM module connects and queries the table creation information of the relational data table, and updates it to the universal relational data structure in the memory. After the update, the structure of the relational data table is dynamically generated in the memory, and the business layer accesses the generated structure of the relational data table in the memory; If it is found that the structure of the relational data table already exists in the memory, the business layer accesses the structure of the relational data table generated in the memory; Step S23: The ROE module performs a validity check and formatting process on the business-level input data of each field of the data table structure dynamically generated in the memory by the RSM module; Step S24: the ROE module receives a business-level operation statement written by a software developer through a function call chain in a SQL-like syntax, which operates only on the data table structure dynamically generated in the memory of the RSM module; Step S25: The ROE module automatically converts the operation statements at the business level into SQL statements that meet security standards, connects to the underlying database that the business level needs to access, and uses the generated SQL statements to perform operations on the underlying database.

2. The database middleware development method based on reverse ORM according to claim 1 is characterized in that: In step S1, the general relational data structure includes at least four fields: field name, field type, field length, and field index information; wherein the field index information refers to whether the relational database creates an index on the field.

3. The database middleware development method based on reverse ORM according to claim 1 is characterized in that: In step S21, the universal relational data structure encompasses various relational data structures and has universality.

4. The database middleware development method based on reverse ORM according to claim 1 is characterized in that: In step S22, the table creation information of the relational data table that needs to be accessed at the business level includes field name, field type, field length, and field index information.

5. The database middleware development method based on reverse ORM according to claim 1 is characterized in that: In step S22, the delay concept of copy-on-write (COW) is adopted.

6. The method for developing database middleware based on reverse ORM according to claim 1, wherein: In step S24, the ROE module also constructs a corresponding object structure based on the data table structure dynamically generated in the memory by the RSM module; the operation statement at the business level is an operation on the object structure at the business level.

7. The database middleware development method based on reverse ORM according to claim 1 is characterized in that: In step S24, all business-level operation statements written by software developers are written for the data table structure dynamically generated in the memory.

8. The method for developing database middleware based on reverse ORM according to claim 1, wherein: When there are expansions or changes at the business level, software developers only develop the data table structure dynamically generated in memory by the RSM module at the database middleware level, and cannot modify the underlying database content.

9. The database middleware development method based on reverse ORM according to claim 1, characterized in that: When a business query requires a table join operation, the join function is called to pass in the information required for the table join, and the SQL statement for the table join operation is automatically generated. There is no need to describe the object structure and relational data structure in the software code.

10. A database middleware development system based on reverse ORM, characterized by: It includes two parts: RSM module and ROE module; The RSM module is used to manage a set of general relational data structures in memory; when the business layer needs to access a certain relational data table, the RSM module queries whether the structure of the relational data table exists in the memory. If it is found that the structure of the relational data table does not exist in the memory, the RSM module connects and queries the table creation information of the relational data table, and updates it to the universal relational data structure in the memory. After the update, the structure of the relational data table is dynamically generated in the memory, and the business layer accesses the generated structure of the relational data table in the memory; If it is found that the structure of the relational data table already exists in the memory, the business layer accesses the structure of the relational data table generated in the memory; The ROE module performs a validity check and formatting process on the business-level input data of each field of the data table structure dynamically generated in the memory by the RSM module; The ROE module also receives business-level operation statements written by software developers through a function call chain in SQL-like syntax, which are only for the data table structure dynamically generated in the memory by the RSM module; the ROE module also automatically converts the business-level operation statements into safe and standardized SQL statements, and connects to the underlying database that needs to be accessed at the business level, and the generated SQL statements perform operations on the underlying database.

Images