Heterogeneous database table building method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a heterogeneous database building method and device, equipment, a storage medium and a program product. The method comprises the following steps: determining a source database type corresponding to a source database and a target database type corresponding to a target database; aiming at each first field type in the source database, respectively searching a corresponding second field type in the target database, and writing the searched second field type into a field type set; for respective definition types in the source database, respectively converting the definition types into equivalent field types in the target database according to a dependency relationship between the self-definition types, and writing the equivalent field types into a field type set; and generating a target table corresponding to the target database according to the field type set and the target database type. According to the method, the table building efficiency is improved, and the user-defined types can be accurately converted, so that the compatibility of table building is improved, and the accuracy of type conversion is guaranteed.

Description

Technical Field

[0001] This application relates to the field of databases, and in particular to a method, apparatus, device, storage medium, and program product for creating tables in a heterogeneous database. Background Technology

[0002] With the rapid development of information technology and the accelerated digital transformation of enterprises, various heterogeneous databases are often deployed to meet the needs of diverse business scenarios. Data synchronization or data migration, as a key technology to ensure the flow of data between different systems, is crucial for business operations, decision-making, and system collaboration.

[0003] Before data synchronization or migration, it is necessary to create tables between heterogeneous databases and then synchronize or migrate the data. However, heterogeneous databases differ significantly in data types and other aspects, making automated table creation between them a pressing issue. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and program product for creating tables in heterogeneous databases, which improves table creation efficiency, enables accurate conversion of custom types, thereby improving table creation compatibility and ensuring the accuracy of type conversion.

[0005] In a first aspect, embodiments of this application provide a method for creating tables in a heterogeneous database, including:

[0006] Determine the source database type corresponding to the source database and the target database type corresponding to the target database;

[0007] For each first field type in the source database, find the corresponding second field type in the target database and write the found second field type into the field type set;

[0008] For each custom type in the source database, according to the dependency relationship between the custom types, they are converted into equivalent field types in the target database, and the equivalent field types are written into the field type set;

[0009] Based on the set of field types and the target database type, create the target table corresponding to the target database.

[0010] This embodiment provides an automated method for handling field type conversion between source and target databases. By automatically finding and converting field types, it reduces the need for manual intervention and improves table creation efficiency. Furthermore, for custom types, it converts them into equivalent field types supported by the target database according to their dependencies, ensuring accurate conversion of custom types and improving table creation compatibility while guaranteeing the accuracy of type conversion.

[0011] In one possible implementation, the step of converting each custom type in the source database into an equivalent field type in the target database according to the dependencies between the custom types includes:

[0012] Obtain the definition information corresponding to each of the custom types in the source database;

[0013] Based on the definition information corresponding to each of the custom types, the dependency relationships between the custom types are determined;

[0014] The custom types are sorted according to the dependencies to obtain the migration order;

[0015] Each of the custom types is converted into an equivalent field type supported by the target database according to the migration order.

[0016] By analyzing the definition information of custom types, the dependencies between types (such as nested types and reference relationships) are clarified, and a migration order is generated based on the dependency ranking. This ensures that during the migration process, the dependent types are converted first, avoiding conversion failures or data loss due to incomplete dependencies.

[0017] In one possible implementation, obtaining the definition information corresponding to each of the custom types in the source database includes:

[0018] Establish a connection to the source database;

[0019] Obtain the query strategy corresponding to the source database type, and query the metadata of each custom type from the source database according to the query strategy;

[0020] Extract the definition information corresponding to each custom type from the metadata of each custom type.

[0021] By establishing a connection with the source database, metadata queries can be performed subsequently. For different database types, corresponding query strategies are adopted to retrieve the metadata of all custom types. For each custom type retrieved, complete definition information is extracted from the metadata to provide data support for determining subsequent dependencies.

[0022] In one possible implementation, determining the dependency relationships between multiple custom types based on the definition information corresponding to each custom type includes:

[0023] For each of the custom types, based on the definition information corresponding to the custom type, the dependency relationship between the custom type and other custom types is identified, and the dependency relationship is constructed into dependency metadata;

[0024] A dependency graph is constructed based on the dependency metadata corresponding to each of the custom types; the nodes in the dependency graph represent the custom types, and the directed edges between the nodes represent the dependency relationships between the custom types.

[0025] The step of sorting the custom types according to the dependencies to obtain the migration order includes:

[0026] The custom types are sorted according to the dependency graph using a topological sorting method to obtain the migration order.

[0027] On the one hand, by automatically identifying dependencies and generating dependency metadata, it avoids omissions or errors that may occur due to manual sorting, ensuring the integrity and accuracy of dependencies. Especially in scenarios where type definitions change frequently (such as microservice architecture and database schema evolution), it can dynamically maintain the correctness of the dependency graph.

[0028] On the other hand, by constructing a dependency graph, the implicit dependencies between custom types are made explicit into a visual structure (nodes + directed edges), enabling developers to intuitively understand the relationship logic between types, reducing the understanding cost of code or data models, and is especially suitable for the maintenance and optimization of large systems or legacy systems.

