Heterogeneous database migration method and device

Abstract

The invention relates to the technical field of databases, and provides a heterogeneous database migration method and device.The method comprises the steps that object definition metadata of a source database and business logic codes of an associated application system are obtained; performing grammar structure analysis on the business logic code, and identifying grammar incompatible items and structure difference items between the source database and the target database in combination with the object definition metadata; on the basis of a preset difference adaptation rule base, matching rewriting strategies corresponding to the grammar incompatible items and the structure difference items; converting the object definition metadata into a target structure definition adaptive to the target database according to a rewriting strategy, and reconstructing the business logic code into a target execution statement adaptive to the target database; according to the method, the target database environment is constructed based on the target structure definition, and the target execution statement is configured in the target database environment or the business interface associated with the target database environment, so that the uncertainty of manual code correction is avoided, and the operation stability of the system in the heterogeneous database environment is improved.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method and apparatus for migrating heterogeneous databases. Background Technology

[0002] With the deepening of the national information technology innovation project, the replacement of databases for enterprise-level application systems with domestically produced ones has become an inevitable trend. In this process, many critical business systems originally built on MySQL, such as supplier relationship management systems, face an urgent need to migrate to domestically produced databases due to their large data volume, complex SQL logic, and high dependence on specific MySQL syntax features. Such migrations not only require the replacement of data storage but also demand the maintenance of system business continuity, data consistency, and performance stability under the information technology innovation environment.

[0003] Existing database migration solutions typically employ general-purpose data extraction, transformation, and loading tools; built-in logical export and import commands of the database; or manual code modification. In practice, technicians often rely on standard SQL statements for data transfer and utilize text processing techniques such as regular expression replacement to attempt to convert the table structure of the source database and the query statements in the business code into a format supported by the target database, thereby completing the switch between heterogeneous databases.

[0004] However, a major technical problem with using the existing technologies for migration is the lack of an automated compatibility and adaptation mechanism for the deep syntactic logic and structural characteristics between heterogeneous databases. Because it is impossible to accurately identify and automatically repair incompatibilities caused by differences in database dialects, data type mappings, and underlying object definitions through rule-based methods, existing solutions struggle to guarantee the correct execution of business logic and data consistency after migration with minimal human intervention. This results in high migration risks and difficulty in ensuring the stability of core business systems. Summary of the Invention

[0005] This invention provides a heterogeneous database migration method and apparatus to address the shortcomings of existing technologies that lack an automated compatibility and adaptation mechanism for the deep syntax logic and structural characteristics between heterogeneous databases, resulting in difficulty in ensuring the correctness of business logic execution and data consistency after migration, as well as high migration risk and poor stability.

[0006] This invention provides a method for migrating heterogeneous databases, comprising: Obtain the object definition metadata from the source database and the business logic code of the associated application system; The business logic code is parsed using syntax structure analysis, and combined with the object definition metadata, the syntax incompatibilities and structural differences between the source database and the target database are identified. Based on a preset difference adaptation rule base, a rewriting strategy is matched with the grammar incompatibility items and structural difference items; According to the rewriting strategy, the object definition metadata is converted into a target structure definition adapted to the target database, and the business logic code is refactored into a target execution statement adapted to the target database. Based on the target structure definition, a target database environment is constructed, and the target execution statement is configured in the target database environment or its associated business interface to complete the database migration and adaptation.

[0007] According to the heterogeneous database migration method provided by the present invention, the step of parsing the syntax structure of the business logic code includes: decomposing the static structured query statement in the business logic code to generate a syntax tree node containing function calls, keywords and syntax clauses; pre-sampling the dynamic query statement in the business logic code to obtain the actual query statement generated at runtime, and parsing the actual query statement into a dynamic syntax structure.

[0008] According to the heterogeneous database migration method provided by the present invention, the step of identifying the syntax incompatibility items and structural differences between the source database and the target database by combining the object definition metadata includes: extracting the field types, index types and constraint attributes from the object definition metadata, and comparing them with the preset mapping rules and support list of the target database respectively, so as to identify the field type mismatch items, index type unsupported items and constraint attribute incompatibility items existing in the source database as the structural differences items; The syntax tree nodes and dynamic syntax structure are traversed to extract the function identifiers, reserved keywords, and query logic clauses contained therein. These are then matched against the syntax rule base of the target database. Function identifiers, reserved keywords, and query logic clauses that are not supported by the target database are selected as the syntax incompatibilities.

[0009] According to the heterogeneous database migration method provided by the present invention, when the identified structural difference item is an auto-incrementing column attribute in the source database table structure, the matching rewriting strategy is a combination strategy of mapping the auto-incrementing attribute to a sequence object and a trigger object. The step of converting the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy includes: Execute the aforementioned combination strategy to generate definition statements that create sequence objects in the target database; Get the current maximum value of the auto-incrementing column in the source database, and generate a sequence synchronization statement that sets the starting value of the sequence object based on the current maximum value; Generate a definition statement to create a pre-insert trigger in the target database, wherein the pre-insert trigger is configured to retrieve a value from the sequence object and assign it to the target column during a data insertion operation; The definition statement for creating the sequence object, the sequence synchronization statement, and the definition statement for creating the pre-insertion trigger are combined into the target structure definition.

[0010] According to the heterogeneous database migration method provided by the present invention, the step of constructing the target database environment based on the target structure definition specifically includes: connecting to the target database instance, executing the target structure definition to establish a data table structure, and temporarily disabling non-primary key indexes and foreign key constraints in the table structure; After establishing the data table structure, data migration is performed. The data tables of the source database are divided into multiple data shards according to the primary key range, and the data shards are fully imported into the target database environment using a multi-threaded parallel approach. After the full import is completed, based on the transaction change log of the source database, data change events generated during the full import are captured, and the data change events are replayed to the target database environment to achieve incremental synchronization. After the data migration is completed, the non-primary key indexes and foreign key constraints are rebuilt to complete the construction of the target database environment.

