A seamless migration method and system for SAAS system tenant data and a storage medium

Abstract

The application provides a SAAS system tenant data seamless migration method, system and storage medium, the method comprises the following steps: obtaining structure information and foreign key association information, generating a structured data structure based on the structure information and the foreign key association information; obtaining the foreign key association relationship based on the structured data structure and constructing a data table dependency chain, verifying the dependency chain and the source tenant data, and obtaining the effective dependency chain; based on the effective dependency chain, the data volume of each business data table is counted, the placeholder record is inserted according to the data volume to reserve the primary key interval, the occupation state of the primary key interval is verified to obtain the available primary key interval; based on the available primary key interval, the intermediate data carrying medium is built, and the comparison relationship table of the source primary key and the target primary key is generated; based on the effective dependency chain, the structured data structure and the comparison relationship table, the data migration processing is performed on the source tenant data to replace the primary key and the foreign key field of the data according to the comparison relationship table. The application can efficiently and accurately complete the data migration work.

Description

Technical Field

[0001] This application relates to the field of SaaS system data processing technology, and in particular to a method, system and storage medium for seamless migration of tenant data in a SaaS system. Background Technology

[0002] The need for tenant data migration between SaaS systems is increasing, such as in scenarios like data integration after mergers and acquisitions or system version upgrades. Existing technologies typically employ general-purpose data migration tools or database backup and recovery methods: general-purpose tools directly read source data and write it in batches to the target system, while backup and recovery involves exporting and then importing all tenant data. However, when migrating between systems with the same data structure but different tenant architectures, the use of auto-incrementing primary keys in most systems makes direct data copying in existing solutions prone to primary key conflicts, leading to data overwriting or insertion failures. Furthermore, these solutions fail to effectively manage foreign key dependencies between tables, often resulting in invalid foreign key associations and data logic errors after migration. In addition, the migration process often involves locking the target table or executing numerous complex queries, severely consuming system resources and interfering with the normal business operations of the target SaaS system. Therefore, current methods cannot efficiently and accurately complete tenant data migration for SaaS systems. Summary of the Invention

[0003] To efficiently and accurately complete the migration of tenant data in a SaaS system, this application provides a method, system, and storage medium for seamless migration of tenant data in a SaaS system.

[0004] Firstly, a seamless migration method for tenant data in a SaaS system is provided, including: Obtain the structure information and foreign key association information of the business data table corresponding to the tenant to be migrated in the source SaaS system, and generate a structured data structure based on the structure information and foreign key association information; Based on the structured data structure, foreign key relationships are extracted and a data table dependency chain is constructed. The logical validity of the dependency chain and the source tenant data is verified, and a valid dependency chain that passes the verification is obtained. Based on the data volume of each business data table corresponding to the source tenant of the effective dependency relationship chain, placeholder records are inserted into the corresponding business data table of the target SAAS system to reserve the primary key range according to the data volume, and the occupancy status of the primary key range is verified to obtain the available primary key range. Based on the available primary key range, an intermediate data carrying medium is constructed and a table of correspondence between the source primary key and the target primary key is generated; Based on the effective dependency chain, the structured data structure, and the mapping table, data migration processing is performed on the source tenant data to synchronously replace the primary key and foreign key fields of the data according to the mapping table during the migration process.

[0005] In some embodiments, generating a structured data structure based on the structural information and foreign key association information includes: Obtain the table name of the business data table corresponding to the tenant to be migrated in the source SaaS system; Based on the table name, extract the table comments and primary key fields of the business data table from the structure information; Based on the table name, extract at least one foreign key field of the business data table, the name of the parent table associated with each foreign key field, and the primary key field of the parent table from the foreign key association information; Based on the table name, extract all columns and fields of the business data table except for the primary key and foreign key, as well as the comments of each column and field, from the structure information; Based on the table name, the table comments, the primary key field, the at least one foreign key field, the parent table name, the parent table's primary key field, all column fields, and comments for each column field, a structured data structure containing a root node, a foreign key node, and column nodes is generated. The structured data structure is any one of an XML structure, a JSON structure, or a database structure, and is used to carry the structural information and foreign key association information of the business data table.

[0006] In some embodiments, the step of parsing and extracting foreign key relationships based on the structured data structure and constructing a data table dependency chain includes: Traverse and parse the foreign key nodes in each structured data structure, extract the parent table name associated with each foreign key node, and obtain a one-way dependency relationship with the current business data table as the child table and the parent table name as the parent table; Aggregate all unidirectional dependencies to construct a data table dependency chain representing the migration order between various business data tables in the source SaaS system, wherein the migration order specifies that the parent table migrates before the child table.

[0007] In some embodiments, verifying the logical validity of the dependency chain and the source tenant data and obtaining a valid dependency chain that has passed the verification includes: Traverse the structured data structures corresponding to each one-way dependency in the data table dependency chain, and verify the existence and data type consistency of the parent table name and parent table primary key field recorded in each structured data structure in the source database. After removing the one-way dependencies that fail the verification, a quasi-valid dependency chain is obtained. Traverse the structured data structure corresponding to each sub-table in the quasi-effective dependency relationship chain, extract the foreign key fields of the sub-tables, and perform a join query on the corresponding parent table through the foreign key fields. Sub-table foreign key data that can be found in the corresponding parent table records are judged as logically normal data, and sub-table foreign key data that cannot be found in the corresponding parent table records are judged as logically abnormal data and a pause migration prompt is triggered. Aggregate all logically normal data corresponding to one-way dependencies to generate a valid dependency chain that has passed verification.

[0008] In some embodiments, inserting placeholder records in the corresponding business data table of the target SaaS system to reserve a primary key range based on the data volume includes: Obtain the current maximum primary key value of the business data table corresponding to the target SaaS system, and calculate a placeholder primary key value based on the current maximum primary key value, the data volume, and the preset primary key redundancy. Based on the placeholder primary key value and the predefined tenant identifier special mark, a placeholder record is constructed and inserted into the business data table corresponding to the target SaaS system, so as to reserve a primary key range between the current maximum primary key value and the placeholder primary key value in the business data table.

[0009] In some embodiments, verifying the occupancy status of the primary key range to obtain the available primary key range includes: In the business data table corresponding to the target SaaS system, query existing records whose primary key values ​​are within the reserved range defined by the current maximum primary key value and the placeholder primary key value; When the existing record is found, the placeholder primary key value is incremented based on the number of existing records to obtain a new placeholder primary key value. The placeholder record is then reconstructed and inserted based on the new placeholder primary key value to re-execute the query and increment correction until the existing record is no longer found. The interval defined by the current maximum primary key value and the latest placeholder primary key value when no existing record can be found is determined as the available primary key interval.