[0029] In one possible implementation, the step of converting each of the custom types into equivalent field types supported by the target database according to the migration order includes:

[0030] Based on the source database type and the target database type, find the corresponding mapping rule from the preset custom type mapping rules;

[0031] According to the mapping rules, the corresponding type processing function is called for the custom type to be converted;

[0032] The custom type is converted into an equivalent field type supported by the target database using the type processing function.

[0033] By using preset custom type mapping rules and type processing functions, the type conversion from the source database to the target database can be completed automatically, reducing the time spent on manual operations. This is especially suitable for large-scale database migration or cross-database compatibility adaptation scenarios.

[0034] In one possible implementation, the step of searching for the corresponding second field type in the target database for each first field type in the source database, and writing the found second field type into the field type set, includes:

[0035] Based on a preset field type dictionary, traverse the first field type in the source database;

[0036] For each of the first field types encountered during the traversal, the corresponding second field type in the target database is searched according to a preset field type conversion relationship dictionary, and the found second field type is written into the field type set.

[0037] By using a pre-defined field type dictionary and field type conversion relationship dictionary, the first field type of the source database can be automatically traversed and matched with the corresponding type of the target database, reducing manual intervention and significantly improving the efficiency of database migration or synchronization.

[0038] In one possible implementation, the method further includes:

[0039] If no corresponding second field type is found according to the field type conversion relationship dictionary, then the default field type in the field type dictionary that is the same as the target database type is written into the field type set.

[0040] When the source field type does not have a direct corresponding type in the target database, it will fall back to the preset default field type (provided that the database types are consistent), ensuring that the migration process will not be interrupted due to missing types and improving cross-database compatibility. The default field type fallback mechanism ensures that all fields have valid type definitions, avoiding data truncation, storage errors, or query anomalies caused by type mismatches, and maintaining data consistency and availability.

[0041] In one possible implementation, creating the target table corresponding to the target database based on the set of field types and the target database type includes:

[0042] Pass the set of field types and the target database type to the database definition table general interface;

[0043] The database definition table general interface is used to generate data definition language statements that conform to the syntax rules of the target database.

[0044] Create the target table corresponding to the target database according to the data definition language statement.

[0045] This automated approach effectively masks the differences in field types between different databases, enabling users unfamiliar with databases to quickly and accurately obtain the DDL statements defining the target database tables. This allows them to quickly and correctly create the target tables based on the DDL statements, thereby improving the efficiency of data synchronization or migration.

[0046] Secondly, embodiments of this application provide a heterogeneous database table creation apparatus, comprising:

[0047] The determination module is used to determine the source database type corresponding to the source database and the target database type corresponding to the target database.

[0048] The lookup module is used to look up the corresponding second field type in the target database for each first field type in the source database, and write the found second field type into the field type set.

[0049] The conversion module is used to convert each custom type in the source database into an equivalent field type in the target database according to the dependency relationship between the custom types, and write the equivalent field type into the field type set;

[0050] A creation module is used to create a target table corresponding to the target database based on the set of field types and the target database type.

[0051] In one possible implementation, the conversion module includes:

[0052] The acquisition unit is used to acquire the definition information corresponding to each of the custom types in the source database;

[0053] The determining unit is used to determine the dependency relationship between the custom types based on the definition information corresponding to each of the custom types.

[0054] A sorting unit is used to sort each of the custom types according to the dependencies to obtain a migration order;

[0055] The conversion unit is used to convert each of the custom types into equivalent field types supported by the target database according to the migration order.

[0056] In one possible implementation, the acquiring unit is specifically used for:

[0057] Establish a connection to the source database;

[0058] Obtain the query strategy corresponding to the source database type, and query the metadata of each custom type from the source database according to the query strategy;

[0059] Extract the definition information corresponding to each custom type from the metadata of each custom type.

[0060] In one possible implementation, the determining unit is specifically used for:

[0061] For each of the custom types, based on the definition information corresponding to the custom type, the dependency relationship between the custom type and other custom types is identified, and the dependency relationship is constructed into dependency metadata;

[0062] A dependency graph is constructed based on the dependency metadata corresponding to each of the custom types; the nodes in the dependency graph represent the custom types, and the directed edges between the nodes represent the dependency relationships between the custom types.

[0063] Sorting unit, specifically used for:

[0064] The custom types are sorted according to the dependency graph using a topological sorting method to obtain the migration order.

[0065] In one possible implementation, the conversion unit is specifically used for:

[0066] Based on the source database type and the target database type, find the corresponding mapping rule from the preset custom type mapping rules;

[0067] According to the mapping rules, the corresponding type processing function is called for the custom type to be converted;

[0068] The custom type is converted into an equivalent field type supported by the target database using the type processing function.

[0069] In one possible implementation, the lookup module is specifically used for:

[0070] Based on a preset field type dictionary, traverse the first field type in the source database;