[0011] According to the heterogeneous database migration method provided by the present invention, the step of replaying the data change event to the target database environment to achieve incremental synchronization includes: Parse the global transaction identifier and operation location in the transaction change log; Before playback, query the synchronization log table in the target database to determine whether the global transaction identifier for the current data change event already exists; If it does not exist, execute the data change event and write the corresponding global transaction identifier into the synchronization log table to achieve incremental synchronization.

[0012] According to the heterogeneous database migration method provided by the present invention, the business logic code includes an object-relational mapping configuration file of the application system and a database connection configuration containing transaction isolation level parameters; configuring the target execution statement in the target database environment or its associated business interface includes: updating the target execution statement to the object-relational mapping configuration file; adapting the database connection configuration that serves as the business interface, replacing the database driver of the application system with a driver version adapted to the target database, and adjusting the transaction isolation level parameters to be consistent with the default level of the target database.

[0013] According to the heterogeneous database migration method provided by the present invention, after completing the migration and adaptation of the database, the method further includes: sorting the corresponding data tables in the source database and the target database according to the primary key and dividing them into several logical segments; calculating the concatenated hash value of the data in each logical segment in the source database and the target database respectively; comparing the concatenated hash values ​​at both ends, and if they are inconsistent, marking the logical segment as a difference segment, and comparing the data in the difference segment row by row to locate the specific difference data.

[0014] This invention provides a heterogeneous database migration device, comprising: The acquisition module is used to acquire object definition metadata from the source database and business logic code from the associated application system. The parsing module is used to parse the syntax structure of the business logic code and, in conjunction with the object definition metadata, identify the syntax incompatibilities and structural differences between the source database and the target database. The matching module is used to match rewriting strategies corresponding to the grammar incompatibility items and structural difference items based on a preset difference adaptation rule base; The refactoring module is used to convert the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and to refactor the business logic code into a target execution statement adapted to the target database. The migration module is used to construct a target database environment based on the target structure definition, and configure the target execution statement in the target database environment or its associated business interface to complete the migration and adaptation of the database.

[0015] The present invention also provides an electronic 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 heterogeneous database migration method as described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the heterogeneous database migration method as described above.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the heterogeneous database migration method as described above.

[0018] This invention provides a heterogeneous database migration method and apparatus. By parsing the syntactic structure of business logic code and combining it with object definition metadata, it can deeply identify hidden syntactic incompatibilities and structural differences between the source and target databases. This overcomes the shortcomings of existing technologies that cannot accurately locate database dialects and underlying object definition differences through rule-based methods. Furthermore, by using a preset difference adaptation rule base to automatically match and rewrite strategies, static metadata and dynamic business code are reconstructed into target structure definitions and target execution statements adapted to the target database. This ensures that the migrated data storage model and business query logic conform to the specifications of the target database, guaranteeing the correctness of business logic execution and the consistency of data storage. Finally, by constructing a target database environment based on the target structure definition and configuring the target execution statements in this environment or related business interfaces, it ensures that the migrated business logic can be correctly executed on the target database. This avoids the uncertainty and omissions caused by a large amount of manual code correction, thereby significantly reducing migration risks and improving the system's operational stability in heterogeneous database environments. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the heterogeneous database migration method provided by the present invention.

[0021] Figure 2 This is a schematic diagram of the heterogeneous database migration device provided by the present invention.

[0022] Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] When performing database migrations, the database's built-in import / export tools or general data migration tools are typically used. However, these methods have several major problems in practical applications.

[0025] First, the identification of differences before migration mainly relies on manual inspection of database table structures and SQL statements one by one. This is not only time-consuming, but also prone to missing incompatible syntax in stored procedures and triggers, and it is difficult to fully cover dynamically generated SQL statements in the application.

[0026] Secondly, after identifying incompatibility points, there is a lack of systematic automatic rewriting solutions. Common practices include manually writing conversion scripts or using simple text replacement, which makes it difficult to guarantee semantic consistency after conversion for complex nested queries, function calls, or transaction logic, and is prone to introducing errors.

[0027] Furthermore, consistency verification during data migration is inefficient. For tables with large amounts of data, a full table comparison or random sampling is usually required. The former consumes a lot of time and system resources, while the latter carries the risk of missed detections, making it difficult to complete reliable verification within a limited time.

[0028] Finally, the adaptation and transformation of the application system is relatively scattered, requiring modifications to multiple configurations, such as database connection drivers, connection pool settings, and transaction management. Moreover, once problems occur after migration, there is a lack of a quick rollback mechanism, resulting in a long system recovery time.

[0029] To address the above issues, this invention provides a database migration method based on syntax compatibility verification and differential adaptation. This method achieves efficient and reliable migration from the source database to the target database through automated differential identification, rule-based syntax rewriting, segmented parallel data migration, and hierarchical consistency verification.

[0030] Before describing the technical solutions of the embodiments of the present invention, the terms and concepts involved in the embodiments of the present invention will be explained illustratively.

[0031] Object definition metadata refers to data used to define and describe the structure and attributes of various objects in a database. Specifically, it includes table structure information (such as field names, data types, lengths, and whether null values ​​are allowed), primary key definitions, index information (type, associated fields), foreign key constraints, view definitions, and the source code of stored procedures and triggers. During migration, it forms the basis for analyzing structural differences between the source and target databases.

[0032] Business logic code: This refers to the code directly contained in the application or used to generate database operation instructions. It mainly includes: 1) static SQL statements written in mapping files; 2) dynamic SQL statements constructed in programming languages ​​such as Java using string concatenation; and 3) programmatic objects such as stored procedures, functions, and triggers on the database side. This code directly reflects the application's specific database operation logic.

[0033] Syntax incompatibility: This specifically refers to SQL elements in business logic code that are supported by the source database but not directly supported by the target database, or have different syntax. For example, the pagination keyword LIMIT and the specific function IFNULL() in MySQL may not exist in the target database or require the use of other keywords (such as FETCH FIRST…ROWS ONLY) and functions (such as COALESCE()) to replace them.