[0010] In some embodiments, the data migration process performed on the source tenant data based on the effective dependency chain, structured data structure, and mapping table, to synchronously replace the primary key and foreign key fields of the data according to the mapping table during the migration process, includes: The migration order of each data table is determined based on the effective dependency chain. Based on the migration order, multiple data tables with no dependencies are selected as parallel migration groups. Based on the amount of data to be migrated in each data table in the parallel migration group, the corresponding batch insertion threshold is dynamically determined, and the source tenant data is divided into several data batches according to the batch insertion threshold. When the migration of the current data table begins, insert a migration flag record carrying the migration identifier into the data table; Based on the structured data structure, an insertion statement template is constructed for each data batch to be migrated, wherein the insertion statement template contains source primary key and source foreign key fields in the form of placeholders; Based on the reference relationship table, query the target primary key corresponding to the source primary key and the target primary key of the parent table corresponding to the source foreign key field value, and synchronously replace the corresponding placeholder in the insert statement template with the query results to generate the target insert statement; The target insert statement is executed in parallel according to the batch insert threshold to write the data batch to the target SaaS system.

[0011] In some embodiments, the method further includes: after the data migration is completed, deleting all placeholder records in the target SaaS system based on placeholder record identifiers.

[0012] Secondly, a seamless migration system for tenant data in a SaaS system is provided, the system comprising: The table structure sorting module is used to obtain the structure information and foreign key association information of the business data table corresponding to the tenant to be migrated in the source SaaS system, and generate a structured data structure based on the structure information and foreign key association information. The dependency generation module is used to parse and extract foreign key relationships based on the structured data structure and construct a data table dependency chain; The logical verification module is used to verify the logical validity of the dependency relationship chain and the source tenant data and obtain the valid dependency relationship chain that has passed the verification. The data volume statistics module is used to count the data volume of each business data table corresponding to the source tenant based on the effective dependency relationship chain; The primary key range reservation module is used to insert placeholder records in the corresponding business data table of the target SaaS system to reserve the primary key range according to the data volume. The interval verification module is used to verify the occupancy status of the primary key interval to obtain the available primary key interval; The intermediate data management module is used to build an intermediate data carrying medium based on the available primary key range and generate a mapping table between the source primary key and the target primary key; The data migration module is used to perform data migration processing on the source tenant data based on the effective dependency relationship chain, the structured data structure, and the mapping relationship table, so as to synchronously replace the primary key and foreign key fields of the data according to the mapping relationship table during the migration process.

[0013] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon that can run on a processor, wherein when the computer program is executed by the processor, it implements a seamless migration method for tenant data in a SaaS system as described in the first aspect.

[0014] Using the above method, this application obtains the structural information and foreign key relationship information of the business data tables corresponding to the tenants to be migrated in the source SaaS system, and generates a structured data structure based on the structural information and foreign key relationship information. Foreign key relationships are extracted based on the structured data structure, and a data table dependency relationship chain is constructed. The logical validity of the dependency relationship chain and the source tenant data is verified, and a valid dependency relationship chain that passes the verification is obtained. Based on the valid dependency relationship chain, the data volume of each business data table corresponding to the source tenant is counted. Placeholder records are inserted into the corresponding business data tables of the target SaaS system to reserve primary key intervals according to the data volume, and the occupancy status of the primary key intervals is verified to obtain available primary key intervals. An intermediate data carrier medium is built based on the available primary key intervals, and a mapping table between the source primary key and the target primary key is generated. Based on the valid dependency relationship chain, the structured data structure, and the mapping table, data migration processing is performed on the source tenant data, synchronously replacing the primary key and foreign key fields of the data according to the mapping table during the migration process. This enables efficient and accurate completion of the SaaS system tenant data migration work. Attached Figure Description

[0015] Figure 1 This application provides a flowchart of a method for seamless migration of tenant data in a SaaS system.

[0016] Figure 2 This is a flowchart illustrating a seamless migration method for tenant data in a SaaS system provided in this application.

[0017] Figure 3 This is a schematic diagram of a seamless migration system connection for tenant data in a SaaS system provided in this application. Detailed Implementation

[0018] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but is consistent with the broadest scope claimed in this application.

[0019] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0020] Figure 1 This is a block diagram of a seamless migration method for tenant data in a SaaS system provided in this application. Figure 1 As shown, a seamless migration method for tenant data in a SaaS system includes the following steps: Step S100: Obtain the structure information and foreign key association information of the business data table corresponding to the tenant to be migrated in the source SAAS system, and generate a structured data structure based on the structure information and foreign key association information.

[0021] This application describes the process from the migration perspective. To systematically understand the data organization logic of the source SaaS system and reduce omissions and mismatches caused by manual sorting, the structural information and foreign key relationships of each business data table involved in the tenant to be migrated are automatically extracted through database system table queries. The process involves first connecting to the source SaaS system's database and then obtaining the table names and corresponding table comments of all data tables in the database based on the system's built-in information summary table. Then, using the tenant identifier field as a filter condition, it iterates through each data table to determine whether there are data records belonging to the tenant to be migrated, and identifies the data tables with existing data records as the business data tables to be migrated. For each identified business data table to be migrated, its constraint relationships are extracted using the database's built-in key column usage information table. On one hand, records with constraint type PRIMARY are filtered out from the key column usage information table to accurately extract the primary key field name of the business data table to be migrated; on the other hand, records with a non-nullable reference table name field are filtered out from the key column usage information table to obtain all foreign key field information of the business data table to be migrated in batches. For each foreign key field, the name of its referenced parent table and the corresponding primary key field name are extracted synchronously. These three elements—foreign key field name, parent table name, and parent table primary key field name—are then bound together to form a complete foreign key relationship. During this process, comments for each foreign key and primary key field can be obtained from the database column information summary table. This ensures that the extracted structural information not only includes inter-table relationships but also carries business semantics. By acquiring structural and foreign key relationship information at the database system table level, manual table-by-table checks or the writing of specific scripts are eliminated. This effectively guarantees the completeness of information extraction and the accuracy of relationship analysis, providing a reliable foundation for transforming this information into a unified structured description and constructing accurate data table dependency chains.

[0022] After obtaining the structural information and foreign key relationship information, in order to transform the various metadata scattered in the database system tables into a unified structured description that is well-organized, machine-readable, and carries complete business semantics, a standardized structured data structure generation process is performed for each business data table to be migrated. This process organically aggregates and hierarchically arranges fragmented table structure information, foreign key dependency information, and column-level metadata, ensuring that it not only fully reflects the logical structure of the source data table but also provides a single, reliable metadata input source for subsequent dependency resolution, primary key mapping, and data migration. The generation of the structured data structure based on the structural information and foreign key relationship information includes the following steps: Step S101: Obtain the table name of the business data table corresponding to the tenant to be migrated in the source SaaS system.

[0023] Step S102: Extract the table comments and primary key fields of the business data table from the structure information based on the table name.

