A database script conversion method, apparatus and system

Abstract

This application discloses a database script conversion method, apparatus, and system, solving the problems of low script conversion efficiency and the inability to automatically optimize rules. The method includes: acquiring a database script, performing lexical and syntactic analysis to generate lexical units and data records representing syntactic combination relationships; comparing the data records with a syntactic conversion rule set to determine the target conversion action; converting the data records to generate a first target data record; modifying the first target data record to determine a second target data record; executing the script generated from the second target data record, and if successful, comparing the differences between the second and first target data records to update the syntactic conversion rule set. This application achieves automated script conversion and feedback learning, significantly improving the efficiency and accuracy of database migration.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a database script conversion method, apparatus and system. Background Technology

[0002] Migrating from traditional databases such as Oracle, MySQL, and SQL Server to new open-source databases faces the following technical challenges: compatibility issues, as new open-source databases differ from traditional databases in SQL syntax, transaction mechanisms, stored procedures, and function support, leading to high migration and adaptation costs; ensuring data consistency, requiring data integrity and transaction consistency during migration to avoid data loss or errors due to data type conversions, index rebuilding, and other operations; performance optimization and adaptation, as the storage engines and query optimizers of new open-source databases differ from traditional databases, necessitating re-tuning of SQL statements and index strategies after migration; and low automation, as existing migration tools (such as Oracle DG and GoldenGate) have insufficient support for new open-source databases, relying on manual script conversion, which is inefficient and prone to errors.

[0003] In existing technologies, database migration tools such as Oracle Migration Workbench are only applicable to specific databases and cannot be adapted to new open-source databases. They also have weak capabilities for converting complex SQL objects such as stored procedures during data migration. Manual migration combined with script conversion relies on DBA experience, is inefficient, error-prone, and difficult to scale.

[0004] Therefore, how to achieve efficient and accurate script conversion during database migration has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] This application proposes a database script conversion method, apparatus, and system to solve the problems of low script conversion efficiency and the inability to automatically optimize and update conversion rules during existing database migration processes due to syntax differences.

[0006] In a first aspect, embodiments of this application provide a database script conversion method, comprising the following steps:

[0007] Obtain the database script, perform lexical and syntactic analysis on the database script to generate lexical units and data records representing the syntactic combination relationships between the lexical units;

[0008] The data record is compared with a preset set of syntax conversion rules. If a rule that completely matches the data record exists, the conversion action corresponding to that rule is determined as the target conversion action for the data record. If no rule that completely matches exists, the target conversion action is determined according to a preset fuzzy matching strategy.

[0009] The lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record are converted to generate the first target data record;

[0010] Modify the first target data record to determine the second target data record;

[0011] A script is generated and executed based on the second target data record. If the execution is successful and the result matches the preset result, the second target data record is compared with the first target data record, and the syntax conversion rule set is updated according to the difference.

[0012] In one embodiment, the script corresponding to the first target data record is executed. If the execution fails or the execution result does not match the preset result, the process is rolled back to the third target data record corresponding to the database script before obtaining the second target data record. The third target data record is the version of the database script that was most recently successfully executed during this conversion process.

[0013] In one embodiment, determining the second target data record specifically includes the following steps:

[0014] Receive a modification instruction for the first target data record, modify the first target data record according to the modification instruction, and obtain a second target data record.

[0015] In one embodiment, a script is generated and executed based on the second target data record. If the execution fails or the execution result does not match the preset result, the script is executed repeatedly to modify the first target data record until the execution is successful or the preset number of times is reached.

[0016] In one embodiment, determining the target conversion action according to a preset fuzzy matching strategy includes:

[0017] Calculate the similarity between nodes that do not fully match in the data record and the matching conditions of each rule in the rule set, and determine the conversion action corresponding to the rule whose similarity meets the preset conditions as the target conversion action.

[0018] In one embodiment, when generating a script based on the second target data record, the target database type is identified. If the target database type supports optimization instructions, the corresponding optimization instructions are added to the script according to preset rules.

[0019] Secondly, embodiments of this application also provide a database script conversion apparatus for implementing the database script conversion method described in any embodiment of the first aspect, comprising: an acquisition module for acquiring a database script, performing lexical analysis and syntactic analysis on the database script to generate lexical units and data records representing syntactic combination relationships between lexical units; a comparison module for comparing the data records with a preset set of syntactic conversion rules, and if a rule that completely matches the data record exists, determining the conversion action corresponding to the rule as the target conversion action of the data record; if no rule that completely matches exists, determining the target conversion action according to a preset fuzzy matching strategy; a determination module for converting the lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record to generate a first target data record; and further for modifying the first target data record to determine a second target data record; and an execution module for generating a script based on the second target data record and executing it, and if the execution is successful and the execution result matches a preset result, comparing the second target data record with the first target data record and updating the syntactic conversion rule set according to the differences.

[0020] Thirdly, embodiments of this application also provide a database script conversion system, comprising: a management server, which is equipped with the database script conversion device as described in the second aspect embodiment, or configured to execute the database script conversion method as described in any one of the first aspect embodiments; a managed terminal, communicatively connected to the management server, for providing database scripts, receiving and executing scripts corresponding to a second target data record sent by the management server, and returning the execution result to the management server; and a core database, connected to the management server, for storing syntax conversion rule sets, data records, and update logs.

[0021] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any one of the embodiments of the first aspect.

[0022] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method as described in any one of the embodiments of the first aspect.