[0071] For each of the first field types encountered during the traversal, the corresponding second field type in the target database is searched according to a preset field type conversion relationship dictionary, and the found second field type is written into the field type set;

[0072] In one possible implementation, the lookup module is further configured to:

[0073] If no corresponding second field type is found according to the field type conversion relationship dictionary, then the default field type in the field type dictionary that is the same as the target database type is written into the field type set.

[0074] In one possible implementation, a module is created specifically for:

[0075] Pass the set of field types and the target database type to the database definition table general interface;

[0076] The database definition table general interface is used to generate data definition language statements that conform to the syntax rules of the target database.

[0077] Create the target table corresponding to the target database according to the data definition language statement.

[0078] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory communicatively connected to the processor;

[0079] The memory stores computer-executed instructions;

[0080] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0081] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0082] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0083] The heterogeneous database table creation method, apparatus, device, storage medium, and program products provided in this application offer an automated approach to handling field type conversion between source and target databases. By automatically finding and converting field types, the need for manual intervention can be reduced, improving table creation efficiency. Furthermore, for custom types, by considering the dependencies between custom types, they are converted into equivalent field types supported by the target database, ensuring accurate conversion of custom types and thus improving table creation compatibility and guaranteeing the accuracy of type conversion. Attached Figure Description

[0084] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0085] Figure 1 A schematic diagram of a system architecture provided for this application;

[0086] Figure 2 A flowchart illustrating a method for creating tables in a heterogeneous database, as provided in this application;

[0087] Figure 3 A flowchart illustrating another method for creating tables in a heterogeneous database provided in this application;

[0088] Figure 4 A schematic diagram of a heterogeneous database table creation device provided in this application;

[0089] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application.

[0090] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0091] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0092] The terms "first," "second," etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of this application, a first field type may be referred to as a second field type, and similarly, a second field type may be referred to as a first field type.

[0093] As used in this application, the terms "multiple", "each", and "any" are used in the following ways: multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0094] MySQL: A relational database.

[0095] Doris: A real-time analytical database based on a massively parallel processing (MPP) architecture.

[0096] OceanBase: A distributed relational database.

[0097] Oracle: A relational database.

[0098] Figure 1 A schematic diagram of a system architecture provided for this application, such as Figure 1 As shown, the system architecture includes an electronic device 10, a first database 20, and a second database 30.

[0099] The electronic device 10 can be a terminal device or a server, and this application does not limit it.

[0100] Electronic device 10 can access first database 20 and also access second database 30.

[0101] Electronic device 10 is used to synchronize or migrate data between the first database 20 and the second database 30.

[0102] In data synchronization or migration scenarios, the first database 20 and the second database 30 can serve as the source database and the target database, respectively. For example, if the first database 20 is the source database, then the second database 30 is the target database; conversely, if the second database 30 is the source database, then the first database 20 is the target database.

[0103] Database 20 and Database 30 are heterogeneous databases.

[0104] The first database 20 and the second database 30 can be any kind of database. This application does not limit the specific type of database, such as relational database, structured database, analytical database, file database, graph database, log database, etc.

[0105] With the rapid development of information technology and the accelerated digital transformation of enterprises, various heterogeneous databases are often deployed to meet the needs of diverse business scenarios. Data synchronization or data migration, as a key technology to ensure the flow of data between different systems, is crucial for business operations, decision-making, and system collaboration.

[0106] Before data synchronization or migration, it is necessary to create tables between heterogeneous databases and then synchronize or migrate the data. However, heterogeneous databases differ significantly in data types and other aspects, making automated table creation between them a pressing issue.

[0107] The heterogeneous database table creation method provided in this application determines the source database type and the target database type. For each first field type in the source database, it searches for the corresponding second field type in the target database and writes the found second field types into a field type set. For each custom type in the source database, it converts it into an equivalent field type in the target database according to the dependencies between custom types and writes the equivalent field types into the field type set. Based on the field type set and the target database type, it creates the target table corresponding to the target database. This method handles field type conversion between the source and target databases automatically. By automatically finding and converting field types, it reduces the need for manual intervention and improves table creation efficiency. Furthermore, for custom types, by converting them into equivalent field types supported by the target database according to the dependencies between custom types, it ensures accurate conversion of custom types, thereby improving table creation compatibility and guaranteeing the accuracy of type conversion.

[0108] The heterogeneous database table creation method provided in this application is executed by a heterogeneous database table creation device, which can be integrated into an electronic device, such as the aforementioned electronic device 10.

[0109] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0110] Figure 2 A flowchart illustrating a method for creating tables in a heterogeneous database, as provided in this application, is shown below. Figure 2 As shown, the method includes:

[0111] S201. Determine the source database type corresponding to the source database and the target database type corresponding to the target database.

[0112] The source database is the original storage location of the data, and also the starting point for migration or synchronization operations. The source database contains the data that needs to be extracted, transformed, and loaded into the target database.

[0113] The target database is the final storage location for the data, i.e., the destination for migration or synchronization operations. The target database receives and stores the data extracted from the source database.