[0024] Step S103: Extract at least one foreign key field of the business data table, the name of the parent table associated with each foreign key field, and the primary key field of the parent table from the foreign key association information based on the table name.

[0025] Step S104: Extract all column fields of the business data table, excluding the primary key and foreign key, and the comments of each column field from the structure information based on the table name.

[0026] Step S105: Generate a structured data structure containing a root node, foreign key nodes, and column nodes based on the table name, table comments, primary key field, at least one foreign key field, parent table name, parent table's primary key field, all column fields, and comments for each column field. The structured data structure is any one of XML structure, JSON structure, or database structure, and is used to carry the structural information and foreign key association information of the business data table.

[0027] In this embodiment, XML structs are used as the primary structured data structure. However, in the specific implementation of this method, XML structs may be used as a carrier, including but not limited to JSON structs, databases, and other data structures that can express structure.

[0028] Specifically, based on the list of business data tables to be migrated obtained and confirmed from the database information summary table, the table name of each business data table is read one by one. This table name is the actual name of the data table stored in the source SaaS system database, and all subsequent metadata extraction and XML node construction for this table will use this table name as the core index identifier. Obtaining the table name ensures that the generated XML structure corresponds strictly one-to-one with the physical table in the source database, avoiding migration target mismatch due to inconsistent table names. Then, the table comments and primary key field names bound to the corresponding table names are directly indexed from the extracted structure information. Among them, the table comments come from the TABLE_COMMENT field recorded in the database information summary table, reflecting the business purpose of the business data table; the primary key field names come from the records with constraint type PRIMARY in the key column usage information table, that is, the primary key column name of the table. The table comments give the primary key fields a business context, so that the subsequently generated XML structure not only contains the inter-table relationships, but also carries business semantics, which facilitates data verification and manual checking during the migration process.

[0029] Then, based on the table name, all foreign key fields and their associated information contained in the table are retrieved in batches from the previously extracted foreign key association information. Foreign key association information originates from records in the key column usage information table where the referenced table name field is not null. Each record explicitly provides the foreign key field name of the current table, the name of the parent table referenced by the foreign key, and the name of the primary key field referenced in the parent table. For each foreign key field, the three elements—foreign key field name, parent table name, and parent table primary key field name—are bound together to form a complete foreign key association record, stored in the foreign key node for subsequent encapsulation. When a business data table has multiple foreign key fields, they are extracted and recorded one by one to ensure the integrity of the foreign key association information. Next, from the database column information summary table, all column field information of the business data table is queried and retrieved based on the table name. During the extraction process, primary key fields and foreign key fields are separated from all column fields, and the remaining business column fields and their comments are specifically retained. The comments originate from the COLUMN_COMMENT field in the column information summary table, reflecting the business meaning of each column field. Ensure comprehensive coverage of column-level information in the data table to guarantee column field alignment and business data integrity during migration.

[0030] Finally, an XML structure is generated. The specific implementation process is as follows: First, initialization: Construct the root node, using the data table name as the core identifier. Write the table comment, tenant identifier field, and primary key field name into its attributes. Second, construct foreign key nodes: Create foreign key nodes under the root node. Iterate through all foreign key association records obtained in step S103, generating a corresponding foreign key child node for each record. Write the foreign key field name, foreign key comment (using the format "parent table name: parent table primary key field"), parent table name, and parent table primary key field name into the attributes of this child node. Third, construct column nodes: Create column nodes under the root node. Iterate through all column fields obtained in step S104, generating a corresponding column child node for each column field. Write the column field name and its comment into the attributes of this child node. Fourth, generate the XML structure: Serialize the combined root node, foreign key nodes, and column nodes into a standard format XML structure. This transforms the scattered table structure information and foreign key relationships stored in the source SaaS system database into a unified, hierarchical XML structure carrying complete business semantics. This allows the table names, comments, tenant identifiers, primary key fields, all foreign key relationships, and all column field information of each business data table to be presented in a structured manner. This enables them to be directly read and utilized by subsequent dependency resolution, primary key mapping, and data migration modules without requiring further database queries, improving metadata flow efficiency and effectively reducing the risk of omissions and mismatches caused by manual processing.

[0031] Step S200: Extract foreign key relationships based on structured data structure parsing and construct data table dependency relationship chain. Verify the logical validity of the dependency relationship chain and the source tenant data and obtain the valid dependency relationship chain that has passed the verification.

[0032] After obtaining the XML structures, although these structures fully contain metadata such as the field composition and foreign key relationships of each table, this information is currently stored in a scattered manner on a table-by-table basis, failing to intuitively reflect the global and ordered dependency logic between the business data tables in the SaaS system. If migration is performed directly based on these fragmented XML structures, improper migration order can easily lead to situations where records in the parent table have not yet been inserted, while records in the child table referencing the parent table's primary key have already been written to the target SaaS system, causing foreign key constraint failures and even data logic errors. Therefore, it is necessary to systematically extract foreign key relationships from all XML structures and construct a clear data table dependency chain that specifies the migration order of each business data table. The steps for parsing and extracting foreign key relationships from XML structures and constructing the data table dependency chain include: Step S201: Traverse and parse the foreign key nodes in each structured data structure, and extract the parent table name associated with each foreign key node to obtain a one-way dependency relationship with the current business data table as the child table and the parent table name as the parent table.

[0033] Step S202: Aggregate all unidirectional dependencies to construct a data table dependency chain representing the migration order between various business data tables in the source SaaS system, wherein the migration order specifies that the parent table migrates before the child table.

[0034] Specifically, to transform the hierarchical information in the structured data structure into machine-processable, clearly directional dependencies, a deterministic traversal parsing process is executed. First, the XML structure generated for each business data table to be migrated in step S100 is read sequentially. For each XML structure, its internal foreign key nodes are located and traversed. This foreign key node serves as a dedicated container for storing foreign key association information, and each of its child nodes represents a parent table that the current business data table depends on. Further, the parent table name is parsed and extracted from the attributes of each foreign key child node. This field explicitly defines which primary key of the target SaaS system the foreign key field of the current business data table specifically references; it is a child-to-parent directional identifier. Based on the extracted parent table name, a clear unidirectional dependency relationship can be generated for each foreign key association. This unidirectional dependency relationship defines the business data table represented by the current XML structure as the child table and the parent table name extracted from the foreign key child node as the parent table, thus forming a relationship expression where the child table depends on the parent table. Logically, the source and flow of data references must be clearly defined, meaning that the writing of records to sub-tables must be done only if the corresponding primary key record in the parent table already exists. For example, when parsing the XML structure of the equipment maintenance plan result table (sub-table), by traversing its foreign key nodes, the parent table name referenced by its factoryid field is biz_base_factory, and the parent table name referenced by its planid field is biz_dev_maintain_plan. This accurately reveals the logical relationship between the equipment maintenance plan result table and the factory table and the equipment maintenance plan table.