[0023] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0024] This application generates lexical units and data records representing grammatical combination relationships through lexical and syntactic analysis, providing a structured data foundation for rule matching and improving the accuracy of syntactic analysis and the efficiency of rule matching. It employs a rule engine for grammatical transformation rule matching, using a fuzzy matching strategy to determine the target transformation action when a precise match fails, effectively improving the automation of script transformation. By executing and verifying the transformed script, if execution fails or the result is inconsistent, it rolls back to the most recent valid target data record, ensuring business continuity and data consistency. Simultaneously, by obtaining a modified second target data record and comparing the differences to update the rule set, combined with machine learning and feedback loops, it achieves automatic training and growth of the rule model and verification model. Furthermore, by identifying the target database type and adding corresponding optimization instructions when generating the script, it achieves performance optimization of the migrated SQL, avoiding inefficient operations such as full table scans. In summary, this application effectively improves the efficiency of database script transformation, reduces errors, lowers labor and time costs, and achieves intelligent, automated, and continuous optimization of database script transformation. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0026] Figure 1 This is a flowchart illustrating a database script conversion method according to an embodiment of this application;

[0027] Figure 2 This is a complete flowchart illustrating a database script conversion method according to an embodiment of this application;

[0028] Figure 3 This is a schematic diagram of the structure of a database script conversion device according to an embodiment of this application;

[0029] Figure 4 This is a structural diagram of a database script conversion system according to an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0031] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0032] In a first aspect, embodiments of this application provide a database script conversion method, comprising the following steps:

[0033] Step 110: Obtain the database script, perform lexical and syntactic analysis on the database script to generate lexical units and data records representing the syntactic combination relationships between each lexical unit.

[0034] The database script refers to the source database script to be converted.

[0035] In practice, users can select the types of source and target databases, import script files, or directly enter script statements. The system supports batch import of script files.

[0036] For example, a user selects SQL Server as the source database and GaussDB as the target database, and imports a script file named "1.sql", which contains the SQL statements to be converted.

[0037] Furthermore, the batch script file import function allows users to select multiple script files for batch conversion at once. The system automatically processes and summarizes the conversion results of each script, generating a corresponding conversion report.

[0038] Lexical analysis refers to the process of splitting database script strings, identifying keywords (such as select, from, where) and special symbols (such as >=, ;) and marking them, and recording the position of each symbol.

[0039] Specifically, the process of marking and recording the position of special symbols includes: for symbols such as ">=", "<=", "<>", and ";", the system assigns specific symbol type identifiers to them during the lexical analysis stage and records their start and end positions in the script string so that the role of these symbols in the statement structure can be accurately located during subsequent syntax analysis.

[0040] The lexical unit refers to each grammatical unit generated after lexical analysis, which includes a morpheme and its corresponding type identifier.

[0041] For example, after lexical analysis, a series of lexical units are generated for a database script, and each lexical unit contains specific text content and its grammatical category.

[0042] Syntax analysis refers to the process of parsing the sequence of lexical units generated by lexical analysis to identify the logical structure of the database script. Through syntax analysis, it can be determined how each lexical unit combines into a complete sentence structure according to grammatical rules.

[0043] The data record that represents the grammatical combination relationship between each lexical unit refers to the data structure generated after grammatical analysis. This data structure records the attributes of each grammatical unit and their hierarchical relationship.

[0044] For example, for a query script, the data records generated after syntax analysis will contain complete structural information of the query statement, such as the various components of the query and their hierarchical relationships.

[0045] In one embodiment, the abstract syntax tree structure corresponding to the data record has the following node hierarchy:

[0046] Query

[0047] ├── SELECT

[0048] │ ├── TOP (100)

[0049] │ └── ColumnList

[0050] │ └── ColumnAlias ​​(product_name)

[0051] │ └── FunctionCall (ISNULL)

[0052] │ ├── ColumnReference (product_name)

[0053] │ └── Literal ('Product Name Empty')

[0054] ├── FROM

[0055] │ └── TableReference

[0056] │ └── QualifiedTableName

[0057] │ ├── DatabaseName (incrv8)

[0058] │ ├── SchemaName (NULL)

[0059] │ └── TableName (product)

[0060] └── WHERE

[0061] └── BinaryExpression (>=)

[0062] ├── ColumnReference (prem)

[0063] └── Literal (1000)

[0064] Detailed node description:

[0065] Query: The root node, representing the entire query statement.

[0066] SELECT: Query Entity

[0067] TOP (100): Limits the return to the first 100 records.

[0068] ColumnList: A list of selected columns / expressions

[0069] ColumnAlias ​​(product_name): Column alias

[0070] FunctionCall (ISNULL): Function call

[0071] ColumnReference(product_name): The first parameter (column reference) of the function.

[0072] Literal('product name empty'): The second parameter (a string constant) of the function.

[0073] FROM: Data Source

[0074] TableReference: Table reference

[0075] DatabaseName (incrv8): Database

[0076] TableName (product): Table Name

[0077] WHERE: Filtering conditions

[0078] BinaryExpression (>=): Comparison expression

[0079] ColumnReference (prem): left operand (column reference)

[0080] Literal (1000): Right operand (numerical constant)

[0081] The above node hierarchy clearly demonstrates the syntactic composition of SQL statements. Each node contains a type identifier and content information, and the parent-child relationship between nodes reflects the compositional relationship between syntactic units.

[0082] Step 120: Compare the data record with a preset set of syntax conversion rules. If there is a rule that completely matches the data record, then the conversion action corresponding to the rule is determined as the target conversion action of the data record; if there is no rule that completely matches, then the target conversion action is determined according to a preset fuzzy matching strategy.

[0083] The syntax transformation rule set refers to a pre-established set that stores syntax transformation rules from source database type to target database type.

[0084] For example, this rule set can contain transformation rules from multiple source databases to multiple target databases, and supports rule sets for new open source databases such as OceanBase, GaussDB, and DM.

[0085] In another embodiment, the rule engine module has thousands of pre-defined heterogeneous database transformation rules, covering syntax mappings between commonly used databases. For example, it converts Oracle's NVL() function to MySQL's IFNULL() function, SQL Server's GETDATE() function to GaussDB's CURRENT_TIMESTAMP function, and PostgreSQL's STRING_AGG() function to MySQL's GROUP_CONCAT() function. These rules can be continuously expanded and optimized according to actual application scenarios.