[0114] In one possible implementation, the source database type (sourceDatabaseType) corresponding to the source database and the target database type (targetDatabaseType) corresponding to the target database are determined according to business requirements. For example, the source database type is MySQL and the target database type is OceanBase; another example is that the source database type is MySQL and the target database type is Doris.

[0115] For example, the source database type and the target database type can be input by the user.

[0116] S202. For each first field type in the source database, find the corresponding second field type in the target database and write the found second field type into the field type set.

[0117] The first field type is a data type that is predefined and directly supported by the source database's database management system. It can be regarded as a built-in field type or standard field type of the source database, without the need for additional definition by the user.

[0118] The second field type is a data type that is predefined and directly supported by the target database's database management system. It can be regarded as a built-in field type or standard field type of the target database, without the need for additional definition by the user.

[0119] The field type collection is used to store field types.

[0120] S203. For each custom type in the source database, convert them into the equivalent field type in the target database according to the dependency relationship between the custom types, and write the equivalent field type into the field type set.

[0121] Custom types are new types created by users or developers by extending or combining built-in types.

[0122] S204. Based on the set of field types and the target database type, create the target table corresponding to the target database.

[0123] In one possible implementation, the method for creating tables in heterogeneous databases and the corresponding logic can be encapsulated in code to build an automatic table creation tool, which can then be used to create the target tables corresponding to the target database.

[0124] This embodiment provides an automated method for handling field type conversion between source and target databases. By automatically finding and converting field types, it reduces the need for manual intervention and improves table creation efficiency. Furthermore, for custom types, it converts them into equivalent field types supported by the target database according to their dependencies, ensuring accurate conversion of custom types and improving table creation compatibility while guaranteeing the accuracy of type conversion.

[0125] Based on the above embodiments, in one possible implementation, a field type conversion interface is predefined. Accordingly, after S201, the source database type and the target database type are passed to the field type conversion interface, and the following operations are performed through this interface:

[0126] If the source database type is the same as the target database type, then the type of each first field in the source database is obtained based on the source database type, and the types of each first field in the source database are written into the field type set. This reduces unnecessary conversion operations and significantly improves efficiency.

[0127] If the source database type is different from the target database type, then execute S202.

[0128] In one possible implementation, a field type dictionary and a field type conversion relation dictionary are pre-built.

[0129] The field type dictionary includes attribute information for field type objects across multiple databases. This attribute information describes the field type attributes of different databases. For example, attribute information includes a unique field identifier (data_type_id), the database it belongs to (database_type), the type category (data_catalog), the specific field type (data_type), the default recommended length (size), the maximum length (max_size), the minimum length (min_size), whether it is the default type (is_default_type), whether it is required (required), and the sorting field (sort). The unique field identifier (data_type_id) uniquely identifies each field type object to accurately identify each field type. The database it belongs to (database_type) indicates the database to which the field type belongs. The type category (data_catalog) categorizes field types, such as numeric, string, date, and boolean types. The specific field type (data_type) indicates the actual type of the field, such as int, string, or date. The default recommended length (size) indicates the default length of the field type. When size is empty, it means that the field type does not require a length setting, thus providing a reference for setting the field length. The maximum length (max_size) and minimum length (min_size) limit the range of field length values ​​to ensure data integrity and consistency. The default type flag (is_default_type) identifies commonly used default field types in the database, facilitating quick matching during conversion. For example, is_default_type=1 indicates that the field type belongs to the commonly used default field types in the database. The required field flag (required) indicates whether the field type is required (i.e., whether null values ​​are allowed). The sort field (sort) adjusts the order of field types for easier data management and querying; for example, users can flexibly set the sort field according to their actual needs.

[0130] The field type conversion relationship dictionary contains multiple field type conversion relationships. Each relationship includes three fields: a unique relation identifier (transform_relation_id), a unique identifier of the source field type in the field type dictionary (data_type_id), and a target recommended field type (recommend_type). These fields define the conversion mapping between field types from different databases. This structured design provides a rule-based foundation for automated field type conversion, ensuring the accuracy and consistency of the conversion process. `transform_relation_id` uniquely identifies the field type conversion relationship. `data_type_id` associates the field type unique identifier (data_type_id) in the field type dictionary. `recommend_type` specifies the target recommended field type.

[0131] By maintaining a field type dictionary and a field type conversion relationship dictionary, support for new database types or adjustments to conversion rules can be quickly extended. When a new database emerges, simply adding the corresponding field type information to the field type dictionary achieves compatibility with the new database, enhancing compatibility and scalability, and adapting to diverse technology stack requirements.

[0132] Accordingly, the specific implementation process of S202 includes:

[0133] Based on the preset field type dictionary, iterate through the first field type in the source database;

[0134] For each first field type encountered during iteration, the corresponding second field type is found in the target database based on a preset field type conversion relation dictionary.

[0135] In one scenario, if the corresponding second field type in the target database is found based on the field type conversion relation dictionary, then the found second field type is written into the field type set.