[0035] Next, after parsing the scattered XML structures into a series of independent unidirectional dependencies, these relationships are still fragmented and cannot be used to directly plan the global migration task. Therefore, aggregation and chaining operations are further performed. All unidirectional dependencies extracted from the XML structures of each business data table are uniformly collected. Using these unidirectional dependencies as directed edges and each business data table as a node, they are combined into a directed acyclic graph (DAG) using algorithms such as topological sorting. This DAG is the data table dependency chain, which completely and without redundancy represents the complex dependency network between all business data tables to be migrated in the entire source SaaS system. In the data table dependency chain, the strict migration order between each business data table is intuitively defined. This order is established based on a basic principle: the parent table that is depended upon must be migrated before the child tables that depend on the parent table. This means that during multi-table migration task scheduling, the root parent tables that do not depend on any other tables will be migrated first. After their data is completely written to the target SaaS system, the migration of the next-level child tables that depend on these parent tables will then be executed, and so on, in a bottom-up or top-down order according to the dependency hierarchy. Continuing the previous example, the generated dependency chain will explicitly indicate: first migrate the factory table (biz_base_factory) and the equipment maintenance plan table (biz_dev_maintain_plan). After their migration is complete, the equipment maintenance plan result table (table_a) that depends on them will be migrated. This reduces the risk of foreign key constraint failure due to disordered migration order from a global mechanism perspective. This systematically transforms the implicit foreign key dependency information scattered in various XML structures into an explicit and globally schedulable data table dependency chain, eliminating the need for manual analysis of complex table relationships. This not only improves the efficiency and accuracy of dependency analysis but also effectively avoids migration order errors caused by omissions or misunderstandings of foreign key associations. This lays a solid foundation for subsequent orderly and reliable multi-table data migration, ensuring the logical integrity of the source tenant data and the validity of foreign key associations after migration.

[0036] Although the dependency chain obtained above structurally defines the migration order of each business data table, directly using it as the sole basis for migration scheduling still presents two potential risks: First, the foreign key association information recorded in the XML structure may deviate from the actual constraints in the source database, such as the parent table being deleted or the data type of the parent table's primary key field changing; second, the source tenant data itself may have logical defects, i.e., the value of the child table's foreign key field does not have a matching primary key record in the corresponding parent table. Any of these situations will lead to foreign key constraint failure or data logic errors after migration to the target SaaS system. Therefore, before formally executing the data migration, it is necessary to perform dual verification of the metadata accuracy of the dependency chain and the logical completeness of the source tenant data to obtain a valid dependency chain that has been confirmed to be error-free. Verifying the logical validity of the dependency chain and the source tenant data and obtaining a valid dependency chain that has passed the verification includes the following steps: Step S203: Traverse the structured data structures corresponding to each unidirectional dependency in the data table dependency chain, and verify the existence and data type consistency of the parent table name and parent table primary key field recorded in each structured data structure in the source database. After removing the unidirectional dependencies that fail the verification, a quasi-valid dependency chain is obtained.

[0037] Step S204: Traverse the structured data structure corresponding to each sub-table in the quasi-effective dependency relationship chain, extract the foreign key fields of the sub-tables, and perform a join query on the corresponding parent table through the foreign key fields. Sub-table foreign key data that can be found in the corresponding parent table records are judged as logically normal data, and sub-table foreign key data that cannot be found in the corresponding parent table records are judged as logically abnormal data and a pause migration prompt is triggered.

[0038] Step S205: Aggregate the unidirectional dependencies corresponding to all logically normal data to generate a valid dependency chain that has passed verification.

[0039] Specifically, the generated XML structures are first parsed, and the parent table name and primary key field name recorded in the foreign key nodes are extracted one by one. Then, the database of the source SaaS system is directly connected, and a comparison query is performed using the database's built-in information summary table: verifying whether each parent table name actually exists in the current database, and further confirming whether the declared primary key field of the parent table truly exists, and whether its data type is completely consistent with the data type of the child table's foreign key field. If, during the traversal, it is found that a parent table pointed to by a unidirectional dependency does not exist, the parent table's primary key field does not exist, or the data type does not match, it indicates that the foreign key association information has become invalid or is incorrectly recorded in the source database. For such unidirectional dependencies that fail verification, they are removed from the dependency chain, and log information containing the reason for failure and the specific table and field names is generated for migration management personnel to check and correct. After traversing and removing all abnormal dependencies, the remaining unidirectional dependency chain is the quasi-valid dependency chain that has passed metadata-level verification. It effectively reduces migration scheduling errors caused by the inconsistency between database metadata and XML description, and provides accurate and clean dependency input for subsequent data logic verification.

[0040] After confirming the quasi-valid dependency chain, the focus of verification shifts from the database metadata level to the source tenant data itself. Each foreign key value of the record to be migrated in the sub-table is examined to ensure that a unique and valid matching primary key record exists in the parent table, guaranteeing the self-consistency of the tenant data at the business logic level. Specifically, based on the quasi-valid dependency chain, each dependent sub-table is traversed sequentially, and all foreign key field names are extracted from the corresponding XML structure of that sub-table. Using these foreign key fields, a join query is constructed. For the sub-table data in the source database, using the tenant identifier field as the filtering condition, LEFT JOIN or subqueries are performed with the corresponding parent table to batch verify the matching status of foreign key field values ​​in the parent table's primary key column. For each foreign key field value, if a corresponding primary key record can be found in the specified parent table, the sub-table record is marked as logically normal data; conversely, if a sub-table record's foreign key field value has no matching record in the parent table, it is judged as logically abnormal data. If at least one logically abnormal record is detected in any sub-table, it indicates a data integrity issue with missing foreign key references in the source tenant's data. Forcing a migration would result in dangling references in the target SaaS system. In this case, the migration process will automatically trigger a pause prompt, interrupting the subsequent migration flow and outputting an anomaly report to the migration administrator. The report will precisely list the sub-table name containing the abnormal data, the foreign key field name, the specific value of the abnormal foreign key, and the corresponding row identifier, facilitating data repair or manual decision-making in the source system. Conversely, if all foreign key field values ​​in the sub-table to be migrated have corresponding primary key records in the parent table, the data logic validation of that sub-table passes.

[0041] Finally, the unidirectional dependencies to which all logically normal data belongs are aggregated systematically. That is, a unidirectional dependency between a child table and its parent table is marked as valid only when all records to be migrated in the child table have been verified through foreign key join queries and no logically abnormal data is found. All valid unidirectional dependencies are retained in the dependency chain, while dependency branches containing logically abnormal data are removed. The resulting aggregated data table dependency chain is the valid dependency chain. This valid dependency chain satisfies both metadata accuracy and data logic completeness constraints, serving as the sole reliable basis for subsequent primary key range statistics, primary key mapping generation, and formal data migration scheduling. This establishes a dual verification closed loop consisting of structural verification, data logic verification, and valid chain aggregation before data migration execution. On the one hand, it automatically identifies and eliminates metadata discrepancies between XML descriptions and database implementations. On the other hand, it accurately discovers and intercepts potential logical defects such as missing foreign key references in the source tenant data, eliminating the risk of data association confusion after migration from the source end, improving the reliability and automation of the migration process, and ensuring that the tenant data delivered in the final SaaS system has the same logical integrity and business availability as the source system.