[0086] A rule that perfectly matches a data record refers to a rule in the rule base whose matching conditions are completely consistent with the syntactic features of the node to be transformed in the current data record.

[0087] For example, when a function call node in a data record perfectly matches the matching condition of a rule in the rule base, that rule is a perfect match rule.

[0088] When multiple rules match the same node simultaneously, the system selects the rule according to the preset priority and records the log.

[0089] The preset priority can be set based on the rule's generality, historical conversion accuracy statistics, or user-defined configuration. When multiple rules match the same node simultaneously, the system selects the rule with the highest priority as the target conversion rule and records this selection in a log file for subsequent rule optimization analysis. The log records include information about the matched node, all candidate rules and their priorities, the finally selected rule, and the selection timestamp.

[0090] The system dynamically adjusts the model through rule weights. Based on historical successful conversion case data, it performs statistical analysis on the hit rate and accuracy of each rule and automatically adjusts the priority weight of the rules periodically.

[0091] For example, if a rule successfully converts 95 out of the past 100 matches, its weight will gradually increase; conversely, the weight of a rule with a lower accuracy rate will be appropriately reduced.

[0092] The target conversion action refers to the specific operation that should be performed on the current node to be converted, converting it into the target database syntax.

[0093] For example, converting a function call specific to a certain database into an equivalent function call supported by the target database.

[0094] The preset fuzzy matching strategy refers to the strategy in which, when there is no perfect matching rule, the system finds a rule similar to the current node from the rule set according to a preset algorithm and determines its transformation action as the target transformation action.

[0095] Employing a fuzzy matching strategy can prevent the conversion process from being interrupted due to missing rules, thus improving the success rate of automated conversion. For nodes that complete the conversion through fuzzy matching, the system will indicate to the user that an exact match was not performed and that manual intervention is required.

[0096] The annotation format is implemented through the following technical means: the system adds a boolean type marker to the corresponding node of the abstract syntax tree, which is converted into a comment of a specific format and inserted into the script when the target script is generated.

[0097] For example, for function calls transformed by fuzzy matching, the system can add a " / " above them. Fuzzy matching conversion, please confirm manually. The comment " / ".

[0098] For example, for function calls converted using fuzzy matching, the system can add a comment above them indicating "fuzzy matching conversion, please confirm manually." This annotation mechanism transforms the non-technical requirement of reminding users into a technical feature that can be intuitively recognized by users.

[0099] For example, when a syntax node cannot find a completely matching rule in the rule base, the system finds the closest rule by calculating similarity and applies its transformation action.

[0100] In one embodiment, if no rule exactly matches the data record, and after determining the target transformation action according to the fuzzy matching strategy, the system automatically adds annotation information to the nodes in the generated script that applied the target transformation action. This annotation information clearly indicates to the user that the transformation used a non-precise matching strategy, requiring the user to pay close attention during subsequent verification or modification to ensure the accuracy of the transformation result. For example, in the generated SQL script, for function calls transformed through fuzzy matching, the system can add a comment above them stating "Fuzzy matching transformation, please manually confirm."

[0101] In one embodiment, determining the target conversion action according to a preset fuzzy matching strategy includes:

[0102] The nodes in the data record that are not fully matched are converted into feature vectors. The distance between the feature vectors and the feature vectors of each rule in the rule set is calculated. The conversion actions corresponding to the rules whose distance is less than a preset threshold are determined as the target conversion actions.

[0103] The nodes that are not fully matched refer to the syntax nodes that fail to find a complete match to the rule during the comparison process in step 120.

[0104] For example, a function call node that does not have a rule that matches it completely in the rule base is called an incompletely matched node.

[0105] The feature vector refers to the result of converting the attribute information of the syntax node into a numerical vector through a preset encoding method.

[0106] For example, information such as the type, content, and context of a node can be encoded into a set of numerical values.

[0107] The feature vector of each rule in the rule set refers to the corresponding numerical vector generated by pre-coding the matching conditions of each rule in the rule base.

[0108] For example, each rule in the rule base has its feature vector pre-computed and stored for quick similarity calculation.

[0109] The distance refers to the similarity measure between two feature vectors; the smaller the distance, the higher the similarity.

[0110] For example, Euclidean distance or cosine similarity can be used to calculate the distance between two feature vectors.

[0111] The preset threshold refers to a pre-defined similarity criterion used to determine whether two grammatical nodes are similar enough to apply the rule's conversion action.

[0112] For example, a threshold of 0.2 is set, and two nodes are considered sufficiently similar when the feature vector distance is less than 0.2.

[0113] In one embodiment, the syntax conversion rule set also includes rules corresponding to different database schema names. For example, the schema name "dbo" in the source database is converted to the specified schema name "dsp_cbps8_650000" in the target database.

[0114] Step 130: Convert the lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record to generate the first target data record.

[0115] The lexical unit and its grammatical combination relationship corresponding to the target conversion action refer to the part of the grammatical structure that needs to be converted by applying the target conversion action, as determined in step 120.

[0116] For example, based on the matched rules, it can be determined that the qualifying clause portion of the query statement needs to be transformed.

[0117] The aforementioned conversion refers to the process of converting the node type of lexical units, adjusting the structure of grammatical combination relations, or reconstructing them in combination with contextual information, according to the specific requirements of the target conversion action.

[0118] The above-mentioned reconstruction based on contextual information refers to determining the appropriate position of a syntactic unit in the target database based on the overall structure of the statement and making adjustments accordingly.

[0119] For example, converting the specific syntax of a certain database into an equivalent syntax supported by the target database, and adjusting its position in the statement according to the syntax rules of the target database.

[0120] In one embodiment, the specific process of reconstructing the query by incorporating contextual information includes: when transforming an SQL statement containing a TOP n clause, the system not only replaces its syntax structure with a LIMIT n clause supported by the target database, but also identifies the position of the TOP n clause in the original statement and its membership in the SELECT clause. Based on the syntax rules of the target database (such as GaussDB), the system automatically moves the generated LIMIT n clause to the end of the entire query statement, thereby ensuring that the transformed statement is semantically and syntactically correct.