[0136] The second field type found in the target database is also the target recommendation field type mentioned above.

[0137] A field type object is a concrete instance of a field type. Accordingly, finding the corresponding second field type in the target database specifically means finding the corresponding field type object in the target database, and a field type set is specifically a collection of field type objects.

[0138] By using a pre-defined field type dictionary and field type conversion relationship dictionary, the first field type of the source database can be automatically traversed and matched with the corresponding type of the target database, reducing manual intervention and significantly improving the efficiency of database migration or synchronization.

[0139] In another scenario, if no corresponding second field type is found in the field type conversion relation dictionary, the default field type in the field type dictionary that is the same as the target database type is written into the field type set.

[0140] If no corresponding field type object is found, the field type object in the field type dictionary that satisfies database_type = targetDatabaseType and is_default_type = 1 is returned, ensuring the rationality and validity of the conversion result.

[0141] When the source field type does not have a direct corresponding type in the target database, it will fall back to the preset default field type (provided that the database types are consistent), ensuring that the migration process will not be interrupted due to missing types and improving cross-database compatibility. The default field type fallback mechanism ensures that all fields have valid type definitions, avoiding data truncation, storage errors, or query anomalies caused by type mismatches, and maintaining data consistency and availability.

[0142] By defining field type dictionaries and conversion relationship dictionaries, along with intelligent field type conversion interfaces, accurate field type conversion can be performed between heterogeneous databases, ensuring data consistency and integrity across different database systems and significantly improving data synchronization efficiency. It provides a convenient operating method for users unfamiliar with databases, eliminating the need for in-depth understanding of complex database field type configuration details, length setting rules, and other complex knowledge. Users can quickly perform data synchronization operations through a universal interface, lowering the technical barrier to data synchronization.

[0143] In one possible implementation, for databases that support multiple schemas (such as OceanBase supporting both MySQL and Oracle schemas), the target database connection information (ConnectParams) is also obtained. This parameter is then passed to the field type conversion interface to query the specific schema used by OceanBase, thereby returning the most accurate field type and further improving the accuracy of the conversion. This parameter can be obtained through the application programming interface (API) provided by the corresponding database.

[0144] For databases like OceanBase that support multiple schemas, the target database connection information parameter can be used to accurately identify and adapt to the differences in field types under different schemas, effectively solving the problem of field type conversion between different schemas of the same database.

[0145] Based on the above embodiments, in one possible implementation, the specific implementation process of S203 includes the following S2031-S2034.

[0146] S2031. Obtain the definition information corresponding to each custom type in the source database.

[0147] Custom types are new types created by users or developers by extending or combining built-in types.

[0148] In one possible implementation, the specific implementation process of S2031 includes:

[0149] Establish a connection with the source database; obtain the query strategy corresponding to the source database type, and query the metadata of each custom type from the source database according to the query strategy; extract the definition information corresponding to each custom type from the metadata of each custom type respectively.

[0150] Different databases employ different query strategies. Specifically, a query strategy involves locating the metadata storage location (such as system tables or views, directory views, and information architecture views) and then retrieving metadata of custom types from that location. For example, for enumeration types: query the table or field storing the enumeration values. For composite types: query the system table storing the table structure or field definitions. For domain types: locate the location of the record's underlying type and constraint information.

[0151] Regarding extracting definition information, for example: for enumeration types: extract the list of enumeration values; for composite types: extract field names, types, and constraints; for domain types: extract the basic type, default value, and constraints.

[0152] By establishing a connection with the source database, metadata queries can be performed subsequently. For different database types, corresponding query strategies are adopted to retrieve the metadata of all custom types. For each custom type retrieved, complete definition information is extracted from the metadata to provide data support for determining subsequent dependencies.

[0153] S2032. Determine the dependency relationships between custom types based on the definition information corresponding to each custom type.

[0154] In one possible implementation, the specific implementation process of S2032 includes:

[0155] For each custom type, based on the definition information corresponding to the custom type, the dependency relationship between the custom type and other custom types is identified, and the dependency relationship is constructed into dependency metadata; a dependency graph is constructed based on the dependency metadata corresponding to each custom type; the nodes in the dependency graph represent custom types, and the directed edges between the nodes represent the dependency relationship between custom types.

[0156] Specifically, from the definition information of custom types, all directly referenced type names or identifiers are extracted, and dependent types are determined. Dependent types include:

[0157] Direct dependency: The definition of type A directly references type B (such as a field of a composite type).

[0158] Indirect dependency: Type A indirectly references type B through an intermediate type C.

[0159] Recursive dependency: Types A and B reference each other.

[0160] For example, the dependencies are as follows:

[0161] Enumeration types: usually have no dependencies.

[0162] Composite types: The type of each field may be a dependency.

[0163] Domain type: depends on the underlying type and constraints.

[0164] Collection type: depends on element type.

[0165] Nodes in the dependency graph: Each custom type is a node in the graph. Edges: If type A depends on type B, then there exists a directed edge from A to B (A→B).