[0034] Structural differences: Specifically, at the object definition metadata level, the source and target databases use different technical mechanisms or support different data types when implementing the same function or concept. Common examples include: differences between the AUTO_INCREMENT attribute used to implement auto-incrementing primary keys and sequence and trigger mechanisms; database-specific field types (such as MySQL's TINYTEXT); or differences in the degree of support for index types (such as full-text indexes).

[0035] The difference adaptation rule base is a structured and extensible collection of rules, serving as the core knowledge base of this invention. Each rule specifies a method for converting a particular syntax incompatibility or structural difference (source form) to a target database-compatible form. Rules typically include matching conditions, conversion templates, execution priorities, and exception handling instructions.

[0036] Rewriting strategy: This refers to the specific transformation and adaptation scheme retrieved from the difference adaptation rule base for a particular grammatical incompatibility or structural difference identified during the analysis phase. It serves as the direct basis for guiding automated tools to perform rewriting.

[0037] Target structure definition: This refers to the object creation statements generated after applying a rewrite strategy, conforming to the syntax and characteristics of the target database. For example, a MySQL table creation statement containing AUTO_INCREMENT is transformed into a series of statements that create the corresponding table, sequence, and pre-insert triggers in the target database.

[0038] The target execution statement is the SQL statement or program code obtained after applying the rewrite strategy, which can be executed correctly on the target database and obtain the expected results. It ensures the continuity of business logic after migration.

[0039] A pre-insert trigger is a programmable object in a database that is automatically activated by the database system before a new record is inserted into a specified table. In this scheme, it is used to simulate the auto-incrementing primary key behavior of the source database in the target database: when an insertion occurs, it automatically retrieves the next value from the associated sequence and assigns it to the primary key field.

[0040] Transaction change log: This is an internal log file in the database system used to record all committed data change operations (such as insert, update, and delete) and their context (such as transaction number and timestamp), such as MySQL's binary log. During the incremental synchronization phase of a migration, parsing this log can reveal the new data changes that occurred on the source database after the full migration is complete.

[0041] Non-primary key indexes: These are indexes created on columns other than the primary key fields of a table, used to speed up queries based on these columns. During the full data import phase, to significantly improve insertion speed, these types of indexes are usually temporarily removed and then recreated after all data has been imported.

[0042] Foreign key constraints are rules defined between two tables to ensure data referential integrity. They require that the value of a field (foreign key) in the child table must exist in the primary key field of the parent table. Similar to non-primary key indexes, they are typically temporarily disabled during data migration and then re-enabled after the migration is complete to avoid constraint errors due to order issues during import.

[0043] A global transaction identifier is a global identifier used to uniquely identify a committed transaction in a data system that supports logical replication or distributed transactions. During incremental data synchronization, it can be used for tracking and deduplication, ensuring that each transaction is applied only once on the target end, thus achieving idempotency in synchronization.

[0044] Operation point: This refers to the coordinate information in the transaction change log that identifies a specific data change operation (or the end position of the transaction), usually consisting of the log file name and the offset within the file. This information is used to enable the breakpoint resume function of incremental synchronization, that is, when the synchronization task is interrupted, it can continue from the last recorded operation point without having to start from the beginning.

[0045] Discrepancy data refers to specific data records in the same table of the source and target databases that are found to have inconsistent content during the consistency verification phase after data migration. Locating discrepancy data is a prerequisite for data repair and ensuring eventual consistency.

[0046] This invention can be implemented in general computing environments. Its hardware includes one or more standard servers acting as control nodes, used for parsing, rule matching, and task scheduling. The source and target databases are deployed on separate servers, with the target database server possessing performance no less than that of the source, particularly high I / O throughput (e.g., using SSDs) to handle the pressure of importing full data. These nodes need to be interconnected via a high-speed, stable internal network to ensure efficient data transfer during migration. Furthermore, this solution is also applicable to virtualization and cloud platform environments, requiring no specific proprietary hardware, demonstrating excellent infrastructure compatibility and scalability.

[0047] Figure 1 This is one of the flowcharts illustrating the heterogeneous database migration method provided by this invention, such as... Figure 1 As shown, the method includes the following: Step 101: Obtain the object definition metadata and related application system business logic code from the source database.

[0048] In this embodiment of the invention, the executing entity can be a software system. This software system is typically deployed on one or more servers (control nodes) and interacts with the source database, target database, and application code repository through programming, automating the entire process from analysis and modification to migration and verification.

[0049] Furthermore, the application system refers to specific business software that depends on the source database to run and needs to be switched to the target database through this migration. In the migration process of this invention, this application system is the object to be adapted and switched.

[0050] In practice, step 101 involves two parallel information acquisition streams: Obtaining object definition metadata from the source database: The migration system establishes a read-only connection to the source database and systematically extracts structured metadata by querying its system information architecture view. This includes, but is not limited to: the names and definitions of all tables and views, column data types and constraints (primary key, NOT NULL, default value, etc.), and the composition and type of indexes. For programmatic objects such as stored procedures, functions, and triggers, their complete creation scripts are obtained by querying the corresponding system directory tables or views. This step aims to fully capture the static structural skeleton of the source database.

[0051] Obtaining the business logic code of related application systems: The migration system scans and parses the source code repository or deployment directory of the application systems. Its core objective is to locate and extract all files containing database interaction logic. This typically includes: mapping configuration files used by object-relational mapping frameworks (which define static SQL statements), code files in the application source code that embed SQL strings or call database interfaces, and configuration items in the application configuration files related to database connections (such as connection strings, connection pool parameters, and ORM dialects). This step aims to comprehensively collect the application-level database operation logic and runtime configurations.

[0052] By collecting these two types of key information simultaneously, the system lays a complete and reliable data foundation for subsequent automated compatibility analysis, ensuring that migration assessment can simultaneously cover the underlying database structure and upper-level application behavior.

[0053] Step 102: Perform syntax structure parsing on the business logic code, and in conjunction with the object definition metadata, identify the syntax incompatibilities and structural differences between the source database and the target database.

[0054] The system first performs a deep analysis of the acquired business logic code. For static SQL statements in the code (such as queries explicitly defined in the mapping file), the system uses a built-in syntax parser to convert them into an abstract syntax tree structure. This process can break down the various components of the SQL statement, including function calls, operation keywords, subquery structures, and conditional expressions. For SQL statements dynamically generated at application runtime, the system samples and captures them by deploying probes in the test environment and performs the same syntax tree construction on them to ensure coverage of all potential code execution paths.

[0055] Based on this, the system systematically compares the parsed syntax elements with the known syntax rules and supported function sets of the target database. For example, it identifies whether specific pagination functions, string processing functions, or system variables used in the source database have equivalent support in the target database or require conversion. Simultaneously, the system maps and verifies object definition metadata (such as field data types and constraint definitions) with the data types and constraint mechanisms supported by the target database, identifying structural definitions that need adjustment or conversion, such as differences in the implementation of auto-incrementing primary keys or index type mismatches.

[0056] Through the above analysis and comparison process, the system automatically outputs a structured difference report. This report clearly lists all identified syntax incompatibilities and structural differences, and usually includes their code location, specific difference description, and preliminary risk level assessment, providing input for subsequent targeted rewriting.

[0057] Step 103: Based on the preset difference adaptation rule base, match the rewriting strategy corresponding to the grammar incompatibility item and the structural difference item.

[0058] The migration system compares each of the syntax incompatibilities and structural differences against a pre-defined rule base for difference adaptation. This rule base is a predefined and continuously maintained set of rules, where each rule is explicitly associated with a specific difference pattern and specifies a standardized procedure for converting it into a form compatible with the target database.

[0059] The system searches and matches within the rule base based on the specific type and characteristics of the differences. For each identified incompatible function or structural difference, the system can locate the corresponding processing rule from the rule base, thus determining a clear and executable rewriting strategy for each difference. This rewriting strategy is essentially a set of specific instructions guiding the system on how to perform automatic conversion.

[0060] Through this step, the system transforms the previously identified problems into a set of operational solutions that can be directly executed in subsequent stages, providing an action guide for the automated transformation of the entire migration process.

[0061] Step 104: According to the rewriting strategy, convert the object definition metadata into a target structure definition adapted to the target database, and refactor the business logic code into a target execution statement adapted to the target database.

[0062] The migration system first defines metadata for objects, applies a matching rewriting strategy, and generates structure creation statements that can be directly executed in the target database. For example, the system automatically converts table definitions in the source database into complete table creation scripts that include target database-specific data types, constraints, and equivalent objects (such as using sequences to replace auto-incrementing attributes) based on the strategy.

[0063] Simultaneously, the system refactors the business logic code. Based on the rewriting strategy corresponding to each line of code, it precisely replaces and adjusts the structured query statements or code snippets. For example, it replaces function calls specific to the source database with equivalent functions supported by the target database, or adjusts the syntax structure of pagination queries. The refactoring process ensures that the generated target execution statements are semantically consistent with the original logic and that the syntax is fully adapted to the target database.

[0064] Through this step, the system achieves standardized and batch conversion from the source database system to the target database system at both the structural definition and business logic levels, preparing for the subsequent construction of a runnable target environment.

[0065] Step 105: Construct a target database environment based on the target structure definition, and configure the target execution statement in the target database environment or its associated business interface to complete the database migration and adaptation.

[0066] After completing all transformations and refactoring, the migration system first connects to the target database server. The system sequentially executes the target structure definition, thereby creating corresponding data tables, indexes, constraints, and other database objects one by one in the target database, constructing a target database environment that is logically equivalent to and syntactically compatible with the source database.

[0067] Next, the system performs application-layer adaptation configuration. It updates the reconstructed target execution statements to the corresponding configuration files or source code locations in the application system, for example, replacing SQL statements in the original object-relational mapping configuration file. At the same time, the system guides or automatically modifies the application system's connection configuration to point it to the newly built target database environment, and adjusts the necessary connection parameters and driver settings to ensure that the application can correctly recognize and connect to the new database.

[0068] Through this step, the system completes the end-to-end switch from database structure to application connection, enabling the entire application system to run on a completely new target database environment, thereby achieving smooth database migration and full adaptation.

[0069] The heterogeneous database migration method provided in this invention, by parsing the syntax structure of business logic code and combining it with object definition metadata, can deeply identify hidden syntax incompatibilities and structural differences between the source and target databases. This overcomes the shortcomings of existing technologies that cannot accurately locate database dialects and underlying object definition differences through rule-based methods. Furthermore, by using a preset difference adaptation rule base to automatically match and rewrite strategies, static metadata and dynamic business code are reconstructed into target structure definitions and target execution statements adapted to the target database, ensuring that the migrated data storage model and business query logic conform to the specifications of the target database, guaranteeing the correctness of business logic execution and the consistency of data storage. Finally, by constructing a target database environment based on the target structure definition and configuring the target execution statements in this environment or related business interfaces, it ensures that the migrated business logic can be correctly executed on the target database, avoiding the uncertainty and omissions caused by a large amount of manual code correction, thereby significantly reducing migration risks and improving the operational stability of the system in a heterogeneous database environment.

[0070] Furthermore, step 102, parsing the syntax structure of the business logic code, is a crucial step in achieving deep compatibility testing. This process primarily addresses the differences between two types of code: For statically structured query statements explicitly written in the application system, such as complete SQL statements directly defined in the mapping configuration file, the system uses a syntax parser for processing. This parser can decompose a complete SQL statement into multiple structured components and generate a corresponding tree structure representation. In this tree structure, each node corresponds to a specific element in the statement, such as a function call, operation keyword, query condition clause, table join expression, or sorting / grouping statement. This decomposition allows the system to identify each syntactic element used in the statement in a structured manner.

[0071] For query statements dynamically generated in the application system through conditional statements, loop concatenation, etc., since their final form cannot be directly obtained during static code analysis, the system employs a runtime sampling method. Specifically, during the pre-migration specialized testing phase, the system embeds monitoring points in the call chain between the application and the database to capture the complete query statements actually sent to the database during testing. Subsequently, the system also sends these captured query statements to a syntax parser for processing, converting them into a structured grammatical representation, thereby covering the database interaction behaviors hidden behind the business logic.

[0072] By combining the two methods described above, the system achieves a comprehensive and structured parsing of all potential database operation statements in the business logic code, laying the foundation for accurate identification of syntax incompatibilities in the future.

[0073] Furthermore, in the specific implementation process, identifying grammatical incompatibilities and structural differences is the foundation for subsequent accurate adaptation. This process systematically combines object definition metadata with the parsed grammatical structure, analyzing from two levels: At the structural level, the system extracts detailed information from the object definition metadata, including the specific data type of each field in the table, the defined index type and its attributes, and various constraints. The system then compares these extracted structural features against the type mapping rules and feature support list pre-configured for the target database. For example, it matches and validates a numeric type in the source database against types supported by the target database, or determines whether a specific index type used in the source database is natively supported by the target database. Through this comparison, the system can clearly identify field types that need adjustment, indexes that cannot be directly converted, and constraints that need to be redefined; these are identified as structural differences.

[0074] At the grammatical level, the system traverses and analyzes the parsed syntax tree nodes and dynamic syntax structures. It extracts all used function names, database-reserved keywords, and specific query clause structures. Then, it matches these extracted grammatical elements against the target database's built-in syntax rule base. This rule base defines all legal functions, keywords, and grammatical forms supported by the target database. Through matching, the system can filter out elements that are absent from or inconsistent with the target database's syntax rule base; these are identified as grammatically incompatible items.

[0075] Through the above dual analysis of structure and syntax, the system is able to accurately locate all the differences that need to be adapted and modified, providing a clear input list for subsequent automatic rewriting by calling the corresponding rules.

[0076] Furthermore, once the system completes the difference identification and confirms the existence of a structural difference item—an auto-incrementing column attribute—it automatically triggers the corresponding transformation process. Based on the matched combination rewrite strategy, the system executes a multi-step automated operation to build a functionally equivalent mechanism in the target database.

[0077] First, the system automatically generates definition statements for creating sequence objects based on the syntax rules of the target database. This sequence will serve as a provider of unique numeric sequences within the target environment.

[0078] Next, the system retrieves the current maximum value of the auto-incrementing column from the source database via a query interface. This is a critical data point used to ensure the continuity of the primary key value. Based on this maximum value, the system generates a dedicated sequence synchronization statement to set the starting value of the newly created sequence object to the appropriate value in the target database.

[0079] The system then generates the definition statement for creating the trigger. This trigger is designed to execute automatically before a data insertion operation occurs. Its core logic is to retrieve the next value from the above sequence and assign it to the corresponding column in the target table.

[0080] Finally, the system combines the three types of statements generated in the above steps—the definition statement for creating sequence objects, the sequence synchronization statement, and the statement for creating pre-insert triggers—in logical order to form a complete and independently executable target structure definition script. This script can fully reproduce the auto-incrementing behavior originating from insert columns in the target database without requiring manual conversion code.

[0081] Furthermore, in the specific implementation process, step 105, which involves constructing the target database environment based on the target structure definition, is a systematic process that includes structure preparation, data migration, and final optimization.

[0082] First, the system connects to the target database instance and executes the target structure definition script sequentially to complete the creation of the basic table structure. To maximize performance during the subsequent data import phase, the system temporarily disables non-primary key indexes in the newly created tables and removes foreign key constraints at this time to eliminate the performance overhead they cause during batch writes.

[0083] Subsequently, the system enters the full data migration phase. For each data table that needs to be migrated, the system logically divides it into multiple contiguous data shards based on the distribution range of its primary key values. By enabling a multi-threaded parallel processing mechanism, each thread is responsible for efficiently extracting one data shard from the source database and importing it into the corresponding table in the target database in batch insert mode, thereby significantly shortening the migration time for large-scale data.

[0084] Considering that the source database may continue to serve and generate new data changes during the full migration, the system immediately starts incremental synchronization after the full import is completed. By continuously parsing the transaction change log of the source database, the system captures all data insertion, update, and deletion events since the start of the full migration and replays these events to the target database according to transaction integrity, ensuring eventual consistency between the two databases.

[0085] Finally, after all data synchronization is complete, the system recreates the previously disabled or removed non-primary key indexes and foreign key constraints on the target database, bringing the database environment into an optimal runtime state, thus marking the completion of the target database environment construction.

[0086] The core of the incremental synchronization phase is to ensure that data change events are accurately and without duplication applied to the target database. This is achieved through a mechanism that includes state tracking and idempotency checks.

[0087] The system first performs in-depth analysis on the transaction change logs captured from the source database, extracting two key metadata: one is a global transaction identifier used to uniquely identify a complete database transaction, and the other is the operation position used to mark the precise location of the event in the log stream.

[0088] To achieve idempotency control, a pre-designed synchronization log table exists in the target database. Its core field records the identifiers of successfully replayed transactions. Before replaying a new data change event to the target database, the system queries this synchronization log table to verify whether the global transaction identifier carried by the current event has been recorded.

[0089] The judgment logic is as follows: If the query result shows that the transaction identifier already exists, it means that this change event has been successfully applied, and the system will automatically skip this replay to avoid duplicate data execution. If it does not exist, the system will safely execute the data operation (such as insert, update, or delete) defined by the data change event. After the event is successfully executed, the system will insert the global transaction identifier of the event and the associated operation position as a new entry into the synchronization log table to mark that the transaction has been synchronized.

[0090] Through the closed-loop process of "parsing-querying-judging-execution-recording" described above, the incremental synchronization process has the ability to resume transmission from breakpoints and the idempotency of transactions, thereby ensuring that the data can maintain eventual consistency even after the synchronization is interrupted and resumed.

[0091] In the specific implementation process, step 105, configuring the target execution statement in the target database environment or its associated business interface, is a crucial step in ensuring that the application system can seamlessly switch to the new database. This process mainly focuses on the centralized adaptation of two core configuration parts of the application system.

[0092] First, the system executes synchronously updates the object-relational mapping (ORM) configuration file of the application system. Specifically, the system batches and accurately replaces the reconstructed target execution statements adapted to the target database syntax from step 104 back into the original configuration files (such as MyBatis' Mapper XML files). This ensures that every data query or operation command initiated by the application at runtime conforms to the syntax of the target database.

[0093] Secondly, the database connection configuration, which serves as the core bridge between the application system and the database, needs to be adapted. This involves modifying the application's core configuration file (such as application.yml in Spring Boot). The system performs two key changes during this process: first, it replaces the database driver class name in the connection configuration with a proprietary driver version provided by the target database vendor; second, it explicitly adjusts the transaction isolation level parameter to match the target database's default isolation level (e.g., read committed) to avoid inconsistencies in behavior due to semantic differences. By updating the connection string, driver name, and key parameters, the application is redirected to the newly built target database environment, thus completing the entire migration and adaptation process.

[0094] After completing all migration and adaptation operations, the system performs a final consistency check to ensure data integrity and accuracy. In practice, the system first logically segments the data tables to be compared according to their primary key order. Based on a preset segment size (e.g., every 10,000 rows), the system divides the entire table into multiple consecutive, non-repeating logical data segments.

[0095] For each logical segment, the system performs a computational task on both the source and target databases: concatenating the values ​​of all data rows within the segment into a unified string according to a predefined column order, and then calculating a unique hash value for this string. This hash value serves as the digital fingerprint of the entire data content of that segment.

[0096] The system then compares the hash values ​​of the corresponding logical segments on the source and target ends. If the hash values ​​calculated by both ends are completely identical, the data segment is determined to be completely identical, and no further action is required. If the hash values ​​are inconsistent, the system automatically marks this logical segment as a "difference segment".

[0097] For all data marked as "difference segments," the system will initiate a detailed row-by-row comparison process. By precisely comparing the values ​​of each field in the corresponding row, the system can locate the specific difference data row and the difference field, and generate a detailed difference report. This hierarchical verification method of "first quickly segmenting and hashing for screening, and then precisely locating the difference segments" significantly improves the comparison efficiency for large datasets while ensuring verification reliability.

[0098] The following example illustrates the implementation process of this invention using a company's "supplier collaboration platform" as an example of its migration from a MySQL 8.0 database to a domestic Kingbase ES V8 database (running in MySQL compatibility mode).

[0099] This platform is a core business system developed in Java, using the Spring Boot framework and MyBatis as the persistence layer. The original production database was MySQL 8.0, containing hundreds of business tables, with the supplier master table (t_supplier) being the key data object. To meet the requirements of information technology application innovation, the entire system needs to be migrated to the domestic Kingbase database, with the migration process required to be seamless for business operations, with zero data loss and no performance degradation.

[0100] The implementation process includes: (1) Information collection.

[0101] The migration system (deployed on a dedicated migration server) connects to the source MySQL database via JDBC. The system automatically queries the MySQL INFORMATION_SCHEMA system view to collect complete object definition metadata of the vendor's master table, including its fields, primary keys, indexes, and stored procedures.

[0102] At the same time, the system extracts all relevant business logic code from the platform's Git code repository, with a focus on: MyBatis Mapper XML file.

[0103] Java DAO layer code using annotations such as @Select and @Update.

[0104] Database initialization script.

[0105] (2) Automated difference recognition.

[0106] The migration system activates its built-in SQL syntax parser to parse the static SQL in the collected Mapper files and generate an Abstract Syntax Tree (AST). By traversing the AST, the system accurately extracts elements such as function calls (e.g., DATE_FORMAT()) and pagination clauses (LIMIT ?, ?) from the SQL.

[0107] At the same time, the system will compare the extracted metadata (such as field type TINYINT) and syntax elements with the pre-built Renmin University Kingbase V8 compatibility knowledge base.

[0108] The recognition results are as follows: Structural differences: The AUTO_INCREMENT attribute defined in the id field of the t_supplier table is not supported in the target library.

[0109] Syntax incompatibility: The LIMIT ?, ? pagination syntax used in SQL needs to be rewritten as LIMIT ?OFFSET ? in the target database.

[0110] The DATE_FORMAT(create_time, '%Y-%m-%d') function has no direct equivalent in the target library.

[0111] The system generates a detailed difference analysis report, listing all the points that need to be modified and their locations.

[0112] (3) Rule matching and code rewriting.

[0113] Based on the difference report, the migration system calls its core rule engine to match the corresponding rewriting strategy from the difference adaptation rule library.

[0114] For AUTO_INCREMENT, match the "sequence + trigger" strategy.

[0115] For LIMIT syntax, match the "syntax rewriting" strategy.

[0116] For the DATE_FORMAT function, match the "function conversion (to TO_CHAR)" strategy.

[0117] Subsequently, the system performs a fully automated rewrite based on the strategy: Generate target structure definition: The system outputs an SQL script that includes creating the t_supplier table (without auto-increment attribute), creating the sequence seq_t_supplier_id, and creating a BEFORE INSERT trigger to automatically retrieve values ​​from the sequence during insertion.

[0118] Generate the target execution statement: The system automatically rewrites `SELECT … LIMIT ?, ?` in the original Mapper file to `SELECT … LIMIT ? OFFSET ?`; and rewrites `DATE_FORMAT` to `TO_CHAR`. The rewritten code is saved in a new branch.

[0119] (4) Data migration and synchronization.

[0120] In the target Kingbase database, the system-generated target structure definition script was executed, successfully creating the table structure and associated objects. During creation, non-primary key indexes were temporarily removed to improve import speed.

[0121] The migration system divides the t_supplier table into multiple data shards based on the primary key id, starts multiple migration worker threads to extract data from MySQL in parallel, and imports it into the target database at high speed through the JDBC batch insert interface.

[0122] During the full migration, the system enables an incremental capture tool based on Binlog logs to read MySQL's binary logs in real time and parse changes into data change events by transaction. Before applying these events to the target database, the system checks whether the same Global Transaction Identifier (GTID) exists in the synchronization log table to ensure idempotency and achieve real-time data synchronization.

[0123] After data synchronization is complete, rebuild all non-primary key indexes and foreign key constraints in the target database.

[0124] (5) Application adaptation and verification.

[0125] Deploy the new version of the Mapper file, which contains the target execution statements, to the application. Modify the application's application.yml configuration file and adjust the connection URL.

[0126] The migration system performs a final check on the t_supplier table. The system sorts all data in the table by ID and divides it into multiple logical segments, calculating the hash value of each segment in both the source and target databases in parallel. The comparison results show that all segment hash values ​​are consistent, confirming no data discrepancies.

[0127] Using the method described in this invention, the platform completed the switchover of its core database within a predetermined downtime window (2 hours). After the switchover, the application system ran smoothly, all query, pagination, and reporting functions functioned normally, and business verification was successful. Compared to traditional migration methods involving manual evaluation, manual rewriting, and long downtime, this method minimizes migration risks, improves efficiency by over 70%, and achieves a truly smooth migration.

[0128] The effects that the method of this invention can achieve are as follows: 1) This application utilizes Abstract Syntax Tree (AST) technology combined with object definition metadata to deeply identify hidden syntactic and structural differences between heterogeneous databases at the code logic level. Compared to traditional manual checks or simple regular expression replacements, this significantly improves the accuracy of difference identification. Simultaneously, the rule-based automated rewriting mechanism enables batch and standardized repair of everything from table structures and auto-incrementing primary keys to complex SQL statements, significantly reducing manual input costs during migration and the risk of code errors due to human oversight.

[0129] 2) By converting metadata into a structure definition compatible with the target database (e.g., converting auto-incrementing columns to sequences and triggers) and refactoring business code into target execution statements, this application achieves end-to-end adaptation from the underlying storage model to the upper-layer application logic. This effectively solves the business function anomalies caused by differences in database dialects (e.g., pagination syntax, function incompatibility), ensuring that the migrated application system can completely and correctly execute the original business logic.

