Data management method and device, storage medium and electronic equipment

Abstract

The invention discloses a data management method and device, a storage medium and electronic equipment. The method comprises the steps of obtaining connection configuration information of a target business database and structured metadata of a target management table; based on the structured metadata, the data management rule and the grammar rule of the target business database, generating an SQL statement corresponding to the data operation type; based on the structured metadata and the data management rule, content adaptation and logic binding are carried out on a preset interface basic template, static interface resources are generated, and the static interface resources are used for being loaded by front-end equipment to generate a data management interface; and receiving an operation request initiated by the front-end equipment based on the data management interface, executing a corresponding data operation in the target business database based on an SQL statement corresponding to the operation request, and feeding back an operation result to the front-end equipment, so that the front-end equipment displays the operation result in the data management interface.

Description

Technical Field

[0001] This application relates to the field of data management technology, and in particular to a data management method, apparatus, storage medium and electronic device. Background Technology

[0002] Currently, in business data management scenarios, developers need to build data management functions through two independent steps: First, they need to select the corresponding template from a preset SQL template library, manually replace placeholders such as table names, field lists, and condition fields to generate SQL statements that adapt to the target management table, and hardcode them into the backend interface logic; Second, they need to independently develop the front-end interface based on a general UI framework, design interactive controls (such as the text input box corresponding to the "order_id" field) according to the field attributes of the target management table, and write code to bind the click events of the query, add, and other operation buttons on the interface to the corresponding backend interface URL.

[0003] In the above scheme, the front-end interface development and the back-end SQL generation are independent of each other: the naming of front-end interface controls and the definition of request parameters depend on the developers' subjective understanding of table fields, while the field names and table names of back-end SQL depend on the manual replacement of template placeholders. The two lack a standardized collaboration mechanism on key information such as field identification and parameter format, which may lead to data transmission failure. Summary of the Invention

[0004] In view of the above problems, this application provides a data management method, apparatus, storage medium and electronic device.

[0005] To solve the above-mentioned technical problems, this application proposes the following solution:

[0006] Firstly, this application provides a data management method, which includes: obtaining connection configuration information of a target business database and structured metadata of a target management table, wherein the connection configuration information is used to establish an interaction link between a backend device and the target business database; obtaining data management rules set for the target management table, wherein the data management rules include at least the types of data operations to be executed; generating SQL statements corresponding to the data operation types based on the structured metadata, data management rules, and syntax rules of the target business database; performing content adaptation and logical binding on a preset interface template based on the structured metadata and data management rules to generate static interface resources, wherein the static interface resources are used for the frontend device to load and generate a data management interface; receiving operation requests initiated by the frontend device based on the data management interface; executing corresponding data operations in the target business database based on the SQL statements corresponding to the operation requests; and feeding back the operation results to the frontend device so that the frontend device can display the operation results in the data management interface.

[0007] Since the SQL statements in this application are generated based on structured metadata and data management rules, and the static interface resources are also built based on structured metadata and data management rules, and the interactive functions of the data management interface correspond one-to-one with the SQL statements for the corresponding data operation types, this application eliminates the need for developers to manually adjust the matching relationship between interface controls and SQL statements. Through the unified support of structured metadata and data management rules, the interactive functions of the data management interface can directly and accurately correspond to the SQL statements for the corresponding operation types. When the front-end device initiates an operation request based on the interface, it can directly call the matching SQL statement to execute the data operation, avoiding issues such as operation buttons on the interface without corresponding SQL or SQL not matching the operation intent caused by manual binding errors, thus ensuring effective connection between front-end requests and back-end SQL execution.

[0008] In conjunction with the first aspect, in one possible implementation, the structural elements of the SQL statement are determined based on the data operation type, and a mapping relationship between the structural elements and the SQL syntax components is established according to the syntax rules of the target business database. Based on the mapping relationship, the structural elements are filled into the SQL basic framework corresponding to the data operation type to generate an SQL statement that conforms to the syntax specifications of the target business database.

[0009] By leveraging the database syntax mapping table built into the backend device, the mapping relationship between the SQL statement structure elements and syntax components is first clarified, and then populated into the SQL basic framework of the corresponding operation type. This allows the generated SQL statement to accurately adapt to the syntax specifications of the target business database, eliminating the need for developers to manually adapt to the syntax differences between different databases. This reduces the risk of SQL execution errors caused by improper syntax adaptation, improves the accuracy and efficiency of SQL statement generation, and enhances the solution's adaptability to multiple database types.

[0010] In conjunction with the first aspect, in another possible implementation, for query-type data operations, the list of filter fields, table name, and data processing constraints of the target management table are determined based on structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement containing the list of filter fields, the table name of the target management table, and data processing constraints, and conforming to the syntax rules of the target business database, is generated. For insert-type data operations, the table name, the list of fields to be inserted, and the auto-incrementing primary key field identifier of the target management table are determined based on structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement containing the table name of the target management table, the list of fields to be inserted, and parameter placeholders, and conforming to the syntax rules of the target business database, is generated. The SQL statements conform to the syntax rules of the target business database. For data modification operations, based on structured metadata, the table name, fields to be modified, and primary key fields of the target management table are determined. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that includes the table name, fields to be modified, parameter placeholders, and primary key locating conditions based on the primary key fields, while also conforming to the syntax rules of the target business database. For data deletion operations, based on structured metadata, the table name and primary key fields of the target management table are determined. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that includes the table name, primary key locating conditions based on the primary key fields, and also conforms to the syntax rules of the target business database.

[0011] For four types of data operations—query, add, modify, and delete—key information is extracted from structured metadata and combined with a database syntax mapping table to generate SQL statements that conform to grammatical rules. This ensures that the generated SQL for each type of operation is clearly targeted and precise. For example, query operations precisely include filter fields, table names, and data processing constraints, while modification operations explicitly define the primary key correlation conditions. This avoids issues such as omitted fields and missing conditions that may occur with general generation methods, ensuring that all types of data operations can be executed efficiently using standardized SQL statements.

[0012] In conjunction with the first aspect, another possible implementation involves extracting field identifiers and data types from the target management table from structured metadata, and extracting field display rules, data operation types to be executed, and interface style requirements from data management rules. Based on the extracted field identifiers, data types, and display rules, data query area tags, data display area tags, and operation interaction area tags are constructed in the HTML file of the interface base template. According to the interface style requirements, style rules corresponding to each area tag in the HTML file are added to the CSS file of the interface base template. According to the data operation types to be executed, association logic and request processing logic are configured in the JS file of the interface base template. The association logic is used to bind the operation buttons in the data management interface corresponding to each data operation type to the request interface of the backend device that matches the corresponding data operation type. The request processing logic is used to enable the frontend device to establish interaction with the backend device when it initiates an operation request based on the data management interface.

[0013] Key information is extracted from structured metadata and data management rules, and the HTML, CSS, and JS files of the basic interface template are adapted and bound accordingly. This ensures that the generated static interface resources accurately match the field attributes of the target management table while meeting the requirements for interface style and interactive functionality. The area tags in the HTML file correspond to the field information, the CSS style rules precisely adapt to the interface requirements, and the JS logic effectively binds the operation buttons to the backend interface. This eliminates the need for developers to separately develop the frontend interface and write interaction logic, greatly reducing frontend development costs while ensuring the consistency between the frontend interface and backend data operations.

[0014] In conjunction with the first aspect, in another possible implementation, the type of the target business database is determined based on the database type identifier in the connection configuration information; the corresponding database driver is matched from the integrated multi-type database drivers according to the type of the target business database, and the database driver is used to realize communication with the target business database; a network connection between the backend device and the target business database is established through the network address and access port in the connection configuration information, forming an interaction link between the backend device and the target business database.

[0015] By matching the database type identifier in the connection configuration information with the corresponding driver, and then establishing an interaction link based on the network address and access port, a standardized database connection process is formed. This process can automatically adapt to different types of business databases, eliminating the need for developers to manually configure drivers and connection parameters. This avoids database connection failures caused by driver incompatibility or incorrect connection parameters, ensuring that backend devices can establish stable and efficient communication with the target business database, laying a solid foundation for the smooth execution of subsequent data operations.

[0016] In conjunction with the first aspect, another possible implementation involves activating a data operation verification mechanism. This mechanism verifies the legality and consistency of the SQL statement execution process and its results. If the data operation verification mechanism passes, the SQL statement execution result is confirmed to be valid and the data is persisted. If the data operation verification mechanism fails, an exception handling strategy is triggered to undo the impact of the executed SQL statement on the target business database.

[0017] A data operation validation mechanism is introduced to verify the legality and consistency of SQL statement execution and results. Data is persisted only after the validation passes; otherwise, exception handling is triggered and the impact is reversed. This mechanism effectively avoids the impact of illegal operations and data inconsistencies on the target business database. For example, it prevents data corruption caused by erroneous SQL statements, ensuring the integrity and accuracy of data in the database, while reducing subsequent maintenance costs caused by data anomalies.

[0018] In conjunction with the first aspect, in another possible implementation, based on the type of data operation to be executed and the field attributes of the target management table in the structured metadata, the corresponding transaction initialization parameters are matched from the preset transaction configuration template library. A database transaction is then initiated based on these parameters. The database transaction integrates all related SQL statements initiated by the backend device against the target management table in the target business database into an indivisible operation unit. When all SQL statements within the operation unit have been executed, passed validation, and have not timed out, the execution results of all SQL statements are permanently effective in the database. The number of rows affected by the operation after the backend device executes the SQL statement corresponding to the operation request is obtained. This number indicates the number of records in the target management table of the target business database that have undergone actual data changes. The number of rows affected by the operation is validated according to the preset standard for the number of rows affected in the data management rules. For operations involving business logic relationships, based on the table relationships recorded in the structured metadata, the target field data of the related tables in the target business database is queried, and the target field data of the related tables is verified to ensure it conforms to the preset business logic.