[0042] Step S300: Based on the effective dependency relationship chain, the data volume of each business data table corresponding to the source tenant is counted. Placeholder records are inserted into the corresponding business data table of the target SAAS system to reserve the primary key range according to the data volume. The occupancy status of the primary key range is verified to obtain the available primary key range.

[0043] After obtaining the effective dependency chain, to ensure the accuracy of subsequent primary key range reservation operations and the orderly nature of the migration process, it is necessary to accurately count the amount of data to be migrated in each business data table of the source tenant. This involves first traversing each business data table included in the effective dependency chain, and for each business data table, extracting the tenant identifier field from the root node of the corresponding XML structure. The tenant identifier field is used to distinguish data records from different tenants. Then, using the tenant identifier field equal to the unique identifier of the tenant to be migrated as a filtering condition, a counting query is performed on the business data table in the source SaaS system's database. For example, an SQL statement in the form of SELECT COUNT(*) FROM business data table WHERE tenant identifier field = tenant identifier value is used to obtain the total number of records belonging to the tenant to be migrated in that business data table. This counting operation is performed sequentially on all business data tables in the effective dependency chain to finally obtain the amount of data to be migrated for each business table. This allows for targeted statistics based on effective dependency chains, reducing the scanning of irrelevant data tables, improving statistical efficiency, and providing a reliable data base for accurate reservation of primary key intervals. This effectively prevents insufficient primary key interval reservation or wasted space due to inaccurate data volume estimation, thereby improving the stability and resource utilization of the migration process.

[0044] After obtaining the amount of data to be migrated from each business data table of the source tenant, in order to accurately reserve the primary key range, a contiguous and unoccupied primary key space needs to be constructed for each business data table in the target SaaS system. Since the target SaaS system is continuously running, its auto-incrementing primary key is dynamically growing, and a fixed available starting value cannot be known in advance before migration. Therefore, placeholder records need to be inserted into the corresponding business data tables of the target SaaS system to reserve the primary key range based on the data volume. This process of inserting placeholder records into the corresponding business data tables of the target SaaS system to reserve the primary key range includes the following steps: Step S301: Obtain the current maximum primary key value of the business data table corresponding to the target SAAS system. Calculate a placeholder primary key value based on the current maximum primary key value, the data volume, and the preset primary key redundancy.

[0045] Step S302: Based on the placeholder primary key value and the predefined tenant identifier special mark, construct a placeholder record and insert the placeholder record into the business data table corresponding to the target SAAS system, so as to reserve a primary key range between the current maximum primary key value and the placeholder primary key value in the business data table.

[0046] Specifically, first, for the currently processed business data table, an aggregate query is initiated to the target SaaS system database to obtain the maximum primary key value of the table up to the current moment. Then, a placeholder primary key value is calculated based on this dynamic baseline. The calculation formula is: Placeholder primary key value = Current maximum primary key value + Amount of data to be migrated + Primary key redundancy. Here, the amount of data to be migrated is the total number of records that need to be migrated from the source SaaS system, as calculated based on the effective dependency chain and tenant identifier field. It determines the minimum space that the reserved interval must accommodate. The primary key redundancy is a preset positive integer, whose core function is to build a safe buffer. Because within the extremely short time window of executing the query, calculation, and subsequent insertion of placeholder records, other normal business requests from the target SaaS system may concurrently insert new data, causing the current maximum primary key value to increase. Introducing primary key redundancy can effectively absorb this concurrent increase, preventing the reserved primary key interval from being immediately crowded out by new business data, thus ensuring the continuity and sufficiency of the reserved space.

[0047] After obtaining the placeholder primary key value, a special INSERT operation is used to anchor the upper bound of this range in the target SaaS system's business data table. Specifically, a placeholder record is first constructed, and the placeholder primary key value is explicitly assigned to the primary key field of the table. Simultaneously, the tenant identifier field of the table is assigned a predefined tenant identifier special flag. This special flag is a preset value that will not conflict with any normal tenant identifier, clearly distinguishing the placeholder record as a system auxiliary record rather than business data at the data level. For other necessary fields in the business data table, safe default values ​​are filled according to their data types to satisfy non-null constraints. Then, an insert operation is immediately performed to write the placeholder record into the target SaaS system's database. After successful insertion, the placeholder record forms a logically continuous and predetermined primary key range between its primary key value and the current maximum primary key value obtained in step S301. This primary key range is specifically reserved for the source tenant data to be migrated in. All available primary key values ​​within this range will not be allocated in the subsequent normal business processes of the target SaaS system, thus eliminating the possibility of primary key conflicts at the physical storage level. This allows for the dynamic construction of an isolated primary key range that adapts to the target system's state, at the cost of lightweight single-row real-time queries and single-insert operations. This reduces performance disruption caused by locking the target table or performing full table scans, minimizes the impact on the normal business operations of the target SaaS system, and precisely ensures that all data to be migrated from the source tenant receives a continuous and conflict-free new primary key.

[0048] Considering that the target SaaS system is running continuously, within the extremely short time window between querying the current maximum primary key value and successfully inserting a placeholder record, other normal business requests may have concurrently inserted new data, causing the reserved primary key range to be partially occupied. Therefore, after inserting a placeholder record, the reserved range is not immediately assumed to be available. Instead, a deterministic real-time verification of the occupancy status of the range is performed to obtain a confirmed, completely free, available primary key range. The verification of the occupancy status of the primary key range to obtain a available primary key range includes the following steps: Step S303: In the business data table corresponding to the target SaaS system, query the existing records whose primary key values ​​are within the reserved range defined by the current maximum primary key value and the placeholder primary key value.

[0049] Step S304: When an existing record is found, the placeholder primary key value is incremented based on the number of existing records to obtain a new placeholder primary key value. The placeholder record is then reconstructed and inserted based on the new placeholder primary key value to re-execute the query and increment correction until no existing record is found.

[0050] Step S305: When no existing record can be found, the interval defined by the current maximum primary key value and the latest placeholder primary key value is determined as the available primary key interval.