[0130] 3) This embodiment of the invention employs a migration strategy combining full import and incremental log synchronization, along with an idempotent processing mechanism, enabling data switching to be completed without interrupting or with minimal business interruption. Simultaneously, by reconstructing indexes and configuring adapted database drivers and transaction parameters after migration, the performance and stability of the target database environment are ensured, meeting the stringent requirements of core business systems for continuity and high availability.

[0131] 4) This embodiment of the invention introduces a segmented hash verification mechanism, which greatly improves the efficiency of data consistency verification between heterogeneous databases compared to full row-by-row comparison. This mechanism can quickly locate the differing data segments and perform detailed checks only on the differing parts, thereby significantly shortening the verification window period after migration while ensuring zero data loss and zero errors.

[0132] The heterogeneous database migration apparatus provided in the embodiments of the present invention is described below. The heterogeneous database migration apparatus described below can be referred to in correspondence with the heterogeneous database migration method described above.

[0133] This invention provides a heterogeneous database migration device, see [link to related document]. Figure 2 ,include: Module 210 is used to obtain object definition metadata and business logic code of associated application systems from the source database. The parsing module 220 is used to parse the syntax structure of the business logic code and, in conjunction with the object definition metadata, identify the syntax incompatibilities and structural differences between the source database and the target database. Matching module 230 is used to match rewriting strategies corresponding to the grammar incompatible items and structural difference items based on a preset difference adaptation rule base; The refactoring module 240 is used to convert the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and to refactor the business logic code into a target execution statement adapted to the target database. The migration module 250 is used to construct a target database environment based on the target structure definition, and configure the target execution statement in the target database environment or its associated business interface to complete the migration and adaptation of the database.