[0166] Alternatively, the dependency graph can be represented as an adjacency list: each node's dependencies are represented by a dictionary, such as {A:[B,C]} indicating that A depends on B and C.

[0167] On the one hand, by automatically identifying dependencies and generating dependency metadata, it avoids omissions or errors that may occur due to manual sorting, ensuring the integrity and accuracy of dependencies. Especially in scenarios where type definitions change frequently (such as microservice architecture and database schema evolution), it can dynamically maintain the correctness of the dependency graph.

[0168] On the other hand, by constructing a dependency graph, the implicit dependencies between custom types are made explicit into a visual structure (nodes + directed edges), enabling developers to intuitively understand the relationship logic between types, reducing the understanding cost of code or data models, and is especially suitable for the maintenance and optimization of large systems or legacy systems.

[0169] S2033. Sort each custom type according to its dependency to obtain the migration order.

[0170] In one possible implementation, the specific implementation process of S2033 includes: sorting each custom type according to the dependency graph using a topological sorting method to obtain the migration order.

[0171] Alternatively, the topological sorting method can be the Kahn algorithm: determine the number of direct dependencies (i.e., the number of incoming edges) of each node; add all nodes with an in-degree of 0 to the queue; remove nodes from the queue and add them to the sorting result; traverse all outgoing edges of the node and decrement the in-degree of the corresponding node by 1; if the in-degree of a node becomes 0, add it to the queue.

[0172] S2034. Convert each custom type into an equivalent field type supported by the target database according to the migration order.

[0173] By analyzing the definition information of custom types, the dependencies between types (such as nested types and reference relationships) are clarified, and a migration order is generated based on the dependency ranking. This ensures that during the migration process, the dependent types are converted first, avoiding conversion failures or data loss due to incomplete dependencies.

[0174] In one possible implementation, the specific implementation process of S2033 includes:

[0175] Based on the source database type and the target database type, the corresponding mapping rule is found from the preset custom type mapping rules; according to the mapping rule, the corresponding type processing function is called for the custom type to be converted; the custom type is converted into an equivalent field type supported by the target database through the type processing function.

[0176] Mapping rules are a set of pre-configured transformation rules used to specify which equivalent type in the target database each custom type (such as enumerations or composite types) in the source database should be converted to, and the specific transformation method (such as field mapping or constraint transformation). In other words, mapping rules are used to specify specific transformation logic (such as enumeration value extraction or field structure transformation) for each mapping relationship, and associate them with specific type processing functions to perform the transformation operation.

[0177] For example, the enumeration type of the source database is mapped to the constraint (VARCHAR+CHECK constraint) of the target database that imposes a range or format restriction on the value of a variable-length string field.

[0178] For example, the table type (composite type) of the source database is mapped to the record (RECORD) type of the target database (PostgreSQL).

[0179] By using preset custom type mapping rules and type processing functions, the type conversion from the source database to the target database can be completed automatically, reducing the time spent on manual operations. This is especially suitable for large-scale database migration or cross-database compatibility adaptation scenarios.

[0180] In addition, custom type mapping rules are stored in the form of dictionaries or configuration files. Adding or modifying rules does not require changing the core code, making it easy to adapt to different database versions or custom types.

[0181] Optionally, during the conversion, types with no dependencies can be processed in parallel to improve migration efficiency.

[0182] Based on the above embodiments, in one possible implementation, S204 specifically includes the following steps:

[0183] The set of field types and the target database type are passed to the database definition table general interface; the interface generates Data Definition Language (DDL) statements that conform to the syntax rules of the target database; the target table corresponding to the target database is created based on the DDL statements to achieve automated table structure definition and creation.

[0184] The general interface for database definition tables encapsulates the structured query language (SQL) logic for various database definition tables, and this interface can automatically combine DDL statements that conform to the syntax rules of the target database based on the input parameters.

[0185] DDL statements are used to define and manage the structure of a database.

[0186] For example, you can use the SQL CREATE TABLE statement to create the target table and define its structure and field attributes.

[0187] This automated approach effectively masks the differences in field types between different databases, enabling users unfamiliar with databases to quickly and accurately obtain the DDL statements defining the target database tables. This allows them to quickly and correctly create the target tables based on the DDL statements, thereby improving the efficiency of data synchronization or migration.

[0188] Figure 3 A flowchart illustrating another method for creating tables in a heterogeneous database provided in this application is shown below. Figure 3 As shown, in this embodiment... Figure 2 Based on the examples, the method for creating tables in heterogeneous databases is described in detail. The method includes:

[0189] S301. Determine the source database type corresponding to the source database and the target database type corresponding to the target database.

[0190] S302, Pass the source database type and target database type to the field type conversion interface.

[0191] If the source database type is the same as the target database type, then execute S303.

[0192] If the source database type is different from the target database type, then execute S304-S307 and S308-S312 respectively.