[0121] The first target data record refers to the data structure that has been initially transformed after applying the target transformation action to the original data record.

[0122] For example, in the data records generated after the original query statement is transformed, some syntax nodes have been replaced or adjusted.

[0123] In one embodiment, the script corresponding to the first target data record is executed. If the execution fails or the execution result does not match the preset result, the process is rolled back to the third target data record corresponding to the database script before obtaining the second target data record. The third target data record is the version of the database script that was most recently successfully executed during this conversion process.

[0124] Executing the script corresponding to the first target data record refers to generating the target database based on the first target data record and executing the script in the test environment to verify the correctness of the conversion result.

[0125] After verifying the correctness of the conversion results, the system further verifies the execution efficiency of the script.

[0126] Specifically, when verifying execution efficiency, the system obtains execution plan details through the EXPLAIN command provided by the database to check for inefficient operations such as full table scans and improper use of indexes.

[0127] For example, if a query is found to have triggered a full table scan in the target database, the system will record this inefficient operation and trigger subsequent optimization processes. Criteria for determining a full table scan include: the execution plan containing keywords such as "Seq Scan," "TABLE SCAN," or "FULL TABLE SCAN," or the estimated number of rows to be scanned exceeding a preset threshold.

[0128] For example, an SQL script can be generated based on the transformed data records and executed in the test environment of the target database.

[0129] The execution failure refers to an exception such as a syntax error or runtime error that occurs when the generated script is executed in the target database.

[0130] For example, the script returns a syntax error message when it is executed.

[0131] The statement that the execution result does not match the preset result means that the script executes successfully, but the returned result set is inconsistent with the expected result. When executing the script corresponding to the first target data record, the execution result sets of the source database and the target database are compared. If the two are inconsistent, it is determined that the execution result does not match the preset result.

[0132] For example, the number of records returned after the script execution does not match the expectation. Execute the same query in both the source and target databases and compare the returned record counts or specific values ​​to see if they are consistent.

[0133] In one embodiment, the preset result specifically refers to the standard result set obtained by executing the source database script in the source database. During the verification phase, the system uses automated tools to execute the same logical query statement in both the source and target databases, and compares the returned result sets field by field and row by row. If inconsistencies are found, such as different record counts or differences in the value of a certain field, the system determines that the execution result does not match the preset result and triggers subsequent rollback or learning processes.

[0134] The rollback refers to discarding the current failed transformation result and restoring the script to a version that was successfully executed earlier in the current transformation process. Rolling back to the third target data record corresponding to the database script specifically includes automatically restoring the script to the most recent valid abstract syntax tree version in the current transformation process.

[0135] For example, if the current conversion version fails, the system automatically reverts to a previously validated version of the script. When a conversion fails, the system automatically discards the current version and reverts to a previously validated syntax tree structure.

[0136] It is important to note that the rollback operation is limited to historical versions of the same database script during this conversion process, and does not roll back to the conversion results of other scripts. Each database script independently maintains a record of successful versions during its conversion process. The system maintains a version stack for each script being processed, recording the target data record generated after each successful conversion. When the current conversion version verification fails, the system only pops the most recently successful version from the script's own version stack as the third target data record; version records between different scripts do not interfere with each other.

[0137] The third target data record refers to the version of the current database script that was most recently successfully executed during this conversion process.

[0138] For example, if a script successfully executes the first five transformations in this process, but fails on the sixth transformation, then the version generated by the fifth transformation is the third target data record.

[0139] The process of performing a rollback operation is defined before acquiring the second target data record. The second target data record is a version obtained through modifications in subsequent steps, and its acquisition may take a considerable amount of time. By performing a rollback operation before the second target data record is ready, a usable version can be provided immediately, preventing business interruptions due to conversion failures.

[0140] For example, when a conversion fails, the system immediately rolls back to the previous available version, while the background continues to try to obtain the modified version; the two processes run in parallel without conflict.

[0141] Step 140: Modify the first target data record to determine the second target data record.

[0142] Modifying the first target data record refers to manually or automatically adjusting the first target data record generated by the initial conversion to correct any conversion errors or imperfections that may exist.

[0143] For example, users can view the conversion results through the interface and manually adjust any incorrect parts.

[0144] The second target data record refers to the modified version of the target data record that can be executed correctly.

[0145] For example, the new version of the data record generated after manual adjustments by the user has been verified to execute correctly.

[0146] In one embodiment, determining the second target data record specifically includes the following steps:

[0147] Receive a modification instruction for the first target data record, modify the first target data record according to the modification instruction, and obtain a second target data record.

[0148] The system provides a graphical interface for modification, allowing users to directly manipulate syntax tree nodes or script content. The system automatically captures the differences in the abstract syntax tree before and after modification, including changes in node types, editing of node content, and adjustments to subtree structures. This difference data is then formatted into training samples (such as JSON or XML) for subsequent rule optimization analysis.

[0149] The modification instruction refers to a command generated manually that instructs the system to make specific adjustments to the first target data record.

[0150] For example, a user can select a syntax node through a graphical interface and specify that it should be replaced with another syntax form.

[0151] The modification according to the modification instruction means that after the system receives the instruction, it parses the instruction content, locates the corresponding node in the first target data record, and performs the modification operation according to the instruction requirements to generate a new data record.

[0152] For example, the system finds the corresponding function call node based on user instructions and replaces it with the function form specified by the user.

[0153] In one embodiment, if there are nodes in the first target data record that cannot be processed automatically, a marker is generated and manual intervention is prompted. For example, for nodes such as custom functions that cannot match the transformation rules, the system adds a marker to the generated script to remind the user to handle them manually.