[0134] Figure 3 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 3 As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, communications interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a heterogeneous database migration method, including: obtaining object definition metadata of the source database and business logic code of the associated application system; parsing the syntax structure of the business logic code and, in conjunction with the object definition metadata, identifying syntax incompatibilities and structural differences between the source and target databases; matching rewriting strategies corresponding to the syntax incompatibilities and structural differences based on a preset difference adaptation rule base; converting the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and reconstructing the business logic code into target execution statements adapted to the target database; constructing a target database environment based on the target structure definition, and configuring the target execution statements in the target database environment or its associated business interface to complete the database migration and adaptation.

[0135] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the heterogeneous database migration method provided by the above methods, including: obtaining object definition metadata of the source database and business logic code of the associated application system; parsing the syntax structure of the business logic code and, in conjunction with the object definition metadata, identifying syntax incompatibilities and structural differences between the source database and the target database; matching rewriting strategies corresponding to the syntax incompatibilities and structural differences based on a preset difference adaptation rule base; converting the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and reconstructing the business logic code into a target execution statement adapted to the target database; constructing a target database environment based on the target structure definition, and configuring the target execution statement in the target database environment or its associated business interface to complete the database migration and adaptation.

[0137] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the heterogeneous database migration method provided by the above methods, including: obtaining object definition metadata of the source database and business logic code of the associated application system; parsing the syntax structure of the business logic code and, in conjunction with the object definition metadata, identifying syntax incompatibilities and structural differences between the source database and the target database; matching rewriting strategies corresponding to the syntax incompatibilities and structural differences based on a preset difference adaptation rule base; converting the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and reconstructing the business logic code into a target execution statement adapted to the target database; constructing a target database environment based on the target structure definition, and configuring the target execution statement in the target database environment or its associated business interface to complete the database migration and adaptation.