[0193] This embodiment does not limit the execution order of S304-S307 and S308-S312. For example, S304-S307 can be executed first and then S308-S312 can be executed, or S308-S312 can be executed first and then S304-S307 can be executed, or S304-S307 and S308-S312 can be executed in parallel.

[0194] For ease of representation, Figure 3 The following examples illustrate how S304-S307 are executed first, followed by S308-S312.

[0195] S303. Obtain the type of each first field of the source database according to the source database type, and write the type of each first field of the source database into the field type set.

[0196] After S303, execute S313.

[0197] S304. Based on the preset field type dictionary, traverse the first field type in the source database.

[0198] After S304, execute S305.

[0199] S305. For each first field type encountered during traversal, find the corresponding second field type in the target database based on the preset field type conversion relation dictionary.

[0200] If the corresponding second field type is found in the target database based on the field type conversion relation dictionary, then S306 is executed.

[0201] If the corresponding second field type is not found in the relation dictionary based on the field type conversion, then execute S307.

[0202] S306. Write the found second field type into the field type set.

[0203] After S306, execute S308.

[0204] S307. Write the default field types in the field type dictionary that are the same as the target database type into the field type set.

[0205] After S307, execute S308.

[0206] S308. Obtain the definition information corresponding to each custom type in the source database.

[0207] S309. Determine the dependency relationships between custom types based on the definition information corresponding to each custom type.

[0208] S310. Sort each custom type according to its dependency to obtain the migration order.

[0209] S311. Convert each custom type into an equivalent field type supported by the target database according to the migration order.

[0210] S312. Write the equivalent field type into the field type set.

[0211] S313. Pass the set of field types and the target database type to the database definition table general interface.

[0212] S314. Generate DDL statements that conform to the syntax rules of the target database.

[0213] S315. Create the target table corresponding to the target database based on the DDL statement.

[0214] The implementation of each step in this embodiment is the same as that in the above embodiment, and will not be repeated here.

[0215] Figure 4 A schematic diagram of the heterogeneous database table creation device provided in this application is shown below. Figure 4 As shown, the heterogeneous database table creation device 40 provided in this embodiment includes:

[0216] The determination module 401 is used to determine the source database type corresponding to the source database and the target database type corresponding to the target database.

[0217] The lookup module 402 is used to look up the corresponding second field type in the target database for each first field type in the source database, and write the found second field type into the field type set.

[0218] The conversion module 403 is used to convert each custom type in the source database into an equivalent field type in the target database according to the dependency relationship between the custom types, and write the equivalent field types into the field type set;

[0219] Create module 404, which is used to create the target table corresponding to the target database based on the set of field types and the target database type.

[0220] In one possible implementation, the conversion module 403 includes:

[0221] The retrieval unit is used to retrieve the definition information corresponding to each custom type in the source database.

[0222] The determination unit is used to determine the dependency relationships between custom types based on the definition information corresponding to each custom type.

[0223] The sorting unit is used to sort the custom types according to their dependencies to obtain the migration order;

[0224] The transformation unit is used to convert each custom type into an equivalent field type supported by the target database according to the migration order.

[0225] In one possible implementation, the acquiring unit is specifically used for:

[0226] Establish a connection with the source database;

[0227] Obtain the query strategy corresponding to the source database type, and query the metadata of each custom type from the source database according to the query strategy;

[0228] Extract the definition information corresponding to each custom type from the metadata of each custom type.

[0229] In one possible implementation, the determining unit is specifically used for:

[0230] For each custom type, based on the definition information corresponding to the custom type, identify the dependency relationship between the custom type and other custom types, and build the dependency relationship into dependency metadata;

[0231] A dependency graph is constructed based on the dependency metadata corresponding to each custom type; the nodes in the dependency graph represent custom types, and the directed edges between nodes represent the dependency relationships between custom types.

[0232] Sorting unit, specifically used for:

[0233] A topological sorting method is used to sort each custom type according to the dependency graph to obtain the migration order.

[0234] In one possible implementation, the conversion unit is specifically used for:

[0235] Based on the source database type and the target database type, the corresponding mapping rule is found from the preset custom type mapping rules;

[0236] According to the mapping rules, the corresponding type processing function is called for the custom type to be converted;

[0237] Use type handling functions to convert custom types into equivalent field types supported by the target database.

[0238] In one possible implementation, the lookup module 402 is specifically used for:

[0239] Based on the preset field type dictionary, iterate through the first field type in the source database;

[0240] For each first field type encountered during the traversal, the corresponding second field type in the target database is searched according to the preset field type conversion relation dictionary, and the found second field type is written into the field type set;

[0241] In one possible implementation, the lookup module 402 is further configured to:

[0242] If no corresponding second field type is found based on the field type conversion relation dictionary, then the default field type in the field type dictionary that is the same as the target database type is written into the field type set.

[0243] In one possible implementation, module 404 is created specifically for:

[0244] Pass the set of field types and the target database type to the database definition table's general interface;

[0245] Generate data definition language statements that conform to the syntax rules of the target database through the database definition table general interface;