[0051] Specifically, a precise range query is initiated directly into the target database. The query conditions are strictly limited to the primary key being greater than the current maximum primary key value and less than the placeholder primary key value, to explore whether any records inserted due to concurrent business exist within this range. When an existing record is found, it indicates that the original reserved range has been contaminated and cannot guarantee the accommodation of all the data to be migrated. At this time, an incremental correction mechanism is executed. Based on the number of existing records found, the sum of the number of existing records and the amount of data to be migrated that the reserved range originally needed to accommodate is used as the new data volume increment. This sum is incremented on the original placeholder primary key value to calculate a larger new placeholder primary key value. Subsequently, a new placeholder record is dynamically constructed based on the new placeholder primary key value, and the insertion operation is re-executed, thereby expanding a new and larger reserved range backward at the physical storage level. After inserting the new placeholder record, the range query in step S303 is re-executed with reference to the new record to re-verify the availability of the new range. If an existing record is found again, the process is repeated, forming a closed loop of dynamic expansion and repeated verification, until the query result of step S303 is empty. Under the pressure of concurrent writes, this mechanism ensures that the interval continues to expand until it finds a physical, uninterrupted contiguous space. When a query result shows zero existing records after step S303 in a certain iteration, it indicates that the reserved interval corresponding to this verification has obtained a definite, clearly defined, and completely free state from the physical storage level. The incremental correction loop stops, and the interval corresponding to this query, defined by the initially locked current maximum primary key value and the latest placeholder primary key value inserted, is officially determined as the available primary key interval. This interval serves as a dedicated, conflict-free, and reliable address space for subsequent source tenant data to be written to the target SaaS system. Thus, a lightweight single-table range query replaces table-level locks, and with the help of a dynamic incremental correction mechanism, the risk of the reserved interval being momentarily filled by concurrent business is adaptively mitigated. This ensures the continuity, integrity, and absolute freeness of the primary key interval obtained by the migrated data without interfering with the normal business operation of the target SaaS system.

[0052] Furthermore, by statistically analyzing the data volume of each business data table based on the effective dependency relationship chain and inserting placeholder records to reserve primary key ranges according to the data volume, the target SaaS system can pre-form a primary key space that matches the scale of the data to be migrated before officially writing the source tenant data. Using the actual amount of data to be migrated as the basis for reserving primary key ranges, and combining this data volume with the reserved space, the impact of concurrent writes that may occur during the operation of the target SaaS system is absorbed, thereby reducing the risk of insufficient primary key ranges, primary key conflicts, and migration interruptions. Simultaneously, by verifying the occupancy status of primary key ranges and determining available primary key ranges, the idle status of primary key ranges can be confirmed without relying on table-level locking. This ensures that the source tenant data obtains a continuous, reliable, and controllable target primary key range during the migration process, thereby improving the stability and accuracy of data migration and compatibility with the normal business operation of the target SaaS system.

[0053] Step S400: Based on the available primary key range, build an intermediate data carrying medium and generate a table showing the correspondence between the source primary key and the target primary key.

[0054] After obtaining the available primary key range, to address the fundamental problem of data association collapse caused by differences in auto-incrementing primary keys between the source and target SaaS systems, an independent mapping data space is constructed to decouple and transform the primary key system. Specifically, an intermediate data carrier medium independent of both the source and target SaaS systems is first built. Then, for each business data table to be migrated in the effective dependency chain, a corresponding mapping table is created in this intermediate data carrier medium. The mapping table is named according to the rule of source data table name + _setid, and its internal structure contains at least two core fields: the source primary key and the target primary key. These fields store the original primary key value of the source data record and the new primary key value to be used in the target system, respectively. The process of generating the mapping table involves reading all records belonging to the tenant to be migrated from the source SaaS system for the currently processed business data table and extracting their source primary key values ​​to form a source primary key set. Simultaneously, based on the starting value of the available primary key range (i.e., the current maximum primary key value + 1), a unique and incremental target primary key value within the available primary key range is assigned to each record in the source primary key set. The mapping relationship between each pair of source primary keys and assigned target primary keys is then batch-inserted into the mapping table of the intermediate data carrier as a data row. This mapping table serves as the core mapping hub during the migration process, enabling subsequent data migration to quickly look up the table and synchronously replace the old primary key and foreign key reference values ​​in the data rows with the new primary key recognized by the target system, fundamentally ensuring the logical integrity and consistency of cross-table data relationships after migration.

[0055] It should be noted that the intermediate data carrier medium in this method includes, but is not limited to, relational databases such as intermediate databases. Any format that can be used to carry data, such as txt, excel, etc., can be used as the intermediate data carrier medium.

[0056] Step S500: Perform data migration processing on the source tenant data based on the effective dependency relationship chain, structured data structure and mapping relationship table, so as to synchronously replace the primary key and foreign key fields of the data according to the mapping relationship table during the migration process.

[0057] The data migration process, which involves performing data migration on the source tenant data based on an effective dependency chain, structured data structure, and a mapping table, and synchronously replacing the primary key and foreign key fields of the data according to the mapping table during the migration, includes the following steps: Step S501: Determine the migration order of each data table based on the effective dependency relationship chain.

[0058] Step S502: Select multiple data tables with no dependencies as parallel migration groups based on the migration order.

[0059] Step S503: Dynamically determine the corresponding batch insertion threshold based on the amount of data to be migrated in each data table in the parallel migration group, and divide the source tenant data into several data batches according to the batch insertion threshold.

[0060] Step S504: When the current data table begins to migrate, insert a migration flag record carrying a migration identifier into the data table.

[0061] Step S505: Based on the structured data structure, construct an insert statement template for each data batch of records to be migrated, wherein the insert statement template contains source primary key and source foreign key fields in placeholder form.

[0062] Step S506: Based on the lookup table, query the target primary key corresponding to the source primary key and the target primary key of the parent table corresponding to the source foreign key field value, and synchronously replace the corresponding placeholder in the insert statement template with the query results to generate the target insert statement.

[0063] Step S507: Execute the target insert statement in parallel according to the batch insert threshold to write the data batch to the target SaaS system.

[0064] Specifically, the effective dependency chain undergoes double verification and is a directed acyclic graph structure. First, it is transformed into a linear execution sequence: the root parent table, which does not depend on any other business data tables, is determined as the first migration level; then all direct child tables of this parent table are determined as the second migration level; and so on, expanding layer by layer according to dependency depth. This hierarchical ordering ensures that before migrating any child table record, the primary key record of the parent table it references already exists in the target SaaS system, strictly adhering to the constraint that parent tables migrate before child tables from a global scheduling mechanism perspective. Within the same migration level, there are no foreign key dependencies between business data tables. Then, all data tables within the same level are aggregated into a group, allowing parallel processing in subsequent steps. Parallel groups between different levels must still adhere to the sequential order; the migration of the next parallel group is only started after all data tables in the previous parallel group have been migrated. This design maximizes the utilization of the parallelism of the dependency chain. The batch insert threshold is dynamically calculated in segments based on the amount of data to be migrated: when the data volume is less than or equal to the first preset threshold, a smaller batch size is used; when the data volume is greater than the first preset threshold, a larger batch size is used. After the source tenant data is split using this threshold, each batch serves as the smallest unit of operation for a single batch write. This dynamic adjustment mechanism balances the high throughput requirements of large data tables with the transaction lightweight nature of small data tables. The migration flag record is a predefined special marker row, whose tenant identifier field is set to a migration-specific flag value that distinguishes it from any normal tenant, while other fields are filled with default values. Its function is to define a clear boundary for the migration task of this data table. When subsequent steps query the source data, this record can be used as a boundary to distinguish migrated data. It also serves as a mutual exclusion signal to prevent the same data table from being repeatedly scheduled for migration in multi-threaded parallel processing.