[0138] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0140] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for migrating heterogeneous databases, characterized in that, include: Obtain the object definition metadata from the source database and the business logic code of the associated application system; The business logic code is parsed using syntax structure analysis, and combined with the object definition metadata, the syntax incompatibilities and structural differences between the source database and the target database are identified. Based on a preset difference adaptation rule base, a rewriting strategy is matched with the grammar incompatibility items and structural difference items; According to the rewriting strategy, the object definition metadata is converted into a target structure definition adapted to the target database, and the business logic code is refactored into a target execution statement adapted to the target database. Based on the target structure definition, a target database environment is constructed, and the target execution statement is configured in the target database environment or its associated business interface to complete the database migration and adaptation.

2. The heterogeneous database migration method according to claim 1, characterized in that, The parsing of the business logic code includes: The static structured query statements in the business logic code are decomposed to generate syntax tree nodes containing function calls, keywords, and syntax clauses; The dynamic query statements in the business logic code are sampled before execution to obtain the actual query statements generated at runtime, and the actual query statements are parsed into dynamic syntax structures.

3. The heterogeneous database migration method according to claim 2, characterized in that, The step of combining the object definition metadata to identify syntax incompatibilities and structural differences between the source and target databases includes: Extract the field types, index types, and constraint attributes from the object definition metadata, and compare them with the preset mapping rules and support list of the target database to identify field type mismatches, unsupported index types, and incompatible constraint attributes in the source database, which are then used as the structural difference items. The syntax tree nodes and dynamic syntax structure are traversed to extract the function identifiers, reserved keywords, and query logic clauses contained therein. These are then matched against the syntax rule base of the target database. Function identifiers, reserved keywords, and query logic clauses that are not supported by the target database are selected as the syntax incompatibilities.