[0246] Create the target table corresponding to the target database based on the data definition language statements.

[0247] The heterogeneous database table creation device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0248] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 5 As shown, the electronic device 10 provided in this embodiment includes a processor 101 and a memory 102 communicatively connected to the processor 101. The processor 101 and the memory 102 are connected via a bus.

[0249] The memory 102 stores computer-executable instructions; the processor 101 executes the computer-executable instructions stored in the memory 102 to implement the heterogeneous database table creation method provided in this application.

[0250] The specific implementation process of processor 101 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0251] Buses can be Industry Standard Architecture (ISA) buses, Peripheral Component Interconnect (PCI) buses, or Extended Industry Standard Architecture (EISA) buses, etc. Buses can be categorized into address buses, data buses, control buses, etc.

[0252] The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise as required.

[0253] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores computer-executable instructions that, when executed by a processor, are used to implement the heterogeneous database table creation method provided in this application.

[0254] In an exemplary embodiment, a computer program product is also provided, including a computer program, which, when executed by a processor, is used to implement the heterogeneous database table creation method provided in this application.

[0255] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0256] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0257] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0258] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or in the form of software program modules.

[0259] Unless otherwise specified, memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as USB flash drives, random-access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), enhanced dynamic random-access memory (EDRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), high-bandwidth memory (HBM), or hybrid memory cube (HMC) and other media capable of storing program code.

[0260] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0261] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0262] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A heterogeneous database table building method, characterized by, The method comprises the following steps: determining a source database type corresponding to a source database and a target database type corresponding to a target database; for each first field type in the source database, finding a corresponding second field type in the target database, and writing the found second field type into a field type set; for each custom type in the source database, converting the custom type into an equivalent field type in the target database according to a dependency relationship between custom types, and writing the equivalent field type into the field type set; creating a target table corresponding to the target database according to the field type set and the target database type.

2. The method of claim 1, wherein, The step of converting each custom type in the source database into an equivalent field type in the target database according to a dependency relationship between custom types comprises the following steps: obtaining definition information corresponding to each custom type in the source database; determining the dependency relationship between custom types according to the definition information corresponding to each custom type; sorting each custom type according to the dependency relationship to obtain a migration order; converting each custom type into an equivalent field type supported by the target database according to the migration order.

3. The method of claim 2, wherein, The step of obtaining definition information corresponding to each custom type in the source database comprises the following steps: establishing a connection with the source database; obtaining a query strategy corresponding to the source database type, and querying metadata of each custom type from the source database according to the query strategy; extracting definition information corresponding to each custom type from the metadata of each custom type.

4. The method of claim 2, wherein, The step of determining the dependency relationship between multiple custom types according to the definition information corresponding to each custom type comprises the following steps: for each custom type, identifying a dependency relationship between the custom type and other custom types according to the definition information corresponding to the custom type, and constructing the dependency relationship into dependency metadata; constructing a dependency graph according to the dependency metadata corresponding to each custom type; a node in the dependency graph represents a custom type, and a directed edge between nodes represents a dependency relationship between custom types; The step of sorting each custom type according to the dependency relationship to obtain a migration order comprises the following step: sorting each custom type according to the dependency graph by using a topological sorting method to obtain the migration order.

5. The method of claim 2, wherein, The step of converting each custom type into an equivalent field type supported by the target database according to the migration order comprises the following steps: finding a corresponding mapping rule from a preset custom type mapping rule according to the source database type and the target database type; calling a corresponding type processing function for a custom type to be converted according to the mapping rule; converting the custom type into an equivalent field type supported by the target database by using the type processing function.

6. The method of claim 1, wherein, The step of searching for the corresponding second field type in the target database for each first field type in the source database and writing the found second field type into the field type set includes: Based on a preset field type dictionary, traverse the first field type in the source database; For each of the first field types encountered during the traversal, the corresponding second field type in the target database is searched according to a preset field type conversion relationship dictionary, and the found second field type is written into the field type set.

7. The method of claim 6, wherein, The method further includes: If no corresponding second field type is found according to the field type conversion relationship dictionary, then the default field type in the field type dictionary that is the same as the target database type is written into the field type set.

8. The method of claim 1, wherein, The step of creating the target table corresponding to the target database based on the set of field types and the target database type includes: Pass the set of field types and the target database type to the database definition table general interface; The database definition table general interface is used to generate data definition language statements that conform to the syntax rules of the target database. Create the target table corresponding to the target database according to the data definition language statement.

9. A heterogeneous database table building apparatus, characterized by comprising: include: The determination module is used to determine the source database type corresponding to the source database and the target database type corresponding to the target database. The lookup module is used to look up the corresponding second field type in the target database for each first field type in the source database, and write the found second field type into the field type set. The conversion module is used to convert each custom type in the source database into an equivalent field type in the target database according to the dependency relationship between the custom types, and write the equivalent field type into the field type set; A creation module is used to create a target table corresponding to the target database based on the set of field types and the target database type.

10. An electronic device, comprising: include: A processor and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images