[0065] Next, all column field names are extracted from the column nodes of the XML structure of the data table to generate a statement skeleton in the form of INSERTINTO table_name(column1, column2, ...) VALUES (...). The primary key and foreign key fields in this template are not filled with actual values; instead, they are marked as source primary key placeholders and source foreign key placeholders using predefined placeholders. The remaining business column fields are directly read from the source data rows and filled in, constructing a semi-finished insert statement template for primary key replacement. Then, for each insert statement template generated in step S505, the source primary key field value is first extracted from the source data rows, and its corresponding target primary key value is obtained by querying the lookup table. The source primary key placeholder in the template is then replaced with this target primary key value. Simultaneously, all foreign key placeholders in the template are traversed. For each source foreign key field value, a lookup table query is also performed to obtain the target primary key value referenced in its corresponding parent table, and the source foreign key placeholder is synchronously replaced with the target primary key value of the parent table. After all replacements are complete, target insert statements that can be directly executed in the target SaaS system are generated. Finally, for each data table within the current parallel migration group, based on the data batches defined in step S503, all target insert statements generated within the same batch are encapsulated into a single database transaction and submitted to the target SaaS system for execution in parallel via a multi-threaded pool. After each batch is completed, the next batch is processed until all batches for that table are migrated. The entire write process is a single batch INSERT operation, without involving complex table joins or applying explicit table-level locks to the target table. This allows for the determination of a hierarchical migration order based on verified dependency chains and the implementation of parallel processing of tables at the same level. The batch size is dynamically adjusted according to the amount of data to be migrated to balance throughput and system load. Migration flags are used to prevent multi-threaded scheduling conflicts. Simultaneously, a unified conversion between primary and foreign keys is achieved using a lookup table as the core hub. Finally, data is persisted to the database using a lightweight batch insert method. By organically integrating dependency constraints, parallel scheduling, primary key mapping, and dynamic batch writing, migration efficiency is improved while ensuring the integrity and consistency of data association logic after migration, and the impact on the normal operation of the target SaaS system is minimized.

[0066] Preferably, after the data migration is completed, all placeholder records in the target SaaS system are deleted based on the placeholder record identifier, thereby reclaiming the reserved primary key space and reducing the interference of residual auxiliary data with the subsequent business operation of the target SaaS system, ensuring the cleanliness and standardization of the data environment.

[0067] Furthermore, a mapping table between source and target primary keys is created based on the intermediate data carrier medium. During data migration, the primary key and foreign key fields are synchronously replaced according to this mapping table. This method of replacing foreign keys based on the intermediate layer preserves the mapping relationship between source and target primary keys through the intermediate data carrier medium. This ensures that the corresponding target primary key can be determined for each source tenant data before it is written to the target SaaS system. Simultaneously, the source foreign key field values ​​in the child table can be replaced with the target primary key of the parent table in the target SaaS system. Therefore, data migration no longer relies on the direct reuse of the source primary key in the target SaaS system, avoiding primary key conflicts and ensuring that the foreign key relationships between the parent and child tables remain consistent after migration. This improves the integrity of cross-table data relationships, the traceability of migration results, and the maintainability of the migration process.

[0068] Figure 2 This is a flowchart illustrating a seamless migration method for tenant data in a SaaS system provided in this application. Figure 2 As shown, the process begins by organizing the source database table structure and generating an XML structure. Then, dependency and data logic are validated. If validation fails, the user is prompted to process the source data / dependencies, the migration is terminated, and the process ends. If validation passes, the amount of tenant data to be migrated from the source system is first calculated. Next, placeholder records are inserted in the target system, reserving primary key ranges. Then, it is checked whether the reserved primary key ranges are occupied. If occupied, the placeholder IDs are recalculated, and placeholder records are re-inserted. If not occupied, an intermediate data carrier is built, a primary key mapping table is generated, multi-table parallel data migration is performed, and placeholder records in the target system are cleaned up. The migration is then complete, the target system can operate the migrated data normally, and the process ends.

[0069] Figure 3 This is a schematic diagram illustrating a seamless migration system connection for tenant data in a SaaS system, as provided in this application. Figure 3As shown, the system includes: a table structure analysis module to obtain the structure information and foreign key relationship information of the business data tables of the tenants to be migrated in the source SaaS system, and generate a structured data structure based on the structure information and foreign key relationship information. A dependency relationship generation module to parse and extract foreign key relationships based on the structured data structure and construct a data table dependency relationship chain. A logic verification module to verify the logical validity of the dependency relationship chain and the source tenant data and obtain a valid dependency relationship chain that passes the verification. A data volume statistics module to count the data volume of each business data table corresponding to the source tenant based on the valid dependency relationship chain. A primary key range reservation module to insert placeholder records in the corresponding business data tables of the target SaaS system to reserve primary key ranges according to the data volume. A range verification module to verify the occupancy status of primary key ranges to obtain available primary key ranges. An intermediate data management module to build an intermediate data carrier medium based on the available primary key ranges and generate a mapping table between the source primary key and the target primary key. A data migration module to perform data migration processing on the source tenant data based on the valid dependency relationship chain, the structured data structure, and the mapping table, and to synchronously replace the primary key and foreign key fields of the data according to the mapping table during the migration process.

[0070] The other functions performed by the above-mentioned table structure sorting module, dependency generation module, logical verification module, data volume statistics module, primary key interval reservation module, interval verification module, intermediate data management module, and data migration module, as well as the technical details of each function, are the same or similar to the corresponding features in the seamless migration method for tenant data in a SAAS system described above, so they will not be repeated here.

[0071] This application also provides a computer storage medium storing a computer program that, when run on a computer, enables the computer to execute the steps in the previously described method for seamless migration of tenant data in a SaaS system.

[0072] It should be understood that although the steps in the flowcharts in the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order requirement for the execution of these steps, and they can be performed in other orders.