4. The heterogeneous database migration method according to claim 1, characterized in that, When the identified structural difference item is an auto-incrementing column attribute in the source database table structure, the matching rewriting strategy is a combination strategy of mapping the auto-incrementing attribute to a sequence object and a trigger object. The step of converting the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy includes: Execute the aforementioned combination strategy to generate definition statements that create sequence objects in the target database; Get the current maximum value of the auto-incrementing column in the source database, and generate a sequence synchronization statement that sets the starting value of the sequence object based on the current maximum value; Generate a definition statement to create a pre-insert trigger in the target database, wherein the pre-insert trigger is configured to retrieve a value from the sequence object and assign it to the target column during a data insertion operation; The definition statement for creating the sequence object, the sequence synchronization statement, and the definition statement for creating the pre-insertion trigger are combined into the target structure definition.

5. The heterogeneous database migration method according to claim 1, characterized in that, The construction of the target database environment based on the target structure definition specifically includes: Connect to the target database instance, execute the target structure definition to establish the data table structure, and temporarily disable non-primary key indexes and foreign key constraints in the table structure; After establishing the data table structure, data migration is performed. The data tables of the source database are divided into multiple data shards according to the primary key range, and the data shards are fully imported into the target database environment using a multi-threaded parallel approach. After the full import is completed, based on the transaction change log of the source database, data change events generated during the full import are captured, and the data change events are replayed to the target database environment to achieve incremental synchronization. After the data migration is completed, the non-primary key indexes and foreign key constraints are rebuilt to complete the construction of the target database environment.