[0154] In one embodiment, the nodes that cannot be automatically processed include, but are not limited to, nodes that do not match any exact match rules and cannot find similar rules through fuzzy matching strategies, such as user-defined functions, source database-specific stored procedures, or non-standard SQL syntax. Once the system identifies such nodes, it will generate a special marker in the generated first target data record and output clear prompts in the user interface or log file to guide manual intervention.

[0155] Step 150: Generate a script based on the second target data record and execute it. If the execution is successful and the execution result matches the preset result, compare the second target data record with the first target data record and update the syntax conversion rule set according to the difference.

[0156] The process of generating a script based on the second target data record refers to serializing the modified target data record, restoring it to a script of the target database, and performing standardized typesetting.

[0157] The system formats the serialized output script according to the syntax rules of the target database, including keyword case conversion (e.g., converting select to SELECT), indentation adjustment (e.g., using two spaces for each level of indentation), and line break control (e.g., each clause on a separate line).

[0158] For example, the modified data records can be converted into SQL scripts for the target database, and indented and line breaks can be added according to standard format.

[0159] Successful execution and the execution result matching the preset result means that the generated script does not report any errors when executed in the target database, and the execution result is consistent with the expected result.

[0160] For example, the modified script executes successfully in the target database, and the returned results are consistent with those in the source database.

[0161] The comparison between the second target data record and the first target data record refers to analyzing the differences between the modified version and the automatically converted initial version, and identifying which syntax nodes have been adjusted and how they have been adjusted.

[0162] Specifically, the difference analysis process includes: the system traverses the syntax tree nodes of the second target data record and the first target data record, and uses a depth-first or breadth-first algorithm to compare the differences in node type, node content, and hierarchical relationship between nodes, quantifying the differences into a set of difference feature vectors; the difference feature vectors may include node type change identifiers, node content edit distance, subtree structure change type (addition, deletion, movement, modification), etc.; based on the difference features, the system automatically creates new conversion rules or adjusts the matching priority of existing rules through a preset rule generation algorithm; the newly generated rules must be verified and tested before they can be added to the formal rule set.

[0163] For example, the system compares two versions of data records and finds that a function call in a certain place has been modified to another form.

[0164] The phrase "updating the syntax transformation rule set based on differences" refers to converting the identified effective adjustment methods into new transformation rules or optimizing existing rules and adding them to the rule set.

[0165] The syntax transformation rule set is updated based on the differences, specifically including: converting the identified effective adjustment methods into new transformation rules or optimizing existing rules and adding them to the rule set; and training the adjustment differences of multiple scripts using machine learning algorithms to continuously optimize the rule model and the validation model.

[0166] The system employs a versioned storage mechanism for rule sets, with each rule and its weight configuration carrying a version identifier and historical records. Based on the rule weight update algorithm derived from validation results, the system periodically performs incremental updates to the rule set. Simultaneously, the system supports a periodic retraining mechanism (e.g., weekly) to comprehensively optimize the rule model using accumulated differential data.

[0167] The specific implementation of the machine learning optimization process is as follows: The system collects a large amount of script comparison data before and after manual adjustment as training samples. Each sample contains information such as original node features (e.g., node type, node content, parent node type, sibling node relationship), application rule identifier, and manually modified node features; a machine learning algorithm is used to train a rule recommendation model to provide more accurate rule recommendations during fuzzy matching; the model is retrained in the background periodically and supports verification of the optimization effect of the new model to ensure that model updates do not introduce new conversion errors.

[0168] For example, the system will identify the function call transformation method and create a new rule, adding it to the rule base. This rule can then be directly applied to similar situations in the future. The system collects a large amount of script comparison data before and after manual adjustments, and uses machine learning to generate new transformation rules or adjust the matching priority of existing rules.

[0169] In one embodiment, the update process is not limited to a rule-based model. The system continuously accumulates script difference data before and after manual adjustments, trains the model using machine learning algorithms, and simultaneously optimizes the validation model. For example, the trained validation model can more accurately predict which types of transformation scripts are prone to full table scans or data type mismatch errors during execution, thus enabling more rigorous checks during the validation phase or providing early optimization warnings.

[0170] In one embodiment, a script is generated and executed based on the second target data record. If the execution fails or the execution result does not match the preset result, the script is executed repeatedly to modify the first target data record until the execution is successful or the preset number of times is reached.

[0171] The repeated execution of modifications refers to the system allowing multiple rounds of modifications to be performed when the modified version still fails to execute correctly.

[0172] For example, if the script still fails to execute after the user's first modification, the user can continue to modify it until it succeeds.

[0173] The term "reaching the preset number of times" refers to the system setting a maximum limit on the number of modifications. If a successful version is not obtained after reaching this number of modifications, the system marks the script as requiring special handling.

[0174] For example, the system sets a maximum of 5 modifications. If the script fails to make changes after 5 attempts, it is marked as abnormal.

[0175] In one embodiment, when generating a script based on the second target data record, the target database type is identified. If the target database type supports optimization instructions, the corresponding optimization instructions are added to the script according to preset rules.

[0176] The optimization instructions refer to query optimization suggestions for a specific database.

[0177] Optimization instructions use database-specific HINT annotation syntax to guide the optimizer to choose a better execution path, such as forcing the use of a certain index, adjusting the table join order, or selecting a specific join algorithm.

[0178] After identifying inefficient operations such as full table scans and improper index usage during execution plan analysis, the system not only automatically adds optimization instructions but also generates readable optimization tips.

[0179] For example, the system can prompt "A full table scan has been detected. It is recommended to create an index or add a HINT comment to force the use of the index" and insert optimization instructions directly into the script. Users only need to confirm to apply the optimization solution.

[0180] The syntax of optimization commands differs between different databases. The system automatically adapts the corresponding optimization command format according to the target database type.

[0181] For example, some databases support using special annotation syntax to prompt the optimizer to choose a better execution plan.

[0182] The addition of optimization instructions according to preset rules refers to the system automatically selecting appropriate optimization instructions and inserting them into the generated script based on the target database type and the specific structure of the script.