[0073] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for seamless migration of tenant data in a SaaS system, characterized in that, The method includes: Obtain the structure information and foreign key association information of the business data table corresponding to the tenant to be migrated in the source SaaS system, and generate a structured data structure based on the structure information and foreign key association information; Based on the structured data structure, foreign key relationships are extracted and a data table dependency chain is constructed. The logical validity of the dependency chain and the source tenant data is verified, and a valid dependency chain that passes the verification is obtained. Based on the data volume of each business data table corresponding to the source tenant of the effective dependency relationship chain, placeholder records are inserted into the corresponding business data table of the target SAAS system to reserve the primary key range according to the data volume, and the occupancy status of the primary key range is verified to obtain the available primary key range. Based on the available primary key range, an intermediate data carrying medium is constructed and a table of correspondence between the source primary key and the target primary key is generated; Based on the effective dependency chain, the structured data structure, and the mapping table, data migration processing is performed on the source tenant data to synchronously replace the primary key and foreign key fields of the data according to the mapping table during the migration process.

2. The method according to claim 1, characterized in that, The generation of structured data structure based on the structural information and foreign key association information includes: Obtain the table name of the business data table corresponding to the tenant to be migrated in the source SaaS system; Based on the table name, extract the table comments and primary key fields of the business data table from the structure information; Based on the table name, extract at least one foreign key field of the business data table, the name of the parent table associated with each foreign key field, and the primary key field of the parent table from the foreign key association information; Based on the table name, extract all columns and fields of the business data table except for the primary key and foreign key, as well as the comments of each column and field, from the structure information; The structured data structure is generated based on the table name, the table comments, the primary key field, the at least one foreign key field, the parent table name, the parent table's primary key field, all column fields, and comments for each column field. The structured data structure is any one of an XML structure, a JSON structure, or a database structure, and is used to carry the structural information and foreign key association information of the business data table.

3. The method according to claim 2, characterized in that, The step of parsing and extracting foreign key relationships based on the structured data structure and constructing a data table dependency chain includes: Traverse and parse the foreign key nodes in each structured data structure, extract the parent table name associated with each foreign key node, and obtain a one-way dependency relationship with the current business data table as the child table and the parent table name as the parent table; Aggregate all unidirectional dependencies to construct a data table dependency chain representing the migration order between various business data tables in the source SaaS system, wherein the migration order specifies that the parent table migrates before the child table.

4. The method according to claim 3, characterized in that, The step of verifying the logical validity of the dependency relationship chain and the source tenant data and obtaining the valid dependency relationship chain that has passed the verification includes: Traverse the structured data structures corresponding to each one-way dependency in the data table dependency chain, and verify the existence and data type consistency of the parent table name and parent table primary key field recorded in each structured data structure in the source database. After removing the one-way dependencies that fail the verification, a quasi-valid dependency chain is obtained. Traverse the structured data structure corresponding to each sub-table in the quasi-effective dependency relationship chain, extract the foreign key fields of the sub-tables, and perform a join query on the corresponding parent table through the foreign key fields. Sub-table foreign key data that can be found in the corresponding parent table records are judged as logically normal data, and sub-table foreign key data that cannot be found in the corresponding parent table records are judged as logically abnormal data and a pause migration prompt is triggered. Aggregate all logically normal data corresponding to one-way dependencies to generate a valid dependency chain that has passed verification.

5. The method according to claim 1, characterized in that, The step of inserting placeholder records in the corresponding business data table of the target SaaS system to reserve a primary key range based on the data volume includes: Obtain the current maximum primary key value of the business data table corresponding to the target SaaS system, and calculate a placeholder primary key value based on the current maximum primary key value, the data volume, and the preset primary key redundancy. Based on the placeholder primary key value and the predefined tenant identifier special mark, a placeholder record is constructed and inserted into the business data table corresponding to the target SaaS system, so as to reserve a primary key range between the current maximum primary key value and the placeholder primary key value in the business data table.

6. The method according to claim 5, characterized in that, The step of verifying the occupancy status of the primary key interval to obtain the available primary key interval includes: In the business data table corresponding to the target SaaS system, query existing records whose primary key values ​​are within the reserved range defined by the current maximum primary key value and the placeholder primary key value; When the existing record is found, the placeholder primary key value is incremented based on the number of existing records to obtain a new placeholder primary key value. The placeholder record is then reconstructed and inserted based on the new placeholder primary key value to re-execute the query and increment correction until the existing record is no longer found. The interval defined by the current maximum primary key value and the latest placeholder primary key value when no existing record can be found is determined as the available primary key interval.

7. The method according to claim 4, characterized in that, The data migration process performed on the source tenant data based on the effective dependency chain, structured data structure, and mapping table, to synchronously replace the primary key and foreign key fields of the data according to the mapping table during the migration process, includes: The migration order of each data table is determined based on the effective dependency chain. Based on the migration order, multiple data tables with no dependencies are selected as parallel migration groups. Based on the amount of data to be migrated in each data table in the parallel migration group, the corresponding batch insertion threshold is dynamically determined, and the source tenant data is divided into several data batches according to the batch insertion threshold. When the migration of the current data table begins, insert a migration flag record carrying the migration identifier into the data table; Based on the structured data structure, an insertion statement template is constructed for each data batch to be migrated, wherein the insertion statement template contains source primary key and source foreign key fields in the form of placeholders; Based on the reference relationship table, query the target primary key corresponding to the source primary key and the target primary key of the parent table corresponding to the source foreign key field value, and synchronously replace the corresponding placeholder in the insert statement template with the query results to generate the target insert statement; The target insert statement is executed in parallel according to the batch insert threshold to write the data batch to the target SaaS system.

8. The method according to claim 1, characterized in that, The method further includes: after the data migration is completed, deleting all placeholder records in the target SaaS system based on the placeholder record identifier.

9. A seamless migration system for tenant data in a SaaS system, characterized in that, The system includes: The table structure sorting module is used to obtain the structure information and foreign key association information of the business data table corresponding to the tenant to be migrated in the source SaaS system, and generate a structured data structure based on the structure information and foreign key association information. The dependency generation module is used to parse and extract foreign key relationships based on the structured data structure and construct a data table dependency chain; The logical verification module is used to verify the logical validity of the dependency relationship chain and the source tenant data and obtain the valid dependency relationship chain that has passed the verification. The data volume statistics module is used to count the data volume of each business data table corresponding to the source tenant based on the effective dependency relationship chain; The primary key range reservation module is used to insert placeholder records in the corresponding business data table of the target SaaS system to reserve the primary key range according to the data volume. The interval verification module is used to verify the occupancy status of the primary key interval to obtain the available primary key interval; The intermediate data management module is used to build an intermediate data carrying medium based on the available primary key range and generate a mapping table between the source primary key and the target primary key; The data migration module is used to perform data migration processing on the source tenant data based on the effective dependency relationship chain, the structured data structure, and the mapping relationship table, so as to synchronously replace the primary key and foreign key fields of the data according to the mapping relationship table during the migration process.

10. A computer-readable storage medium having a computer program stored thereon that can run on a processor, characterized in that, When the computer program is executed by the processor, it implements a seamless migration method for tenant data in a SaaS system as described in any one of claims 1 to 8.

Images