[0019] Based on the data operation type and target management table field attributes, the transaction initialization parameters are matched to initiate a database transaction to integrate the join SQL statements. Then, the legality of the operation is ensured through row count verification and business logic verification. Finally, the transaction is committed or rolled back based on the verification results. This approach effectively avoids data inconsistency issues caused by the partial success of join SQL statements. For example, join operations between the order table and the payment table can remain synchronized. Furthermore, a timeout mechanism prevents transactions from occupying resources for extended periods, further guaranteeing the security and reliability of data operations.

[0020] In conjunction with the first aspect, another possible implementation involves: performing a basic check on the number of rows affected by the operation based on a threshold range in the data management rules; indicating that the basic check fails when the number of rows affected by the operation exceeds the upper or lower limit of the threshold range; performing a dynamic check on the number of rows affected by the operation based on a dynamic fluctuation threshold; indicating that the dynamic threshold check fails when the number of rows affected by the operation exceeds the dynamic fluctuation threshold, where the dynamic fluctuation threshold is calculated by weighting the historical number of rows affected by the operation in the target management table within a preset time range using a time decay factor; obtaining the number of rows affected by synchronous operations in the associated tables and establishing a mapping relationship between the number of rows affected by the operation and the number of rows affected by synchronous operations; indicating that the association check fails when the mapping relationship does not conform to the preset business association ratio rules, where the associated tables are management tables that have business associations or data dependencies with the target management table when the backend device executes the SQL statement corresponding to the operation request on the target management table in the target business database.

[0021] The system comprehensively verifies the number of rows affected by operations across three dimensions: basic verification, dynamic verification, and correlation verification. Basic verification ensures that operations comply with preset threshold ranges; dynamic verification, combined with historical data, avoids abnormal fluctuations in operations; and correlation verification ensures the matching of operations between the target table and related tables. This multi-dimensional verification mechanism can accurately identify operations that do not conform to business rules, such as batch operations exceeding reasonable limits or imbalanced operation ratios in related tables, further improving the legality and rationality of data operations and reducing the impact of violations on business data.

[0022] In conjunction with the first aspect, another possible implementation involves constructing a query update frequency matrix based on historical query frequency data of SQL statements querying the target management table and the update frequency characteristics of the table data. According to the query update frequency matrix, query results with high-frequency queries and low-frequency updates are classified into a first-level cache, and the query results of the first-level cache are fully stored in the memory cache area of ​​the backend device. According to the query update frequency matrix, query results with medium-frequency queries and medium-frequency updates are classified into a second-level cache, and the target fields in the query results of the second-level cache are stored in the ordinary storage area of ​​the backend device. According to the query update frequency matrix, query results with low-frequency queries or high-frequency updates are classified into a third-level cache, and the query results of the third-level cache are not cached.

[0023] Query results are cached in a tiered manner based on a query update frequency matrix. Results from high-frequency queries with low-frequency updates are stored in their entirety in the high-speed cache; results from medium-frequency queries with medium-frequency updates only have their fields stored; and results from low-frequency queries or high-frequency updates are not cached. This differentiated caching strategy precisely matches the usage scenarios of different queries, ensuring fast response times for high-frequency queries, reducing database access pressure, avoiding waste of cache resources, and ensuring consistency between cached data and database data through reasonable cache storage and invalidation mechanisms, thereby improving overall data query efficiency and resource utilization.

[0024] In conjunction with the first aspect, another possible implementation involves obtaining the identity identifier and associated permission configuration information of the current user, including the accessible data range rules corresponding to the user's organization and position; matching the accessible data range rules with the field attributes in the structured metadata to determine the data permission filtering fields and their corresponding sets of legal values; embedding the conditional statement containing the data permission filtering fields and the sets of legal values ​​into the query conditions or filtering logic of the generated SQL statement to form a target SQL statement with permission control; executing the target SQL statement with permission control to return the data within the current user's permission range, and triggering a permission verification exception and providing feedback when the user initiates a request for data operation beyond their permissions.

[0025] By adding a data access scope control step after SQL statement generation and before execution, based on the current user's identity and associated permission configuration information, the system automatically matches data permission filtering fields and sets of legal values ​​and embeds SQL query conditions or filtering logic to form a target SQL statement with access control. This ensures that users can only access and operate data within their own permission scope, effectively preventing security risks such as unauthorized data access and leakage. Furthermore, it eliminates the need for developers to manually write access control code and seamlessly integrates with the existing automated SQL generation and front-end interface adaptation processes. While ensuring data security and compliance, it further enhances the usability and security of data management functions and reduces the development and maintenance costs of access control.

[0026] Secondly, this application provides a data management device, which includes:

[0027] The first acquisition module is used to acquire the connection configuration information of the target business database and the structured metadata of the target management table. The connection configuration information is used to establish the interaction link between the backend device and the target business database.

[0028] The second acquisition module is used to acquire the data management rules set for the target management table. The data management rules include at least the types of data operations to be performed.

[0029] The first generation module is used to generate SQL statements corresponding to the data operation type based on structured metadata, data management rules, and the syntax rules of the target business database.

[0030] The second generation module is used to adapt and logically bind the preset interface template based on structured metadata and data management rules to generate static interface resources. The static interface resources are used to generate the data management interface after being loaded by the front-end device.

[0031] The execution module is used to receive operation requests initiated by the front-end device based on the data management interface, execute the corresponding data operations in the target business database based on the SQL statement corresponding to the operation request, and feed back the operation results to the front-end device so that the front-end device can display the operation results in the data management interface.

[0032] To achieve the above objectives, according to a third aspect of this application, a storage medium is provided, the storage medium including a stored program, wherein, when the program is executed, the device where the storage medium is located is controlled to perform the data management method of the first aspect described above.

[0033] To achieve the above objectives, according to a fourth aspect of this application, an electronic device is provided, the device including at least one processor, and at least one memory and bus connected to the processor; wherein the processor and memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the data management method of the first aspect described above.

[0034] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0035] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0036] Figure 1 A flowchart illustrating a data management method provided in an embodiment of this application is shown;

[0037] Figure 2 This paper shows a schematic diagram of the structure of a data management system provided in an embodiment of this application;

[0038] Figure 3This illustration shows a schematic diagram of the structure of a data management device provided in an embodiment of this application;

[0039] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0040] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0041] The user data, data acquisition, and / or use involved in the embodiments of this application strictly comply with the laws, regulations, and industry standards of relevant countries and regions. The collection and acquisition of data involved in the embodiments of this application are all done in advance by actively prompting or prominently displaying information to inform users and obtaining authorization, or by obtaining full authorization from all parties. The processing, manipulation, forwarding, and use of data involved in the embodiments of this application are all carried out on the premise that the user or relevant party is fully informed and authorized. In implementing the various embodiments of this application, the types of data or information, scope of use, and usage scenarios that may be involved are informed to users or relevant parties and authorization is obtained through appropriate means. The specific methods of notification and authorization may vary according to actual circumstances, and this application is not limited in this regard. The processing of personal information involved in the embodiments of this application is carried out under the premise of having a legal basis (such as obtaining the consent of the personal information subject or being necessary for the performance of a contract), and is only processed within the scope stipulated or agreed. Sensitive personal information such as biometric information, medical and health information, financial account information, and precise location information involved in the embodiments of this application are all processed under the premise of having a specific purpose and sufficient necessity, and with the separate authorization and consent of the user or relevant party. In some embodiments of this application, if the user or related party refuses to process personal information other than the information necessary for the basic functions, it will not affect the use of the basic functions of the embodiments of this application.

[0042] In the embodiments of this application, the terms "first," "second," etc., do not have a logical or temporal dependency, nor do they limit the quantity or execution order. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another.

[0043] In this application, the term "at least one" means one or more, and the term "multiple" means two or more.

[0044] It should also be understood that the term “if” can be interpreted as “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrase “if determination…” or “if detection [the stated condition or event]” can be interpreted as “when determination…” or “in response to determination…” or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

[0045] In the current business data management scenario, developers need to perform two independent steps to build data management functions: First, they need to select templates that match the data operation to be performed (such as query or add) from a pre-set SQL template library, manually replace the placeholder elements in the templates, generate SQL statements that are adapted to the target management table, and then embed the SQL statements into the business logic code of the backend interface in a hard-coded form; Second, they need to independently develop the front-end interface based on a general UI framework, design interactive controls according to the field attributes of the target management table, and write code to bind the click events of the operation buttons in the interface to the URLs of the corresponding backend function interfaces.

[0046] In the above implementation scheme, the front-end interface development and back-end SQL statement generation are separate processes: the naming rules of the front-end interface controls and the definition format of request parameters rely entirely on the developers' subjective understanding and experience in the target management table fields; the determination of field names and table names in the back-end SQL statements depends on the developers' manual replacement of template placeholder elements. There is no standardized collaborative mechanism between the two at the level of key information such as field identification and parameter format. Taking the order management scenario as an example, during the front-end development phase, the developers named the interface input control corresponding to the "order number" "order_no" and used this name as the request parameter name to transmit query conditions to the back-end; however, during the back-end SQL statement generation phase, when manually replacing the template, the developers mistakenly set the field name corresponding to the order number to "order_id" and hardcoded the SQL statement containing this field into the query interface logic. When the front-end initiates a query request based on the interface operation and transmits the parameter "order_no=123" to the back-end, the SQL statement executed by the back-end interface cannot match the "order_no" parameter transmitted by the front-end because the query condition field is "order_id". This results in no corresponding data being returned after the SQL statement is executed, or a syntax error is triggered directly because the field does not exist. Ultimately, the link between the front-end request and the back-end execution is broken, and the effective connection of data operation cannot be achieved.

[0047] Based on this, this application provides a data management method. The data management method will be described in detail below with reference to the accompanying drawings. Figure 1This is a flowchart illustrating a data management method provided in this application. It specifically includes the following steps:

[0048] Figure 2 This is a schematic diagram of a data management system provided in one embodiment of this application. The data management system 200 includes a front-end device 210 and a back-end device 220. The front-end device 210 and the back-end device 220 communicate with each other via a network. For example, they communicate via a network 230, which can be a wired connection such as a serial cable or a Universal Asynchronous Receiver / Transmitter (UART), or a wireless connection such as a wireless signal.

[0049] Backend device 220 is used to generate SQL statements and corresponding static interface resources adapted to the database, based on unified structured metadata and data management rules. This ensures that the interactive functions of the frontend interface accurately correspond to the backend SQL statements, eliminating the need for manual binding by developers. Frontend device 210 is used to load the static interface resources generated by the backend device, presenting an operation interface corresponding to the target management table. Subsequent operation requests initiated by the user on this interface will directly correspond to the SQL statements generated by the backend device.

[0050] It should be noted that, in this embodiment, the front-end device 210 and the back-end device 220 can be terminal devices such as smartphones, tablets, and personal computers. Alternatively, they can be computing devices of a cloud service platform, such as servers or server clusters of a cloud service platform. This embodiment does not limit the specific type of device used.

[0051] Step 110: Obtain the connection configuration information of the target business database and the structured metadata of the target management table.

[0052] Since the data management methods in this application all rely on effective communication between the backend device and the target business database and a clear understanding of the target management table structure, this step first completes two preparatory tasks: obtaining the connection configuration information of the target business database and the structured metadata of the target management table.

[0053] The connection configuration information for the target business database is crucial for establishing the interaction link between the backend device and the target business database. Only through complete connection configuration can it be ensured that SQL statements can be accurately sent to the target database and return results received during subsequent data management. Specifically, the connection configuration information includes at least the database type identifier, network address, access port, login credentials, and driver adaptation parameters. These parameters together constitute the foundation for database access. The database type identifier clearly specifies the type of the target business database, such as MySQL, Oracle, or PostgreSQL. This identifier directly relates to the various database driver libraries integrated in the backend device, providing a key basis for driver matching. The network address uses a server address in IPv4 or IPv6 format. The access port is a preset or custom communication port for the database, such as MySQL's default port 3306 and Oracle's default port 1521. These two parameters together determine the database's network access path. The login credentials contain a username and password that have undergone asymmetric encryption to avoid security risks associated with plaintext storage and transmission. Driver adaptation parameters are dynamically supplemented based on the database type. For example, Oracle databases require a service name configuration, and PostgreSQL requires a database instance name configuration, ensuring that the driver accurately adapts to the database's operating environment during loading.

[0054] Regarding the acquisition of connection configuration information for the target business database, this application supports two modes: configuration interface input and configuration file import. When inputting configuration information via the interface, the backend device provides a visual form corresponding to the connection configuration information. The form has a field linkage function; when the user selects a database type, the form automatically hides irrelevant fields, such as hiding the Oracle service name field when selecting MySQL, while retaining the required and optional parameters for the current database type, guiding the user to fill in the information accurately. When importing configuration files, XML or JSON format files are supported. The files follow preset tag specifications, such as using "db-type" to identify the database type and "ip-address" to identify the network address in XML.

[0055] After obtaining the connection configuration information, the backend device also needs to verify its validity. Specifically, for the network address and port, a connectivity test is initiated via TCP / IP protocol to verify the database server's reachability. For login credentials, a simulated login request is used to verify the username and password. For the database type identifier, it is verified whether it is within the backend's list of supported database types. Upon successful verification, the connection configuration information is stored in an encrypted configuration library as key-value pairs with the database identifier and parameter type as the key.

[0056] After obtaining and validating the connection configuration information for the target business database, this information forms the foundational parameter package for establishing communication between the backend device and the target business database. Specifically, the database type identifier clarifies the driver adaptation direction, the network address and port lock the communication path, and the login credentials and driver adaptation parameters ensure access security and environmental compatibility. However, obtaining the connection configuration information alone is insufficient for data interaction. A standardized link construction process is needed to transform these discrete configuration parameters into a stable communication channel capable of transmitting SQL statements and receiving data results. The specific implementation of establishing the interaction link between the backend device and the target business database based on the aforementioned connection configuration information is as follows:

[0057] The database type identifier recorded in the connection configuration information is the basis for distinguishing the target database type and version. For example, a database type identifier of MySQL-8.0 indicates that the target business database is a MySQL 8.0 series version, and a database type identifier of Oracle-19c indicates that the target business database is an Oracle 19c version. The backend device stores a list of supported database types, including the database type name, version range, and corresponding identifier format. After obtaining the database type identifier, the backend device matches the identifier with the stored list: if the identifier format conforms to the stored rules (e.g., database type-major version number) and the version is within the supported range (e.g., the MySQL identifier MySQL-8.0 is within the stored MySQL 5.7-8.0 supported range), then the target database type is directly determined. If the identifier does not contain version information (e.g., only MySQL), then the processing logic corresponding to the latest compatible version of that database type is matched by default.

[0058] The backend device pre-integrates driver libraries for multiple database types, with each database type corresponding to an independent driver file and version adaptation submodule. For example, for MySQL databases, the driver library stores the mysql-connector-java-8.0.30.jar driver file, as well as a submodule adapted for MySQL versions 5.7-8.0, ensuring that driver resources for different database types are managed independently and do not interfere with each other. After determining the specific type and version of the target business database through the database type identifier in the connection configuration information, the backend device will perform the driver module location and invocation operation: First, it queries the corresponding driver storage path in the driver library's mapping table according to the database type identifier (e.g., the path for MySQL-8.0 is / driver / mysql / 8.0 / mysql-connector-java-8.0.30.jar); then, it locates the target driver module through the path and triggers the module loading mechanism.