[0183] For example, the system identifies the target database as GaussDB and automatically adds corresponding optimization hints and comments based on the script structure.

[0184] In one embodiment, when generating a script based on the second target data record, the system first analyzes the script's execution plan. For example, it obtains execution plan details using the EXPLAIN command provided by the database to check for inefficient operations such as full table scans or improper index usage. If the execution efficiency is found to be lower than a preset standard, the system adds corresponding optimization instructions to the script according to preset rules, or generates explicit optimization prompts. For example, if a query statement is found to have triggered a full table scan in GaussDB, the system can automatically add / + INDEX(table_name_index_name) The / HINT comment forces the query to use a specific index.

[0185] In one embodiment, after a script is generated and executed based on the second target data record, if the execution efficiency is detected to be lower than a preset standard, an optimization prompt message is generated.

[0186] For example, if the execution plan of the script is analyzed and a full table scan is found, the user is prompted to consider adding an index or rewriting the query.

[0187] In one embodiment, to support the conversion of complex SQL objects, the system establishes a subset of conversion rules for object types such as stored procedures, functions, triggers, and views.

[0188] For example, when converting stored procedures, the system not only converts the SQL statements during the process, but also handles the stored procedure-specific syntax structures such as parameter passing, variable declaration, cursor operations, exception handling, conditional control statements (IF-ELSE, CASE), and loop statements (LOOP, WHILE, FOR), ensuring that the converted stored procedure can be executed completely in the target database. Each subset of conversion rules for each object type maintains its own version and priority.

[0189] Figure 2This is a complete flowchart of a database script conversion method provided in an embodiment of this application.

[0190] like Figure 2 As shown, in one embodiment, taking the source SQL Server database and the target GaussDB database as examples, the database script conversion method described in this application is fully explained.

[0191] First, enter the source SQL script. Before importing the script, you need to select the names of the source and target databases. For the source, select SQL Server, and for the target, select GaussDB. Import the 1.sql script; the script content is as follows:

[0192] SELECT top 100 isnull(product_name,'product name is empty') as product_name fromincrv8..product where prem>=1000;

[0193] This application embodiment corresponds to the step of obtaining the database script in step 110.

[0194] Next, lexical and syntactic analysis are performed. The database script string is split and processed, keywords such as select, from, and where are identified, and special symbols such as >= and ; are marked and their positions are recorded. Syntactic analysis is then performed to parse the logical structure of the database script and construct an abstract syntax tree.

[0195] The embodiments of this application correspond to the lexical analysis and syntax analysis steps in step 110.

[0196] Then, rule base matching is performed. Based on the types of the source and target databases, the rule engine module is invoked to match rules such as script syntax correspondence and database schema name correspondence. For exact matches that fail, fuzzy rule matching is performed, and the user is notified of locations where no exact match has been found through annotation. When multiple rules match the same node, they are selected according to priority and logged.

[0197] When mapping schema names, the system converts the schema names in the source database to the specified names in the target database according to preset mapping rules.

[0198] For example, the schema name "dbo" in the source database can be converted to "dsp_cbps8_650000" in the target database. Schema name mapping rules can be set based on global configuration, database type pairs, or user-defined mapping tables.

[0199] In this embodiment of the application, the step of comparing the data record with the rule set and determining the target conversion action corresponds to step 120.

[0200] Next, the SQL statement nodes are refactored. The abstract syntax tree is traversed, and transformation rules are applied to refactor the script through node type conversion, subtree structure adjustment, and context combination.

[0201] In this embodiment of the application, the step of converting the data record and generating the first target data record corresponds to step 130.

[0202] Then, the target SQL script is generated. The abstract syntax tree is serialized into the target database SQL, and the script is standardized for the target database. The generated script content is as follows:

[0203] SELECT nvl(product_name,'product name is empty') as product_name from dsp_cbps8_650000.product where prem>=1000 limit 100;

[0204] In this embodiment of the application, the step of generating a script based on data records corresponds to step 150.

[0205] Finally, verification and optimization are performed. The transformed SQL is executed in an isolated environment for verification. The query result sets of the source database and the target database are compared to check whether the execution plan contains inefficient operations such as full table scans. For scripts with low execution efficiency, prompts are given and optimization suggestions are provided.

[0206] This application embodiment corresponds to the step of executing script verification in step 150.

[0207] If SQL validation fails after conversion, it will automatically revert to the most recent valid abstract syntax tree version.

[0208] This application embodiment corresponds to the step of rolling back to the third target data record in embodiment 130.

[0209] For nodes that cannot be handled automatically, such as custom functions, generate a flag and prompt for manual intervention.

[0210] The embodiments of this application add a step after step 140 where node tag generation cannot be automatically processed.

[0211] The system compares the SQL scripts before and after manual adjustments, and continuously optimizes the rule model and validation model by combining machine learning and feedback loop.

[0212] The embodiments of this application correspond to the step of comparing differences and updating the rule set in step 150, as well as the embodiment of combining machine learning to optimize the rule model.

[0213] Figure 3 This is a structural diagram of a database script conversion device provided in an embodiment of this application.

[0214] Secondly, embodiments of this application also provide a database script conversion apparatus for implementing the database script conversion method described in any one of the embodiments of the first aspect, comprising:

[0215] The acquisition module 301 is used to acquire a database script, perform lexical analysis and syntax analysis on the database script, and generate lexical units and data records representing the syntactic combination relationships between each lexical unit.

[0216] The comparison module 302 is used to compare the data record with a preset set of syntax conversion rules. If there is a rule that completely matches the data record, the conversion action corresponding to the rule is determined as the target conversion action of the data record. If there is no rule that completely matches, the target conversion action is determined according to a preset fuzzy matching strategy.

[0217] The determining module 303 is used to convert the lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record to generate a first target data record; it is also used to modify the first target data record to determine a second target data record.