6. The heterogeneous database migration method according to claim 5, characterized in that, The step of replaying the data change event to the target database environment to achieve incremental synchronization includes: Parse the global transaction identifier and operation location in the transaction change log; Before playback, query the synchronization log table in the target database to determine whether the global transaction identifier for the current data change event already exists; If it does not exist, execute the data change event and write the corresponding global transaction identifier into the synchronization log table to achieve incremental synchronization.

7. The heterogeneous database migration method according to claim 1, characterized in that, The business logic code includes the application system's object-relational mapping configuration file and the database connection configuration containing transaction isolation level parameters; The step of configuring the target execution statement in the target database environment or its associated business interface includes: Update the target execution statement to the object-relational mapping configuration file; The database connection configuration serving as the business interface is adapted by replacing the application system's database driver with a driver version compatible with the target database, and adjusting the transaction isolation level parameter to match the default level of the target database.

8. The heterogeneous database migration method according to any one of claims 1-7, characterized in that, After completing the database migration and adaptation, the following is also included: Sort the corresponding data tables in the source database and target database according to their primary keys and divide them into several logical segments; Calculate the concatenated hash value of the data in each logical segment of the source database and the target database respectively; If the concatenated hash values ​​at both ends are inconsistent, the logical segment is marked as a difference segment, and the data within the difference segment is compared line by line to locate the specific difference data.

9. A heterogeneous database migration device, characterized in that, include: The acquisition module is used to acquire object definition metadata from the source database and business logic code from the associated application system. The parsing module is used to parse the syntax structure of the business logic code and, in conjunction with the object definition metadata, identify the syntax incompatibilities and structural differences between the source database and the target database. The matching module is used to match rewriting strategies corresponding to the grammar incompatibility items and structural difference items based on a preset difference adaptation rule base; The refactoring module is used to convert the object definition metadata into a target structure definition adapted to the target database according to the rewriting strategy, and to refactor the business logic code into a target execution statement adapted to the target database. The migration module is used to construct a target database environment based on the target structure definition, and configure the target execution statement in the target database environment or its associated business interface to complete the migration and adaptation of the database.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the heterogeneous database migration method as described in any one of claims 1 to 8.

Images