[0059] After completing database driver matching and communication protocol initialization, the network connection between the backend device and the target business database is established based on the network address and access port in the connection configuration information, ultimately forming a stable data transmission link. The network address included in the connection configuration information is the valid address of the target database server and supports both IPv4 and IPv6 formats. For example, IPv4 addresses can be in dotted decimal notation, and IPv6 addresses can be in colon-hexadecimal notation. The access port corresponds exactly to the port number listened to by the target database service; different types of databases typically have default ports (e.g., MySQL's default port is 3306).

[0060] When a backend device establishes a network connection, it initiates a TCP connection request to the target database server based on the driver module with the initialized communication protocol. Taking MySQL 8.0 as an example, the backend device calls the Socket connection method encapsulated in the database driver module to send a connection request to the network address (e.g., 192.168.1.100) and access port (e.g., 3306) specified in the connection configuration information. The request data packet carries key information such as the driver identifier (e.g., mysql-connector-java-8.0.30) and the protocol version (e.g., ProtocolVersion10 for MySQL 8.0). After receiving the request, the target database server verifies the validity of the driver according to the protocol specifications it supports. If the verification passes, a TCP connection is established with the backend device.

[0061] After the TCP connection is established, the backend device decrypts the encrypted username and password stored in the connection configuration information, and then sends the decrypted login credentials to the target database server through the authentication interface provided by the driver module. The target database server verifies the received login credentials. If the verification passes, it returns a connection success response. At this point, the network connection between the backend device and the target business database is officially established, and the interaction link has data transmission capabilities.

[0062] On the other hand, the structured metadata of the target management table obtained in this application includes at least basic table information, field information, constraint information, and relationships. Basic table information includes at least the table name, table comments, creation time, and the business module to which it belongs. Table comments describe the business purpose of the table (e.g., storing basic order data for an e-commerce platform). Field information includes at least the field name, field type, field length, field comments, whether it is a primary key, whether it is nullable, and default value. For example, the "order_id" field is of type VARCHAR, length 64, is a primary key, and is not nullable; the "order_amount" field is of type DECIMAL, length 10, 2, and default value 0.00. Constraint information includes at least primary key constraints, foreign key constraints, unique constraints, and check constraints. Primary key constraints specify the unique identifier of the table (e.g., "order_id"); foreign key constraints define relationships with other tables (e.g., "user_id" is related to "user_id" in the "user_info" table); check constraints restrict the range of field values ​​(e.g., "order_status" only allows three values: 0, 1, and 2, corresponding to pending payment, paid, and cancelled, respectively). The relationship record records the relationship type (one-to-one, one-to-many, many-to-many) between the target table and other tables, as well as the related fields. For example, the "order table" and the "order_item table" have a one-to-many relationship, and the related field is "order_id".

[0063] Regarding the acquisition of metadata, the backend device executes the database native metadata query statement (such as MySQL's "SHOWFULLCOLUMNSFROM table_name") through the established database connection to automatically extract basic table information, field information, constraint information, and relationships. After the raw metadata is acquired, it needs to be standardized, that is, for field types, the different types of different databases are mapped to a unified standard type (such as MySQL's INT and Oracle's NUMBER(10) are uniformly mapped to INTEGER). For constraint information, a standardized naming rule is adopted (such as naming the primary key constraint "PK_table_name").

[0064] Step 120: Obtain the data management rules set for the target management table.

[0065] After the backend device obtains the structured metadata of the target management table, it retrieves the data management rules set for the target management table. This application supports two methods for obtaining data management rules: manual configuration via the interface and importing rule files. In the manual configuration scenario, the backend device dynamically generates a rule configuration form based on the structured metadata of the target management table, with each form field corresponding to a specific dimension of the data management rule. For example, for the "Order Table," the form loads all field names from the "Order Table" as optional parameters for the rule configuration. In the rule file import scenario, users can upload rule configuration files in XML or JSON format.

[0066] Data management rules must at least include the types of data operations to be executed, and can be expanded to include operation field ranges, data filtering conditions, operation permission control, execution log configuration, etc. The types of data operations to be executed include, but are not limited to, query, add, modify, and delete. When selecting an operation type, the backend device performs validity checks based on the structured metadata of the target management table. For example, for the "Historical Order Archive Table" (marked "Query Only" in the structured metadata), the backend device hides the add, modify, and delete operation type options by default, only retaining the query operation type. The operation field range is used to specify the target table fields involved in the current operation type. For example, when selecting the "Query" operation type, fields such as "order_id," "order_amount," and "order_status" from the "Order Table" can be selected as query return fields. Data filtering conditions are used to define row-level constraints for operation execution, supporting the generation of conditional expressions through combinations of field value ranges and logical operators. For example, for the "Query" operation type, the filtering condition can be set to "order_status=1 AND create_time>='2024-01-01'". Operation access control is used to associate user roles with operation permissions. For example, only the "Administrator" role can select the delete operation type. Execution log configuration is used to set the log content after an operation is executed, including whether to record the operator, operation time, and data snapshots before and after the operation. For example, for the modification operation type, you can configure it to record the "operator ID", "operation time", and "order_status value before modification" for easy traceability of subsequent operations.

[0067] Step 130: Based on structured metadata, data management rules, and the syntax rules of the target business database, generate SQL statements corresponding to the data operation types.

[0068] The backend device of this application stores a database syntax mapping table. This mapping table records the differences in syntax rules between different types of business databases, including at least keyword case sensitivity, function syntax, field reference formats, and parameter placeholder types. For example, for MySQL databases, the mapping table records that its keywords (such as SELECT, FROM, WHERE) are case-insensitive, string concatenation uses the CONCAT function, field references are enclosed in backticks (`), and parameter placeholders use "?". The database syntax mapping table also contains syntax rules specific to each database, such as MySQL's LIMIT pagination syntax.

[0069] After obtaining the structured metadata and data management rules based on steps 110-120, SQL statements are generated for data operations of the query type. This process first extracts key parameters from the structured metadata and data management rules, and then generates statements in conjunction with the database syntax mapping table. Specifically, the table name and field information (field name, field type) of the target management table are obtained from the structured metadata, and the list of filter fields (such as "order_id", "order_amount", "order_status") and data processing constraints (such as filter condition "order_status=1", sorting condition "create_timeDESC", pagination condition "10 records per page") corresponding to the query operation are obtained from the data management rules. Subsequently, the SQL statement is assembled according to the syntax rules of the target business database in the database syntax mapping table. If the target database is MySQL, the list of filter fields should be enclosed in backticks (e.g., order_id). The filter conditions in the data processing constraints should directly reference the expressions in the rules. The pagination syntax should use "LIMIT 0,10". An example of the generated SQL statement would be "SELECT order_id,order_amount,order_status FROM order_info WHERE order_status=1 OR DERBY create_time DESCLIMIT 0,10". During the generation process, the backend device will verify the consistency between the list of filter fields and the structured metadata. If a filter field specified in the rule (e.g., "invalid_field") does not exist in the structured metadata, the field will be automatically removed and a warning log will be generated to ensure the accuracy of field references.

[0070] Generate SQL statements for data operations involving newly added data types. Extract the table name and field information (including auto-incrementing primary key field identifiers, such as "order_id" marked as an auto-incrementing primary key) from the structured metadata. Obtain the list of fields to be inserted (such as "order_amount", "order_status", and "create_time") from the data management rules. When generating statements using the database syntax mapping table, differentiate the processing logic for auto-incrementing primary key fields. If the target database is MySQL, the auto-incrementing primary key field (order_id) does not need to be specified in the INSERT statement; an example of the generated SQL statement would be "INSERT INTO order_info(order_amount,order_status,create_time)VALUES(?,?,?)".

[0071] Generate SQL statements for data modification operations. Obtain the target table's name, primary key field information (e.g., "order_id" is the primary key), and field type constraints from structured metadata. Obtain the fields to be modified (e.g., "order_status", "remark") and primary key locating conditions (e.g., "order_id = ?") from data management rules. When generating the statement using the database syntax mapping table, ensure the accuracy of the primary key locating conditions and the validity of the fields to be modified. If the target database is MySQL, an example of the generated SQL statement would be "UPDATE order_info SET order_status = ?,remark = ? WHERE order_id = ?".

[0072] For data deletion operations, SQL statements are generated. The table name and primary key field information of the target management table are obtained from structured metadata, and the primary key locating condition (such as "order_id IN (?,?)") is obtained from data management rules. When generating the statement using the database syntax mapping table, the locating condition is ensured to be accurate and syntactically correct. If the target database is MySQL, the generated SQL statement example is "DELETE FROM order_info WHERE order_id IN (?,?)". During the generation process, if no primary key locating condition is specified in the data management rules, the backend device will automatically generate a default locating condition of "WHERE primary key field ISNOT NULL" based on the primary key field of the structured metadata, avoiding full table deletion due to lack of locating conditions.

[0073] In addition, after all types of SQL statements are generated, the backend device performs syntax verification. By calling the syntax checking rules in the database syntax mapping table, it verifies whether the use of keywords, matching of brackets, and parameter placeholder format in the statement meet the requirements of the target database. After the verification is passed, the SQL statement is associated with the data management rules and stored, and then called when performing data operations later.

[0074] In one implementation, to achieve fine-grained access control and avoid the risk of exceeding permissions, the following data access scope control step is added after generating the SQL statement and before executing it. The backend device obtains the identity identifier (such as user ID or account) of the current user through an authentication interface and retrieves the associated permission configuration information from the permission configuration center based on this identifier. This permission configuration information is pre-set by the administrator through a visual configuration interface and includes the user's organization (such as sales department or finance department), position (such as ordinary employee or department manager), and corresponding rules for the scope of accessible data. For example, "sales department employees can only access order data in their assigned region" or "department managers can access customer data of all employees in their department." The permission configuration information is stored in an encrypted permission database in the form of "user ID-permission rule" key-value pairs to ensure data security. Subsequently, the backend device automatically matches the obtained rules for the scope of accessible data with the field attributes in the structured metadata to determine the data permission filtering fields and the corresponding set of legal values. The structured metadata has pre-marked fields with data isolation attributes (such as region code, department ID, user affiliation identifier, etc.). For example, if the target management table is the "Orders Table," and the permission rule is "Only access data within the user's region," then the "Region Code" field in the structured metadata is matched as the permission filter field. Simultaneously, a set of valid region codes (e.g., "East China 001, South China 002") is extracted based on the user's organization. If the permission rule is "Only access data created by the user," then the "Creator ID" field is matched as the permission filter field, and the set of valid values ​​represents the current user's identity. Next, the backend device, based on the operation type of the target SQL statement (query, insert, update, delete), embeds the conditional statement containing the permission filter field and the set of valid values ​​into the query conditions or filtering logic of the SQL statement. For query-type SQL statements, the condition "AND permission filter field IN (set of valid values)" is appended after the WHERE clause. For example, the original query SQL is "SELECT order_id, order_amount FROM order_info WHERE order_status=1". After embedding permission conditions, it becomes "SELECT order_id, order_amount FROM order_info WHERE order_status=1 AND region_code IN('001','002')". For SQL statements with new types, add the valid values ​​of the permission filtering fields to the INSERT statement. For example, "INSERT INTO customer(name,dept_id)VALUES(?,'003')", where "dept_id='003'" is the matching permission constraint.For SQL statements involving modification and deletion, permission filtering conditions are also added to the WHERE clause to ensure that only data within the authorized scope can be accessed. Finally, when executing a target SQL statement with access control, the backend device synchronously triggers a secondary permission check to verify whether the permission conditions embedded in the SQL statement are consistent with the user's permission configuration information, preventing unauthorized tampering. If the user's operation request involves data beyond their permissions (such as a sales department employee attempting to access data in the North China region), the SQL statement returns an empty result set after execution. Simultaneously, the backend device triggers a permission check exception, generating an exception log containing the exception type (exceeding permission access), user ID, operation time, and target table name. The frontend device then sends a message to the user stating "No permission to access this range of data; please contact the administrator to grant permission," ensuring a closed loop of permission control.

[0075] Step 140: Based on structured metadata and data management rules, adapt the content and bind the logic to the preset interface template to generate static interface resources. The static interface resources are used to generate the data management interface after being loaded by the front-end device.

[0076] The basic interface template includes a blank HTML file, a basic CSS file, and a JS file for the initial interaction framework. The HTML file provides placeholder containers for the data query area, data display area, and interactive area. The CSS file contains general style classes (such as font, margin, and basic button styles). The JS file contains basic request sending functions and basic interface rendering methods. The template package also supports differentiation based on business scenarios (such as list query scenario templates and form editing scenario templates). The backend device automatically matches the corresponding template based on the type of data operation to be performed in the data management rules. For example, query and modification operations are matched with a combined list query and form editing template.

[0077] First, extract the field identifiers and data types of the target management table from the structured metadata. The field identifiers directly use the field names recorded in the structured metadata (e.g., order_id). The field data types are mapped to the front-end control types according to the interface display requirements. For example, if the order_id field in the structured metadata is of type VARCHAR and is the primary key, it is mapped to the front-end "text display control". When extracting field display rules, data operation types to be executed, and interface style requirements from the data management rules, the field display rules include the field's display name (e.g., "order_id" corresponds to the display name "order ID"), whether to display (e.g., the "delete_time" field is configured to be hidden according to the rules), and display width (e.g., "order_amount" is configured to have a display width of 120px). The interface style requirements include table styles (e.g., with borders, alternating row colors), button layouts (e.g., top button group, inline operation buttons), etc.

[0078] Secondly, labels are populated according to the functional positioning of the three main areas: data query, data display, and operation interaction. For the data query area, labels are generated based on the filter fields corresponding to the query operation. For example, for the "order_status" field, labels are generated including a text label containing "Order Status:", a dropdown selection control label with options 0 - Pending Payment, 1 - Paid, 2 - Cancelled, and a query button label. The "name" attribute of the control label will be consistent with the field identifier. The data display area generates table labels according to the field display rules. The table header label corresponds to the field display name (e.g., order ID), and the table content labels are associated with the field identifier through dynamic rendering syntax. The operation interaction area generates button labels based on the data operation type: a query button is generated for query operations, an add button for add operations, and edit / delete buttons are generated within the table rows for modify or delete operations.

[0079] After completing the HTML file tag structure, add style rules in the CSS file corresponding to each area tag according to the interface style requirements, ensuring that the styles match the tag structure. For the data query area, if the requirement is for horizontally arranged query conditions, add flexible layout, spacing, and alignment styles to the area container tag, and set a fixed width for the filter control tag. For the data display area, if the requirement is for a table with borders and alternating row colors, add border merging and 100% width styles to the table tag, set borders and padding for the table cell tags, and set a specific background color for the odd-numbered row tags. For the interactive area, if the button theme color is required to be #1890FF, add corresponding background color, text color, no border, and padding styles to the button tags, and set the transparency for the button hover state. All CSS style rules use class selectors or ID selectors to precisely associate with the HTML tags; for example, use ID selectors for buttons in the data query area and class selectors for in-row table operation buttons to avoid style conflicts.

[0080] Finally, configure the association logic and request processing logic in the JS file according to the type of data operation to be performed. In the association logic configuration, bind each operation button in the data management interface to the corresponding request interface of the backend device. For example, when the query button is clicked, retrieve the input values ​​of each filter control in the data query area, call the preset sendRequest function to send a GET request to the backend interface " / api / data / query", with the interface parameters including the target table name and filter conditions. When the add button is clicked, a pop-up add form window appears; when the form is submitted, the sendRequest function is called to send a POST request to the backend interface " / api / data / insert". When the edit button is clicked, retrieve the data to be modified based on the primary key value of the current row and populate the form; when submitted, a PUT request is sent. When the delete button is clicked, a confirmation pop-up appears; after confirmation, a DELETE request is sent.

[0081] After static interface resources are generated, the backend device performs integrity checks on the HTML, CSS, and JS files. This checks whether HTML tags correspond one-to-one with field identifiers, whether CSS style rules cover all area tags, and whether the JS logic includes bindings for all pending operation types. Once the checks pass, the three types of files are packaged into a static resource package and provided to the frontend device for loading via an HTTP interface. After loading, the frontend device uses the HTML files to build the interface structure, the CSS files to render the interface styles, and the JS files to implement interactive functions, ultimately generating a data management interface that includes data query, data display, and interactive operation functions.

[0082] Step 150: Receive the operation request initiated by the front-end device based on the data management interface, execute the corresponding data operation in the target business database based on the SQL statement corresponding to the operation request, and feed back the operation result to the front-end device so that the front-end device can display the operation result in the data management interface.

[0083] After the front-end device initiates an operation request based on the data management interface, the back-end device receives the operation request through a preset request receiving interface and extracts the SQL statement that matches the current operation request from the stored relationships. For example, for a modification request to the "order_info" table (order_id = 123456), the previously generated statement "UPDATE order_infoSET order_status = ?,remark = ?WHERE order_id = ?" is extracted.

[0084] After data operations are completed, the backend devices organize the results according to the operation type, forming a standardized result data structure. The query operation result includes the total number of data rows, the current page data list, and pagination information. The total number of data rows is used by the frontend to calculate the total number of pages (e.g., if the total number of rows is 100 and the page size is 10, then the total number of pages is 10). The current page data list is structured data (field names and values ​​correspond one-to-one, such as [{order_id:'123456',order_amount:99.9,order_status:1,create_time:'2024-05-20 14:30:00'},...]). Pagination information includes the current page number and page size. The result of the add operation includes the number of rows affected by the operation (e.g., "1" indicates successful insertion of 1 data row) and the primary key value of the added data (e.g., "order_id:'123456'"). The result of a modification operation includes the number of rows affected (e.g., "1" indicates one record was successfully modified) and a comparison of the field values ​​before and after the modification (e.g., "{order_status:{'old':0,'new':1}}"). The result of a deletion operation only includes the number of rows affected (e.g., "1" indicates one record was successfully deleted). All operation results must be converted to JSON format to ensure that the front-end device can parse them.

[0085] The backend device sends the operation result back to the frontend device through the original request's response chain. The response status code is set according to the HTTP standard (e.g., 200 for success, 400 for incorrect request parameters, 403 for insufficient permissions, and 500 for an internal server error). The response body includes a result code (0 for success, non-zero for failure), a result description (e.g., operation successful, incorrect request parameters), and operation result data (query operations return paginated data, add / modify / delete operations return the number of rows affected, etc.). After receiving the response, the frontend device determines whether the operation was successful based on the result code in the response. If successful, the query operation calls the interface rendering function to populate the data list from the result data into the table in the data display area, and updates the pagination control to display the current page number and total number of pages; the add operation pops up a message "Add successful, new order ID: 123456" and refreshes the table data to display the new record; the modify operation pops up a message "Modification successful, affecting 1 record" and updates the current row of table data to the modified value; the delete operation pops up a message "Delete successful, affecting 1 record" and removes the corresponding row data from the table.

[0086] In addition, the backend device records the execution log of each operation. The log content includes the operation time, operator, operation type, target table name, executed SQL statement, operation parameters, operation result (success / failure), number of rows affected, etc., for data operation traceability and fault diagnosis.

[0087] In addition, during the process of the front-end device initiating an operation request based on the generated static interface resources, and the back-end device receiving the request and executing the corresponding SQL statement, in order to avoid inconsistencies in the data in the target business database due to SQL execution exceptions (such as some statements succeeding and some failing) (e.g., the order table is successfully modified but the associated payment table fails to be modified), it is necessary to uniformly control the execution process of the associated SQL statements through database transactions.

[0088] Specifically, transaction initialization parameters include transaction isolation level (supports READ UNCOMMITTED, READCOMMITTED, REPEATABLE READ, SERIALIZABLE), transaction timeout (unit: seconds), transaction propagation behavior (supports REQUIRED, REQUIRES_NEW, SUPPORTS), and table locking strategy (row locks, table locks). Data operation types are divided into three categories: insert, update, and delete (query operations do not require transaction control). Target table field attributes are divided into categories including: fields with auto-incrementing primary keys and no foreign keys, fields with non-auto-incrementing primary keys and a single foreign key, fields with composite primary keys and multiple foreign keys, and high-frequency access fields (the criteria for determining high-frequency access fields are: the field's call frequency in query / update operations within the past 7 days is ≥ 30% of the average daily total operation frequency, or the field is a business status identifier (such as order status, payment status)). When matching transaction initialization parameters, the backend device first reads the data operation type to be executed from the data management rules, extracts the field attributes of the target management table from the "Field Information Table" and "Relationship Table" of the structured metadata (e.g., the operation type of the "Order Table" is modification, and the field attributes are "containing auto-incrementing primary key + single foreign key (related to user table user_id)" and "high-frequency access field order_status"), and then matches the corresponding template in the transaction configuration template library. If the combination is "Modify - includes auto-incrementing primary key + single foreign key + frequently accessed field", the matching transaction initialization parameters are "Isolation level REPEATABLEREAD, timeout 60 seconds, propagation behavior REQUIRED, table locking strategy row lock"; if the combination is "Add - includes auto-incrementing primary key + no foreign key", the matching parameters are "Isolation level READCOMMITTED, timeout 30 seconds, propagation behavior REQUIRED, table locking strategy row lock"; if the combination is "Delete - includes composite primary key + multiple foreign keys", the matching parameters are "Isolation level SERIALIZABLE, timeout 90 seconds, propagation behavior REQUIRES_NEW, table locking strategy table lock". After matching is completed, the backend device calls the transaction control API of the target business database through the JDBC interface, passes in the above parameters to start a database transaction, the database assigns a unique identifier to the transaction, and locks the data rows of the target management table and related tables involved in the transaction. At this time, all related SQL statements initiated by the backend device against the target management table (such as SQL that modifies the order log table after modifying the order table) are included in the transaction, forming an indivisible operation unit. Before the commit, all operation results are only visible within the transaction and do not affect other concurrent transactions.

[0089] After the backend device executes the SQL statement, it obtains the number of affected rows returned by the database (e.g., "3" is returned after executing the insert statement, which means that 3 records have been modified). The number of affected rows is the number of records in the target management table that have actually undergone data changes.

[0090] When performing validation based on the preset impact row count standard in the data management rules, it is executed in three steps: basic validation, dynamic validation, and correlation validation. In the basic validation stage, the threshold range for the current operation type and the target table is read from the "Operation Constraint Configuration" of the data management rules. For example, "Batch deletion threshold range for order table is 5-100 rows" and "Modification threshold range for user form is 1-1 rows". If the number of rows affected by the operation is 3 (below the lower limit of 5) or 105 (above the upper limit of 100), the basic validation will fail. During the dynamic verification phase, the historical number of rows affected by operations in the target management table within a preset time range (e.g., the last 7 days) is first extracted from the operation log (e.g., 40, 50, 45, 35, 30, 25, 20 for each day). Then, a weighted average is calculated based on the time decay factor (0.8 for 1 day ago, 0.5 for 2-3 days ago, and 0.2 for 4-7 days ago): (40×0.8+50×0.8+45×0.5+35×0.5+30×0.2+25×0.2+20×0.2)=127, with an average value ≈18.14. The dynamic fluctuation threshold is set to 1.5 times the average value (≈27.21). If the number of rows affected by the current operation is 30 (greater than 27.21), the dynamic verification fails. During the association verification phase, the associated tables (i.e., tables that have business relationships or data dependencies with the target management table, such as the order detail table and payment table associated with the order table) are first identified from the association relationship table of the structured metadata. The number of rows affected by the synchronization operation in the associated tables is obtained by executing the association query SQL (e.g., "SELECT COUNT(*) FROM order_item WHERE order_id IN (list of deleted order IDs)"). Then, the preset business association ratio rules are read from the data management rules (e.g., "delete 1 row in the order table, delete at least 1 row in the order detail table" and "the amount modified in the order table and the amount modified in the payment table must be modified synchronously, with a ratio of 1:1"). If the number of rows affected in the target table is 10 and the number of rows affected by the synchronization in the associated table is 8, which does not meet the ratio rule of "1:≥1", then the association verification fails.

[0091] For operations involving business logic relationships (such as order status modification, inventory deduction, etc.), business logic validation is performed based on the table relationships in structured metadata. The backend device first extracts the relationship type (one-to-one, one-to-many) and related fields (e.g., order_id in the order table related to payment_id) from the relationship table. Then, it generates a related query SQL based on the preset business logic expression in the data management rules (e.g., "When the order status is changed to paid, the payment status of the corresponding record in the payment table must be paid and the amount must be equal"). For example, "SELECT pay_status, pay_amount FROM pay_info WHERE order_id='123456'". After executing the query, it validates whether the returned target field data in the related table conforms to the logic. If the payment status is 0 (pending payment) or the payment amount is not equal to the order_amount in the order table (e.g., order amount 99.9, payment amount 100), the business logic validation fails. If it is an inventory deduction operation, the associated table is the product inventory table, and the business logic rule is "inventory after deduction ≥ 0". If the corresponding record in the product inventory table is found to have stock_num = 5, the deduction quantity is 10, and the calculated inventory = -5, then the validation will fail.

[0092] The backend device monitors the runtime of database transactions in real time. If the timeout specified in the transaction initialization parameters (e.g., 60 seconds) has not been reached, and the basic, dynamic, and relational validations of the rows affected by the operation all pass, along with the business logic validation, the database transaction commit API is called. This permanently writes the execution results of all related SQL statements within the transaction to disk, releases data row locks, and completes data persistence. If any validation fails, or the transaction runtime exceeds the timeout, a rollback operation is triggered. This undoes the execution results of all SQL statements within the transaction, restores the target management table and related tables to their state before the transaction began, and releases all locked resources.

[0093] After completing data operation execution, result feedback and transaction control, in order to further optimize data query efficiency and reduce access pressure on the target business database, a differentiated caching strategy is formulated based on the actual query and update characteristics of the target management table.

[0094] Specifically, when collecting historical query frequency data for SQL statements targeting the management table, the backend device extracts all execution records of SQL statements targeting that table within the past 30 days from the operation logs, and counts the execution frequency based on the unique identifier of the SQL statement. To accurately distinguish the resource consumption levels of different queries and the adaptation requirements of caching strategies, a high-frequency, medium-frequency, and low-frequency determination scheme is established by combining three dimensions: "average daily query count, peak query period, and query result data volume." All three must simultaneously meet the corresponding threshold conditions. In some embodiments, the criteria for determining high-frequency, medium-frequency, and low-frequency queries are as follows: High-frequency queries must meet the following conditions: an average daily number of queries over the past 30 days ≥ 30 times, and the number of executions during the peak query period (the hour with the highest daily access volume) ≥ 20% of the total number of executions on that day, with a single query result data volume ≤ 500 records (to avoid misjudging high-frequency queries with large result sets); Medium-frequency queries must meet the following conditions: an average daily number of queries over the past 30 days ≥ 10 times and < 30 times, and the number of executions during the peak query period ≥ 10% and < 20% of the total number of executions on that day, with a single query result data volume ≤ 1000 records; Low-frequency queries are defined as: an average daily number of queries over the past 30 days < 10 times, or the number of executions during the peak query period < 10% of the total number of executions on that day, or a single query result data volume > 1000 records (even if the number of executions for large result set queries meets the criteria, they are still classified as low-frequency to adapt to differentiated caching). For example, a query SQL statement is executed an average of 50 times per day over the past 30 days, with the peak execution time being 10:00-11:00 AM, accounting for 25% of the total daily executions. Each query returns an average of 300 rows of data, meeting the three-dimensional thresholds for high-frequency queries and is therefore marked as a "high-frequency query." Another query SQL statement is executed an average of 15 times per day over the past 30 days, with the peak execution time accounting for 12% of the total daily executions. Each query returns an average of 800 rows of data, meeting the three-dimensional requirements for medium-frequency queries and is therefore marked as a "medium-frequency query." A third query SQL statement is executed an average of 8 times per day over the past 30 days. Even though the peak execution time accounts for 15% of the total daily executions, each query returns 1200 rows of data and is still marked as a "low-frequency query."

[0095] When collecting update frequency characteristics of the target management table data, the update frequency and scope are statistically analyzed based on the add, modify, and delete operation records for the table in the operation log over the past 30 days. Statistical dimensions include the daily average number of updates (the sum of add, modify, and delete operations), the range of updated fields, and the number of rows affected by the update. For example, if the target management table has an average of 5 updates per day in the past 30 days, with each update involving only the "order_status" and "remark" fields, and each update affecting 1-5 records, it is marked as a "low-frequency update." If the daily average number of updates is 30, involving multiple fields such as "order_amount" and "order_status," and each update affecting 10-20 records, it is marked as a "medium-frequency update." If the daily average number of updates is 100, involving all fields in the table, and each update affecting more than 50 records, it is marked as a "high-frequency update."

[0096] After collecting query frequency and update frequency data, a 3×3 matrix structure is formed with "historical query frequency" as the row dimension and "table data update frequency characteristics" as the column dimension. The matrix row dimension is divided into three levels: "high-frequency query (daily average queries ≥ 30 times)," "medium-frequency query (daily average queries 5-29 times)," and "low-frequency query (daily average queries < 5 times)." The column dimension is divided into three levels: "low-frequency update (daily average updates < 10 times)," "medium-frequency update (daily average updates 10-50 times)," and "high-frequency update (daily average updates > 50 times)." The historical query frequency level of each query SQL statement is mapped to the update frequency level of the corresponding target table to the matrix cells. For example, a high-frequency query SQL statement with low-frequency table data updates corresponds to the "high-frequency query - low-frequency update" cell, a medium-frequency query SQL statement with medium-frequency table data updates corresponds to the "medium-frequency query - medium-frequency update" cell, and a low-frequency query SQL statement or a table data update high-frequency cell corresponds to the "low-frequency query - any update" or "any query - high-frequency update" cell.

[0097] Furthermore, when classifying the first cache level based on the query update frequency matrix, the query results corresponding to all query-type SQL statements in the cells of high-frequency queries and low-frequency updates in the matrix are classified as the first cache level. After classification, the backend device stores the query results of this type completely in the memory cache. The memory cache is implemented using Redis or a local in-memory database, and the storage structure is a "cache key-cache value" key-value pair. The cache key is a unique identifier for the SQL statement, and the cache value is the complete query result dataset (including the field names and values ​​of all returned fields). A cache expiration time is also set. If the table data is updated in batches on a regular schedule, the cache expiration time is set to 10 minutes before the next batch update time (e.g., if the update is at 3:00 AM daily, the cache expiration time is until 2:50 AM the next day). If the table data is updated randomly and infrequently, the cache expiration time is set to 2 hours. Within the expiration time, if there is a query request for the same SQL statement, the result is returned directly from the memory cache without executing an SQL query to the database.

[0098] The query results within the mid-frequency query and mid-frequency update cells in the matrix are classified into the second caching level. Only core fields from the query results are retained during storage; core fields refer to identifying fields and frequently accessed fields. Non-core fields are not stored. The storage location is the general storage area of ​​the backend device, implemented using a disk database (such as a MySQL cache table). The storage structure includes a "cache key - core field value list," where the cache key is also a unique identifier for the SQL statement, and the core field value list contains only key-value pairs of core fields. The cache validity period is set to 30 minutes, and an update-triggered invalidation mechanism is enabled. When an update operation occurs on the target management table and the updated field contains a core field, the corresponding cached entry for the SQL statement is immediately deleted to prevent inconsistencies between cached and database data. If the updated field does not contain a core field, cache invalidation is not triggered, and cached data can continue to be used.

[0099] The query results in cells of the matrix that are queried infrequently and updated arbitrarily, or queried infrequently and updated arbitrarily, are classified into the third caching level. These query results are not cached. Each time the backend device receives a corresponding query request, it re-executes the SQL statement to access the target business database to obtain the latest results. This avoids resource waste caused by frequent cache expiration (e.g., in high-frequency update scenarios, the cache becomes invalid immediately after storage due to updates, failing to fulfill its caching function) or a mismatch between cache resource consumption and query efficiency improvement in low-frequency query scenarios (e.g., low-frequency queries are cached but not accessed for a long time, consuming storage resources).

[0100] In summary, this application provides foundational data support for automation by acquiring the connection configuration information of the target business database and the structured metadata of the target management table. The connection configuration information can be directly used to establish the interaction link between the backend device and the target business database, clarifying the key parameters required for database communication and ensuring that the backend can accurately connect to the target database. The structured metadata fully presents the structural characteristics of the target management table, providing a table structure basis for subsequent SQL statement generation and interface adaptation. The application also acquires the data management rules set for the target management table; these rules at least include the types of data operations to be performed, directly defining the functional requirements of data management.

[0101] Based on structured metadata, data management rules, and the syntax rules of the target business database, SQL statements for corresponding data operation types are automatically generated. Structured metadata provides the basic elements of the table structure, determining the components of the SQL statement; data management rules define the operation types, determining the functional type of the SQL statement; and the syntax rules of the target business database ensure that the generated SQL statement conforms to the database syntax specification. The combination of these three elements enables the automatic generation of SQL statements, allowing data operation instructions to be directly adapted to the target database and business requirements.

[0102] Based on structured metadata and data management rules, the preset interface template is adapted and logically bound. When generating static interface resources, the structured metadata supports the construction of interface query controls and display labels, while the operation types in the data management rules support the binding logic between interface operation buttons and backend request interfaces. After the generated static interface resources are loaded by the front-end device, they can directly form a data management interface that matches the backend data operations, realizing the automatic connection between the front-end interface and the backend logic.

[0103] Finally, when the front-end device initiates an operation request based on the data management interface, the back-end device receives the request, directly calls the corresponding automatically generated SQL statement, executes the data operation in the target business database, and then feeds back the operation result to the front-end device. This step relies on the previously established interaction link and the automatically generated SQL statement to achieve a complete closed loop from front-end request to back-end execution and result feedback.

[0104] It is understood that, in order to achieve the functions in the above embodiments, the computer device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0105] Furthermore, as a response to the above Figure 1 The implementation of the method embodiment shown in this application provides a data management device. The embodiment of this device corresponds to the foregoing method embodiments. For ease of reading, this embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the device in this embodiment can correspondingly implement all the contents of the foregoing method embodiments. Specifically, as shown... Figure 3 As shown, the data management device 300 includes:

[0106] The first acquisition module 310 is used to acquire the connection configuration information of the target business database and the structured metadata of the target management table. The connection configuration information is used to establish the interaction link between the backend device and the target business database.

[0107] The second acquisition module 320 is used to acquire the data management rules set for the target management table. The data management rules include at least the types of data operations to be performed.

[0108] The first generation module 330 is used to generate SQL statements corresponding to the data operation type based on structured metadata, data management rules and the syntax rules of the target business database.

[0109] The second generation module 340 is used to adapt and logically bind the preset interface template based on structured metadata and data management rules to generate static interface resources. The static interface resources are used to generate the data management interface after being loaded by the front-end device.

[0110] The execution module 350 is used to receive operation requests initiated by the front-end device based on the data management interface, execute corresponding data operations in the target business database based on the SQL statement corresponding to the operation request, and feed back the operation results to the front-end device so that the front-end device can display the operation results in the data management interface.

[0111] Furthermore, such as Figure 3 As shown, the backend device has a built-in database syntax mapping table, which is used to indicate the syntax rules of different types of business databases. The first generation module 330 is specifically used to determine the structural elements of the SQL statement based on the data operation type, establish the mapping relationship between the structural elements and the SQL syntax components according to the syntax rules of the target business database, and fill the structural elements into the SQL basic framework of the corresponding data operation type based on the mapping relationship to generate an SQL statement that conforms to the syntax specification of the target business database.

[0112] Furthermore, such as Figure 3As shown, the first generation module 330 is specifically used for data operations of the query type. Based on structured metadata, it determines the list of filter fields, table name, and data processing constraints of the target management table. According to the syntax rules of the target business database in the database syntax mapping table, it generates an SQL statement containing the list of filter fields, the table name of the target management table, and data processing constraints, conforming to the syntax rules of the target business database. For data operations of the insertion type, based on structured metadata, it determines the table name, the list of fields to be inserted, and the auto-incrementing primary key field identifier of the target management table. According to the syntax rules of the target business database in the database syntax mapping table, it generates an SQL statement containing the table name of the target management table, the list of fields to be inserted, and parameter placeholders, conforming to the syntax rules of the target business database. The SQL statement is generated as follows: For modification-type data operations, the table name, fields to be modified, and primary key fields of the target management table are determined based on structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that includes the table name of the target management table, fields to be modified, parameter placeholders, and primary key locating conditions based on the primary key fields, while conforming to the syntax rules of the target business database. For deletion-type data operations, the table name and primary key fields of the target management table are determined based on structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that includes the table name of the target management table, primary key locating conditions based on the primary key fields, and conforms to the syntax rules of the target business database.

[0113] Furthermore, such as Figure 3 As shown, the second generation module 340 is specifically used to extract field identifiers and field data types from the structured metadata of the target management table, and to extract field display rules, data operation types to be executed, and interface style requirements from the data management rules. Based on the extracted field identifiers, field data types, and field display rules, it constructs data query area labels, data display area labels, and operation interaction area labels in the HTML file of the interface base template. Based on the interface style requirements, it adds style rules in the CSS file of the interface base template that correspond one-to-one with each area label in the HTML file. Based on the data operation types to be executed, it configures association logic and request processing logic in the JS file of the interface base template. The association logic is used to bind the operation buttons in the data management interface corresponding to each data operation type to the request interface of the backend device that matches the corresponding data operation type. The request processing logic is used to enable the frontend device to establish interaction with the backend device when it initiates an operation request based on the data management interface.

[0114] Furthermore, such as Figure 3As shown, the first acquisition module 310 is specifically used to determine the type of the target business database based on the database type identifier in the connection configuration information; match the corresponding database driver from the integrated multi-type database drivers according to the type of the target business database, so as to realize communication with the target business database through the communication protocol supported by the database driver; and establish a network connection between the backend device and the target business database through the network address and access port in the connection configuration information, forming an interaction link between the backend device and the target business database.

[0115] Furthermore, such as Figure 3 As shown, the execution module 350 is also used to start a data operation verification mechanism. The data operation verification mechanism is used to verify the legality and consistency of the SQL statement execution process and execution result. If the data operation verification mechanism passes the verification, the SQL statement execution result is confirmed to be valid and the data is persisted. If the data operation verification mechanism fails the verification, the exception handling strategy is triggered to undo the impact of the executed SQL statement on the target business database.

[0116] Furthermore, such as Figure 3 As shown, the execution module 350 is specifically used to match the corresponding transaction initialization parameters from the preset transaction configuration template library according to the data operation type to be executed and the field attributes of the target management table in the structured metadata. Based on the transaction initialization parameters, a database transaction is started. The database transaction integrates all related SQL statements initiated by the backend device against the target management table in the target business database into an indivisible operation unit. When all SQL statements within the operation unit have been executed, passed verification, and have not timed out, the execution results of all SQL statements are permanently effective in the database. The module also obtains the number of rows affected by the operation after the backend device executes the SQL statement corresponding to the operation request. The number of affected rows indicates the number of records that actually change data in the target management table of the target business database. The number of affected rows is verified according to the preset standard for the number of affected rows in the data management rules. For operations involving business logic relationships, the target field data of the related tables in the target business database is queried based on the table relationships recorded in the structured metadata, and the target field data of the related tables is verified to meet the preset business logic. If both the number of affected rows and the business logic verification pass and the preset timeout mechanism of the database transaction is not triggered, the database transaction is committed so that the execution results of all related SQL statements are permanently written to the target business database; otherwise, the database transaction is rolled back.

[0117] Furthermore, such as Figure 3As shown, the execution module 350 is specifically used to perform basic verification on the number of rows affected by the operation based on the threshold range in the data management rules. When the number of rows affected by the operation exceeds the upper or lower limit of the threshold range, the basic verification is indicated as failing. It also performs dynamic verification on the number of rows affected by the operation based on a dynamic fluctuation threshold. When the number of rows affected by the operation is greater than the dynamic fluctuation threshold, the dynamic threshold verification is indicated as failing. The dynamic fluctuation threshold is a threshold obtained by weighting the historical number of rows affected by the operation in the target management table within a preset time range using a time decay factor. The module also obtains the number of rows affected by the synchronous operation in the associated table and establishes a mapping relationship between the number of rows affected by the operation and the number of rows affected by the synchronous operation. When the mapping relationship does not conform to the preset business association ratio rules, the association verification is indicated as failing. The associated table is the management table that has a business association or data dependency relationship with the target management table when the backend device executes the SQL statement corresponding to the operation request on the target management table in the target business database.

[0118] Furthermore, such as Figure 3 As shown, the execution module 350 is further configured to construct a query update frequency matrix based on the historical query frequency data of SQL statements querying the target management table and the update frequency characteristics of the table data; according to the query update frequency matrix, the query results of high-frequency queries and low-frequency updates are classified into the first cache level, and the query results of the first cache level are completely stored in the memory cache area of ​​the backend device; according to the query update frequency matrix, the query results of medium-frequency queries and medium-frequency updates are classified into the second cache level, and the target fields in the query results of the second cache level are stored in the ordinary storage area of ​​the backend device; according to the query update frequency matrix, the query results of low-frequency queries or high-frequency updates are classified into the third cache level, and the query results of the third cache level are not cached.

[0119] Optionally, the data management device may be an electronic device with data processing capabilities, or a functional module within the electronic device, without limitation.

[0120] For example, the electronic device can be a server, which can be a single server or a server cluster consisting of multiple servers. As another example, the electronic device can be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, and other terminal devices. As yet another example, the electronic device can also be a recording device, video surveillance equipment, etc. This application does not impose any special limitations on the specific form of the electronic device.

[0121] The following example uses an electronic device as the data management device. Figure 4 As shown, Figure 4 The hardware structure of an electronic device 400 provided in this application.

[0122] like Figure 4 As shown, the electronic device 400 includes a processor 410, a communication line 420, and a communication interface 430.

[0123] Optionally, the electronic device 400 may also include a memory 440. The processor 410, memory 440, and communication interface 430 can be connected via a communication line 420.

[0124] The processor 410 can be a central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 410 can also be any other device with processing capabilities, such as a circuit, device, or software module, without limitation.

[0125] In one example, processor 410 may include one or more CPUs, for example Figure 4 CPU0 and CPU1 in the CPU.

[0126] As an optional implementation, electronic device 400 may include multiple processors, for example, in addition to processor 410, it may also include processor 470. Communication line 420 is used to transmit information between the components included in electronic device 400.

[0127] Communication interface 430 is used for communicating with other devices or other communication networks. These other communication networks can be Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc. Communication interface 430 can be a module, circuit, transceiver, or any device capable of enabling communication.

[0128] Memory 440 is used to store instructions. These instructions can be computer programs.

[0129] The memory 440 can be a read-only memory (ROM) or other type of static storage device that can store static information and / or instructions; it can also be a random access memory (RAM) or other type of dynamic storage device that can store information and / or instructions; it can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, etc., without limitation.

[0130] It should be noted that the memory 440 can exist independently of the processor 410, or it can be integrated with the processor 410. The memory 440 can be used to store instructions, program code, or some data, etc. The memory 440 can be located inside or outside the electronic device 400, without restriction.

[0131] The processor 410 is configured to execute instructions stored in the memory 440 to implement the communication method provided in the following embodiments of this application. For example, when the electronic device 400 is a terminal or a chip in a terminal, the processor 410 can execute instructions stored in the memory 440 to implement the steps performed by the transmitting end in the following embodiments of this application.

[0132] As an optional implementation, the electronic device 400 also includes an output device 450 and an input device 460. The output device 450 can be a display screen, speaker, or other device capable of outputting data from the electronic device 400 to the user. The input device 460 can be a keyboard, mouse, microphone, joystick, or other device capable of inputting data into the electronic device 400.

[0133] It should be pointed out that, Figure 4 The structure shown does not constitute a limitation on the electronic device, except... Figure 4 In addition to the components shown, the electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0134] The data management device and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of data management devices and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0135] This application provides a storage medium on which a program is stored, which implements a data management method when executed by a processor.

[0136] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] In a typical configuration, the device includes one or more processors (CPUs), memory, and a bus. The device may also include input / output interfaces, network interfaces, etc.

[0138] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

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

[0140] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0141] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data management method, characterized in that, Applied to backend devices, the method includes: Obtain the connection configuration information of the target business database and the structured metadata of the target management table. The connection configuration information is used to establish the interaction link between the backend device and the target business database. Obtain the data management rules set for the target management table, wherein the data management rules include at least the data operation types to be performed; Based on the structured metadata, the data management rules, and the syntax rules of the target business database, generate SQL statements corresponding to the data operation type; Based on the structured metadata and the data management rules, the preset interface template is adapted and logically bound to generate static interface resources. The static interface resources are used to generate the data management interface after being loaded by the front-end device. The interactive functions of the data management interface correspond one-to-one with the SQL statements of the corresponding data operation types. The system receives an operation request initiated by the front-end device based on the data management interface, executes a corresponding data operation in the target business database based on the SQL statement corresponding to the operation request, and feeds back the operation result to the front-end device so that the front-end device can display the operation result in the data management interface.

2. The method according to claim 1, characterized in that, The backend device has a built-in database syntax mapping table, which indicates the syntax rules of different types of business databases. Based on the structured metadata, the data management rules, and the syntax rules of the target business database, it generates SQL statements corresponding to the data operation type, including: Based on the data operation type, determine the structural elements of the SQL statement, and establish a mapping relationship between the structural elements and the SQL syntax components according to the syntax rules of the target business database; Based on the mapping relationship, the structural elements are filled into the SQL basic framework of the corresponding data operation type to generate SQL statements that conform to the target business database syntax specifications.

3. The method according to claim 2, characterized in that, Based on the data operation type, the structural elements of the SQL statement are determined. According to the syntax rules of the target business database, a mapping relationship is established between the structural elements and SQL syntax components. Based on the mapping relationship, the structural elements are filled into the corresponding SQL basic framework for the data operation type, generating an SQL statement that conforms to the syntax specifications of the target business database, including: For data operations of the query type, the filter field list, table name and data processing constraints of the target management table are determined based on the structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement containing the filter field list, the table name of the target management table, the data processing constraints and conforming to the syntax rules of the target business database is generated. For data operations of newly added types, the table name, the list of fields to be inserted, and the auto-incrementing primary key field identifier of the target management table are determined based on the structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement containing the table name of the target management table, the list of fields to be inserted, and parameter placeholders and conforming to the syntax rules of the target business database is generated. For data operations involving modification, the table name, fields to be modified, and primary key field information of the target management table are determined based on the structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that contains the table name of the target management table, the fields to be modified, parameter placeholders, primary key location conditions based on the primary key field, and conforms to the syntax rules of the target business database. For data operations involving deletion, the table name and primary key field information of the target management table are determined based on the structured metadata. According to the syntax rules of the target business database in the database syntax mapping table, an SQL statement is generated that includes the table name of the target management table, primary key location conditions based on the primary key field, and conforms to the syntax rules of the target business database.

4. The method according to any one of claims 1-3, characterized in that, Based on the structured metadata and the data management rules, content adaptation and logical binding are performed on the preset interface template to generate static interface resources, including: Extract the field identifiers and field data types of the target management table from the structured metadata, and extract the field display rules, data operation types to be executed, and interface style requirements from the data management rules; Based on the extracted field identifiers, field data types, and field display rules, data query area labels, data display area labels, and operation interaction area labels are constructed in the HTML file of the interface base template. Based on the interface style requirements, add style rules to the CSS file of the basic interface template that correspond one-to-one with the tags of each area in the HTML file. According to the data operation type to be executed, the association logic and request processing logic are configured in the JS file of the interface base template. The association logic is used to bind the operation buttons in the data management interface corresponding to each data operation type to the request interface of the backend device that matches the corresponding data operation type. The request processing logic is used to enable the frontend device to establish interaction with the backend device when the frontend device initiates an operation request based on the data management interface.

5. The method according to claim 1, characterized in that, Establishing an interaction link between the backend device and the target business database includes: The type of the target business database is determined based on the database type identifier in the connection configuration information; Based on the type of the target business database, a corresponding database driver is matched from the integrated multi-type database drivers, and the database driver is used to implement communication with the target business database; A network connection is established between the backend device and the target business database using the network address and access port in the connection configuration information, thus forming an interaction link between the backend device and the target business database.

6. The method according to claim 1, characterized in that, After executing the corresponding data operation in the target business database based on the SQL statement corresponding to the operation request, the method further includes: A data operation verification mechanism is initiated, which is used to verify the legality and consistency of the SQL statement execution process and execution results. If the data operation verification mechanism passes the verification, the SQL statement execution result is confirmed to be valid and the data is persisted. If the data operation verification mechanism fails, an exception handling strategy is triggered to undo the impact of the executed SQL statement on the target business database.

7. The method according to claim 6, characterized in that, Enable data operation verification mechanism, including: Based on the data operation type to be executed and the field attributes of the target management table in the structured metadata, the corresponding transaction initialization parameters are matched from the preset transaction configuration template library. The database transaction is started based on the transaction initialization parameters. The database transaction is used to integrate all related SQL statements initiated by the backend device against the target management table in the target business database into an indivisible operation unit. When all SQL statements in the operation unit have been executed and have passed the verification without timeout, the execution results of all SQL statements are permanently effective in the database. The number of rows affected by the operation after the backend device executes the SQL statement corresponding to the operation request is obtained. The number of rows affected by the operation is used to indicate the number of records that actually change the data in the target management table of the target business database. The number of rows affected by the operation is verified according to the preset number of rows affected in the data management rules. For operations involving business logic relationships, based on the table relationships recorded in the structured metadata, the target field data of the associated table in the target business database is queried, and the target field data of the associated table is verified to conform to the preset business logic.

8. The method according to claim 7, characterized in that, The number of rows affected by the operation is verified according to the preset standard for the number of affected rows in the data management rules, including: A basic check is performed on the number of rows affected by the operation based on the threshold range in the data management rules. When the number of rows affected by the operation exceeds the upper or lower limit of the threshold range, the basic check is indicated to fail. The number of rows affected by the operation is dynamically verified based on the dynamic fluctuation threshold. When the number of rows affected by the operation is greater than the dynamic fluctuation threshold, the dynamic threshold verification is indicated as failing. The dynamic fluctuation threshold is a threshold obtained by weighting the historical number of rows affected by the operation in the target management table within a preset time range using a time decay factor. Obtain the number of rows affected by the synchronization operation in the associated table, establish a mapping relationship between the number of rows affected by the operation and the number of rows affected by the synchronization operation, and indicate that the association verification fails when the mapping relationship does not conform to the preset business association ratio rule. The associated table is the management table that has a business association or data dependency relationship with the target management table when the backend device executes the SQL statement corresponding to the operation request on the target management table in the target business database.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Based on the historical query frequency data of SQL statements for querying target management tables and the update frequency characteristics of table data, a query update frequency matrix is ​​constructed. Based on the query update frequency matrix, query results with high frequency queries and low frequency updates are divided into the first type of cache level, and the query results of the first type of cache level are completely stored in the memory cache area of ​​the backend device. Based on the query update frequency matrix, query results with medium-frequency queries and medium-frequency updates are divided into a second type of cache level, and the target fields in the query results of the second type of cache level are stored in the ordinary storage area of ​​the backend device. Based on the query update frequency matrix, query results with low frequency or high frequency are classified into a third cache level, and the query results of the third cache level are not cached.

10. A data management device, characterized in that, The device includes: The first acquisition module is used to acquire the connection configuration information of the target business database and the structured metadata of the target management table. The connection configuration information is used to establish the interaction link between the backend device and the target business database. The second acquisition module is used to acquire the data management rules set for the target management table, wherein the data management rules include at least the data operation types to be performed; The first generation module is used to generate SQL statements corresponding to the data operation type based on the structured metadata, the data management rules, and the syntax rules of the target business database. The second generation module is used to adapt and logically bind the preset interface template based on the structured metadata and the data management rules to generate static interface resources. The static interface resources are used to generate the data management interface after being loaded by the front-end device. The interactive functions of the data management interface correspond one-to-one with the SQL statements of the corresponding data operation types. The execution module is used to receive the operation request initiated by the front-end device based on the data management interface, execute the corresponding data operation in the target business database based on the SQL statement corresponding to the operation request, and feed back the operation result to the front-end device so that the front-end device can display the operation result in the data management interface.

11. A storage medium, characterized in that, The storage medium includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the data management method as described in any one of claims 1-9.

12. An electronic device, characterized in that, The device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the data management method as described in any one of claims 1-9.

Images