[0218] The execution module 304 is used to generate a script based on the second target data record and execute it. If the execution is successful and the execution result matches the preset result, the second target data record is compared with the first target data record, and the syntax conversion rule set is updated according to the difference.

[0219] Furthermore,

[0220] The acquisition module includes a first acquisition unit, which is used to acquire a database script, perform lexical analysis and syntax analysis on the database script, and generate lexical units and data records representing the syntactic combination relationships between each lexical unit.

[0221] The comparison module includes a first comparison unit, which is used to compare the data record with a preset set of syntax conversion rules. If there is a rule that completely matches the data record, the conversion action corresponding to the rule is determined as the target conversion action of the data record; if there is no rule that completely matches, the target conversion action is determined according to a preset fuzzy matching strategy.

[0222] The determining module includes a first determining unit, which is used to convert the lexical units and their grammatical combination relationships corresponding to the target conversion action in the data record to generate a first target data record.

[0223] The determining module further includes a second determining unit, used to modify the first target data record to determine the second target data record.

[0224] The execution module includes a first execution unit, which is used to generate a script based on the second target data record and execute it. If the execution is successful and the execution result matches the preset result, the second target data record is compared with the first target data record, and the syntax conversion rule set is updated according to the difference.

[0225] In one embodiment, the comparison module further includes a second comparison unit, used to select and record logs according to a preset priority when multiple rules match the same node simultaneously.

[0226] This embodiment is used to implement the function of selecting and logging rules according to priority when multiple rules match the same node at the same time in step 120.

[0227] In one embodiment, the first comparison unit is specifically used for:

[0228] The nodes in the data record that are not fully matched are converted into feature vectors. The distance between the feature vectors and the feature vectors of each rule in the rule set is calculated. The conversion actions corresponding to the rules whose distance is less than a preset threshold are determined as the target conversion actions.

[0229] This embodiment is used to implement the function of matching by feature vector distance calculation when determining the target conversion action according to the preset fuzzy matching strategy in step 120.

[0230] In one embodiment, the determining module further includes a third determining unit, which is used to execute the script corresponding to the first target data record. If the execution fails or the execution result does not match the preset result, and before obtaining the second target data record, the execution is rolled back to the third target data record corresponding to the database script. The third target data record is the version of the database script that was most recently successfully executed during this conversion process.

[0231] This embodiment is used to implement the function of rolling back to the third target data record when the execution of the script corresponding to the first target data record fails in step 130.

[0232] In one embodiment, the second determining unit is specifically used for:

[0233] Receive a modification instruction for the first target data record, modify the first target data record according to the modification instruction, and obtain a second target data record.

[0234] This embodiment is used to implement the function of determining the second target data record by receiving modification instructions in step 140.

[0235] In one embodiment, the execution module further includes a second execution unit, which is used to generate a script based on the second target data record and execute it. If the execution fails or the execution result does not match the preset result, the first target data record is modified repeatedly until the execution is successful or the preset number of times is reached.

[0236] This embodiment is used to implement the function of repeatedly executing the modification when the second target data record fails in step 150.

[0237] In one embodiment, the execution module further includes a third execution unit, which is used to identify the target database type when generating a script based on the second target data record, and if the target database type supports optimization instructions, add the corresponding optimization instructions to the script according to preset rules.

[0238] This embodiment is used to implement the function of adding optimization instructions when generating the script based on the second target data record in step 150.

[0239] In one embodiment, the comparison module further includes a third comparison unit for configuring the syntax transformation rule set to include transformation rules from multiple source database types to multiple target database types.

[0240] This embodiment is used to implement the function of syntax transformation rule set supporting multiple database types.

[0241] In one embodiment, the determining module further includes a fourth determining unit, which is used to generate an optimization prompt message if the execution efficiency is detected to be lower than a preset standard after the script is generated and executed based on the second target data record.

[0242] This embodiment is used to implement the function of detecting execution efficiency and generating optimization suggestions in step 150.

[0243] In one embodiment, the determining module further includes a fifth determining unit, used to generate a marker and prompt manual intervention if there are nodes in the first target data record that cannot be processed automatically.

[0244] This embodiment is used to implement the function of generating tags when nodes cannot be automatically processed after step 140.

[0245] In one embodiment, the first execution unit is specifically used for:

[0246] The identified effective adjustment methods are transformed into new conversion rules or existing rules are optimized and added to the rule set; the adjustment differences of multiple scripts are trained using machine learning algorithms to continuously optimize the rule model and the validation model.

[0247] This embodiment is used to implement the function of combining machine learning optimization when updating the rule set according to the differences in step 150.

[0248] In one embodiment, the third determining unit is specifically used for:

[0249] Automatically revert to the most recent valid version of the abstract syntax tree for this script during this transformation process.

[0250] This embodiment is used to implement the function of automatically restoring to the most recent valid abstract syntax tree version when rolling back to the third target data record in step 130.

[0251] Figure 4 This is a structural diagram of a database script conversion system provided in an embodiment of this application.

[0252] Thirdly, embodiments of this application also provide a database script conversion system, comprising:

[0253] The managed terminal 500 is used to provide database scripts, receive the script corresponding to the second target data record sent by the server, execute it, and return the execution result to the server.

[0254] Server 400, communicatively connected to the managed terminal 500, includes:

[0255] Management server 401 is equipped with a database script conversion device as described in the second aspect embodiment, or is configured to execute a database script conversion method as described in any of the first aspect embodiments, for performing database script acquisition, lexical analysis, syntax analysis, rule matching and conversion operations, and modifying a first target data record to determine a second target data record.

[0256] The core database 402 is connected to the management server 401 and is used to store syntax conversion rule sets, data records and update logs.

[0257] It should be noted that the data record described in this application is a specific implementation of an abstract syntax tree (AST), which includes all node information (node ​​type, node content, node attributes) and hierarchical relationships between nodes. In practice, the data record can be stored and transmitted using a tree data structure, JSON format, or XML format. The advantage of implementing the abstract syntax tree as a data record lies in its ease of serialization, network transmission, and cross-platform interaction.

[0258] In one embodiment, the server 400 further includes a verification server 403, which is connected to the management server 401 and the core database 402, and is used to generate and execute a script based on the second target data record to verify the correctness of the execution result.

[0259] In one embodiment, the server 400 further includes a learning server 404 connected to the management server 401 and the core database 402, for comparing differences in data records and updating the syntax conversion rule set.

[0260] In one embodiment, the server 400 further includes a rule base server 405, which is connected to the management server 401 and the core database 402, and is used to read the syntax transformation rule set from the core database 402 and provide it to the management server 401.

[0261] In one embodiment, the server 400 further includes a log server 406 connected to the verification server 403 and the core database 402, for reading and writing data records and updating logs from the core database 402.

[0262] In one embodiment, the database script conversion system further includes the following core components:

[0263] The SQL parsing module is used to execute the method described in step 110, namely, to perform lexical and syntactic analysis on the acquired database script, generate an abstract syntax tree (AST), and extract metadata from the abstract syntax tree; the metadata includes table structure, constraints, index information, and data type definitions.

[0264] The rule engine module is used to execute the method described in step 120, that is, to store a set of syntax conversion rules from source database type to target database type; the rule engine module has thousands of heterogeneous database conversion rules pre-set, such as converting the NVL() function of Oracle database to the IFNULL() function of MySQL database.

[0265] The code generation module is used to execute the step 150 of generating a script based on the second target data record, that is, serializing the converted abstract syntax tree, restoring it to the SQL script of the target database, and performing standardized typesetting.

[0266] The code verification module is used to perform the script verification step in step 150, that is, to execute the converted SQL script in the test environment and verify its execution efficiency and correctness. The code verification module verifies correctness by comparing the execution result sets of the source database and the target database, evaluates execution efficiency by analyzing the execution plan, and automatically optimizes scripts with low execution efficiency, such as adding optimization instructions or generating optimization prompts.

[0267] The modules mentioned above work together to automate the conversion, verification, optimization, and update of database scripts.

[0268] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention 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.

[0269] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods described in any embodiment of this application.

[0270] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0271] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0272] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0273] Furthermore, this application also proposes an electronic device (or computing device) including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any embodiment of this application.

[0274] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-persistent, removable and non-removable media that can store information by 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-transfer medium that can be used to store information that can be accessed by the computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

[0275] 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. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0276] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0277] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical, technical, and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0278] The above description is merely an embodiment of this application and is 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 database script conversion method, characterized in that, Includes the following steps: Obtain the database script, perform lexical and syntactic analysis on the database script to generate lexical units and data records representing the syntactic combination relationships between each lexical unit; The data record is compared with a preset set of syntax conversion rules. If a rule that completely matches the data record exists, the conversion action corresponding to that rule is determined as the target conversion action for the data record. If no rule that completely matches exists, the target conversion action is determined according to a preset fuzzy matching strategy. The lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record are converted to generate the first target data record; Modify the first target data record to determine the second target data record; A script is generated and executed based on the second target data record. If the execution is successful and the result matches the preset result, the second target data record is compared with the first target data record, and the syntax conversion rule set is updated according to the difference.

2. The database script conversion method according to claim 1, characterized in that, The script corresponding to the first target data record is executed. If the execution fails or the execution result does not match the preset result, the process is rolled back to the third target data record corresponding to the database script before obtaining the second target data record. The third target data record is the version of the database script that was most recently successfully executed during this conversion process.

3. The database script conversion method according to claim 1, characterized in that, Determining the second target data record specifically includes the following steps: Receive a modification instruction for the first target data record, modify the first target data record according to the modification instruction, and obtain a second target data record.

4. The database script conversion method according to claim 1, characterized in that, A script is generated and executed based on the second target data record. If the execution fails or the execution result does not match the preset result, the script is executed repeatedly to modify the first target data record until the execution is successful or the preset number of times is reached.

5. The database script conversion method according to claim 1, characterized in that, The step of determining the target conversion action according to the preset fuzzy matching strategy includes: Calculate the similarity between nodes that do not fully match in the data record and the matching conditions of each rule in the rule set, and determine the conversion action corresponding to the rule whose similarity meets the preset conditions as the target conversion action.

6. The database script conversion method according to claim 1, characterized in that, When generating a script based on the second target data record, the target database type is identified. If the target database type supports optimization instructions, the corresponding optimization instructions are added to the script according to preset rules.

7. A database script conversion apparatus for implementing the database script conversion method according to any one of claims 1-6, characterized in that, Include: The acquisition module is used to acquire a database script, perform lexical analysis and syntax analysis on the database script, and generate lexical units and data records representing the syntactic combination relationships between the lexical units. The comparison module is used to compare the data record with a preset set of syntax conversion rules. If there is a rule that completely matches the data record, the conversion action corresponding to the rule is determined as the target conversion action of the data record. If there is no rule that completely matches, the target conversion action is determined according to a preset fuzzy matching strategy. The determining module is used to convert the lexical units and their syntactic combination relationships corresponding to the target conversion action in the data record to generate a first target data record; it is also used to modify the first target data record to determine a second target data record; The execution module is used to generate and execute a script based on the second target data record. If the execution is successful and the execution result matches the preset result, the second target data record is compared with the first target data record, and the syntax conversion rule set is updated according to the difference.

8. A database script conversion system, characterized in that, Include: The management server is equipped with the database script conversion device as described in claim 7, or is configured to execute the database script conversion method as described in any one of claims 1-6; The managed terminal is connected to the management server and is used to provide database scripts, receive and execute the script corresponding to the second target data record sent by the management server, and return the execution result to the management server. The core database, connected to the management server, is used to store syntax conversion rule sets, data records, and update logs.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-6.

Images