Database version unified management method and system

Abstract

The invention discloses a database version unified management method and system.The method comprises the steps that database scripts corresponding to databases of different versions are obtained, and the database scripts are extracted from local micro-service resource directories in all the databases; all the database scripts are uploaded; the script automatic uploading supports two modes of client component integration and non-invasive integration; in a test environment, executing each uploaded database script, and issuing an execution result; deploying a scheduling source code generated by the release result to start a production environment; and in the production environment, scheduling the database scripts based on a preset sequence so as to realize management of the databases of different versions.

Description

Technical Field

[0001] The present invention relates to the technical field of database management, and in particular to a method and system for unified management of database versions. Background Art

[0002] Database version management is an important part of the development and operation and maintenance process. It can standardize database change version management and have a far-reaching impact on development and operation and maintenance.

[0003] In the process of software development and operation and maintenance, database version management is an important task, which is related to database change control and audit. With the development of microservices, there are more and more services, and different services may have different development languages ​​and different databases, so different database versions contain different scripts. However, the existing technology cannot effectively separate the script execution operation from the client in the process of database version management, resulting in the inability to correctly execute the script in some cases, increasing the difficulty of judging the script execution status, thereby reducing system performance.

[0004] It can be seen that how to uniformly manage database versions has become a technical problem that needs to be urgently solved by those skilled in the art. Summary of the invention

[0005] The present invention provides a method and system for unified management of database versions to solve the problem of how to uniformly manage database versions to meet the scenario requirements of multiple services, multiple development languages ​​and multiple data sources in a microservice environment.

[0006] In order to solve the above technical problems, an embodiment of the present invention provides a method for unified management of database versions, including:

[0007] Respectively obtain database scripts corresponding to different versions of databases, wherein the database scripts are extracted from the local microservice resource directory in each of the databases;

[0008] Automatically upload each of the database scripts, wherein the automatic upload supports two modes: client component integration and non-invasive integration;

[0009] In the test environment, execute each of the uploaded database scripts and publish the execution results;

[0010] Deploy the scheduling source code generated by the release results to start the production environment;

[0011] In the production environment, each of the database scripts is scheduled in a confirmed execution order based on a preset microservice orchestration order to achieve management of databases of different versions.

[0012] Furthermore, each database script is automatically uploaded, and the automatic upload supports two modes of client component integration and non-invasive integration, including:

[0013] Each of the database scripts is associated with a corresponding local microservice to automatically upload the database execution script and the database rollback script; the non-invasive integration mode of the automatic upload only dynamically injects the client component through a command when the microservice is started to realize the automatic upload.

[0014] Furthermore, the scheduling of each of the database scripts in a confirmed execution order based on a preset microservice orchestration order includes:

[0015] Arrange the execution order of the microservices corresponding to the database script, and confirm the first execution order according to the arrangement result;

[0016] In the first execution order, the database script is named according to a preset naming rule, and the second execution order is determined according to the version number of the named database script;

[0017] The database script is scheduled for execution according to the second execution order.

[0018] Furthermore, the scheduling of each of the database scripts in the confirmed execution order also includes:

[0019] The database script is scheduled to be executed by manual triggering or automatic triggering.

[0020] Furthermore, it also includes:

[0021] In the process of scheduling each of the database scripts, a change audit log view of the database is queried through multiple dimensions; the change audit log view stores the execution status of the database script.

[0022] Another embodiment of the present invention provides a unified database version management system, including:

[0023] A database script acquisition module is used to respectively acquire database scripts corresponding to different versions of databases, wherein the database scripts are extracted from the local microservice resource directory in each of the databases;

[0024] A database script uploading module, used for automatically uploading each of the database scripts, wherein the automatic uploading supports two modes: client component integration and non-intrusive integration;

[0025] A database script testing module is used to execute each of the uploaded database scripts in a test environment and publish the execution results;

[0026] The deployment startup module is used to deploy the scheduling source code generated by the publishing results to start the production environment;

[0027] The database script scheduling module is used to schedule each of the database scripts in a confirmed execution order based on a preset microservice orchestration order in the production environment to achieve management of databases of different versions.

[0028] Furthermore, the database script upload module is specifically used for:

[0029] Each of the database scripts is associated with a corresponding local microservice to automatically upload the database execution script and the database rollback script; the non-invasive integration mode of the automatic upload only dynamically injects the client component through a command when the microservice is started to realize the automatic upload.

[0030] Furthermore, the database script scheduling module is specifically used to:

[0031] Arrange the execution order of the microservices corresponding to the database script, and confirm the first execution order according to the arrangement result;

[0032] In the first execution order, the database script is named according to a preset naming rule, and the second execution order is determined according to the version number of the named database script;

[0033] The database script is scheduled for execution according to the second execution order.

[0034] Furthermore, the database script scheduling module is also used to:

[0035] The database script is scheduled to be executed by manual triggering or automatic triggering.

[0036] Furthermore, the system also includes an audit log view module, which is specifically used to:

[0037] In the process of scheduling each of the database scripts, a change audit log view of the database is queried through multiple dimensions; the change audit log view stores the execution status of the database script.

[0038] Compared with the prior art, the embodiments of the present invention have the following advantages:

[0039] The embodiment of the present invention builds a unified database version management system that can meet the needs of multi-service, multi-development language, and multi-data source scenarios in a microservice environment. By utilizing the microservice architecture, it can be quickly integrated into the microservice environment and the script execution operation can be separated from the client. It supports two modes: interface operation and automatic client upload execution, which can meet the needs of microservices in different development languages. At the same time, it supports providing a complete audit view for database version management from the dimensions of microservices, database scripts, and developers. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic diagram of the process of a unified database version management method in one embodiment of the present invention;

[0041] Figure 2 This is a diagram of the architecture of a unified database management platform in one embodiment of the present invention;

[0042] Figure 3 It is a schematic diagram of the structure of a unified database version management system in one embodiment of the present invention. DETAILED DESCRIPTION

[0043] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. The purpose of providing these embodiments is to make the disclosure of the present invention more thorough and comprehensive. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0044] In the description of this application, the terms "first", "second", "third", etc. are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", "third", etc. may explicitly or implicitly include one or more of the feature. In the description of this application, unless otherwise specified, "plurality" means two or more.

[0045] In the description of the present application, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be a connection between the two elements. The terms "vertical", "horizontal", "left", "right", "upper", "lower" and similar expressions used herein are only for illustrative purposes, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. The term "and / or" used herein includes any and all combinations of one or more related listed items. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0046] In the description of this application, it should be noted that, unless otherwise defined, all technical and scientific terms used in the present invention have the same meaning as those commonly understood by those skilled in the art. The terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood by specific circumstances.

[0047] An embodiment of the present invention provides a method for unified management of database versions. For details, see Figure 1 , Figure 1 The figure shows a flow chart of a unified database version management method in one embodiment of the present invention, which includes the following steps:

[0048] S1. Obtain database scripts corresponding to different versions of databases respectively, wherein the database scripts are extracted from a local microservice resource directory in each of the databases.

[0049] It can be understood that in this embodiment, the database script is saved in the local microservice source directory according to the specification. After the microservice is started, the database script is automatically synchronized to the database management and scheduling center through the integrated client component or non-invasive command injection method. The management and scheduling center will then schedule the execution of the database script. This operation can actually separate the database script execution operation from the client. For applications that do not support client components, upload them through the interface provided by the management and scheduling center.

[0050] It is worth noting that the database script uploaded synchronously through the client component should contain information such as execution script, rollback script, service code, test user, and database change description.

[0051] S2. Automatically upload each of the database scripts, and the automatic upload supports two modes: client component integration and non-invasive integration. After obtaining the database scripts stored in the local microservice, uploading the scripts through these two modes can provide users with more flexible options. Users can choose the most suitable integration method according to their needs and scenarios to achieve more efficient and reliable automatic upload of database scripts.

[0052] Specifically, the non-invasive integration mode refers to the automatic upload of files by dynamically injecting commands or scripts without modifying the target system or application source code or execution environment. The integrated client component mode refers to the integration of specific automatic upload components or plug-ins in the client software, and the automatic upload function of files is realized through these components or plug-ins.

[0053] In this embodiment, each of the database scripts is associated with the corresponding local microservice to upload the database execution script and the database rollback script; it is worth noting that the non-invasive integration mode of automatic upload only dynamically injects the client component through commands when the microservice is started to realize automatic upload. As an example, in some embodiments of the present invention, the database script can be uploaded through the interface provided by the management and scheduling center platform. In other words, both interface operation and client automatic upload execution are supported to meet the needs of microservices with different development languages. Microservices that do not support client components can choose to operate through the interface.

[0054] The database script includes two files: the execution script and the rollback script. During the upload process, you need to fill in the developer, change description and other information. When uploading the script, you need to select the corresponding microservice, so that the uploaded script is associated with the microservice. Therefore, it is understandable that when the management and scheduling center platform schedules the script execution in the dimension of microservices, all related scripts belonging to this service will be executed. And because the microservice is configured with the corresponding database connection information, and the script is associated with the microservice, it is possible to achieve unified scheduling management of different microservice scripts in the same library / sub-library on one platform.

[0055] S3. In the test environment, execute each of the uploaded database scripts and publish the execution results.

[0056] As you can understand, the test environment is used to perform various testing activities, including unit testing, integration testing, system testing, and user acceptance testing. Its main purpose is to verify the functionality, performance, and stability of the database to ensure that the expected quality standards are met before it is released to the production environment. The production environment is the environment where the database is officially operated and provides services to the outside world. It is the final delivery environment in the database life cycle and is directly facing users, so it has extremely high requirements for stability, performance, and security.

[0057] In this step, that is, in the test environment, after the database script is uploaded to the management and scheduling center and successfully executed, the successfully executed database script needs to be published. Only after the successful publishing, the script file can enter the storage path of the production environment. It is worth noting that the release can be revoked.

[0058] Therefore, for operational safety, after the database script is synchronized through the client or uploaded through the interface, it will be automatically triggered for scheduling and execution only when the current environment is a test environment. Database scripts in the production environment will only be scheduled and executed after the operation is published through the interface.

[0059] It is understandable that after the test environment verifies that the database script is uploaded successfully and released, the published script will be downloaded from the management and scheduling center platform, synchronized to the scheduling source code of the management and scheduling center platform, and submitted to wait for production release. The operation of this step provides support for the migration of database scripts from the test environment to the production environment, ensuring the smooth release of the script.

[0060] S4-S5, deploy the scheduling source code generated by the publishing result to start the production environment; in the production environment, schedule each of the database scripts in the confirmed execution order based on the preset microservice orchestration order to achieve management of different versions of the database.

[0061] In the production release phase, before scheduling in the production environment, the production scheduling source code is packaged and deployed to the production environment, and then the production environment is started, at which time the script will be automatically scheduled for execution.

[0062] As for the scheduling of database scripts, each of the database scripts is scheduled according to a preset order. It can be understood that one microservice corresponds to multiple scripts, and the execution order of the microservices can be dynamically arranged in the interface, while the execution order of the scripts is executed according to the version number. When the script is created, the execution order is determined and cannot be dynamically arranged.

[0063] Based on this, in this implementation, the execution order of the microservices corresponding to the database script is arranged, and the first execution order is determined according to the arrangement result, that is, the microservice scheduling order is arranged, and the microservice scheduling order is determined according to the arrangement order. The first execution order here is the determined microservice scheduling order.

[0064] In this embodiment, under the first execution order, the database script is named according to a preset naming rule, and the second execution order is determined according to the version number of the named database script. The database script is executed and scheduled according to the second execution order. The second execution order here is the execution order of the script.

[0065] In some embodiments of the present invention, the database script name is named according to the naming rule of "V major version number__ minor version number_script name.sql". As an example, a database script is named: V2.1.1__20240801_init.sql. The database scripts of the same service will be executed from small to large according to the major version number. If the major version numbers are the same, they will be executed from small to large according to the minor version number. The execution order of different script files of the same service is distinguished by the size of the version number.

[0066] Since multiple scripts may be related to each other, in order to avoid confusion in script execution, when a script with a version number fails to execute, the next version of the script will not be executed. After a script with a larger version number is executed, a new script with a smaller version number will not be executed if it is added to the same service later, because it is necessary to ensure that the scripts are executed in order from small to large version numbers, otherwise it will cause confusion in script execution and affect the execution results of higher version numbers. For scripts that are successfully executed, the rollback operation can be triggered through the interface.

[0067] In this embodiment, the execution scheduling of the database script can be manually triggered or automatically triggered. Specifically, the automatically executed script is immediately triggered to be scheduled for execution after being uploaded to the management and scheduling center platform, while the manually triggered script is in a ready state after being uploaded to the management and scheduling center platform, and the user triggers the script execution through a unified button.

[0068] It is worth noting that, in the process of scheduling each of the database scripts, the change audit log view of the database can be queried in multiple dimensions; the change audit log view stores the execution status of the database scripts.

[0069] It is understandable that in the embodiment of the present invention, the user queries the change log of the database through multiple dimensions of microservices, databases, and developers (i.e., script submitter dimensions). As an example, the statistics of script execution success and failure can be queried from the script submitter dimension.

[0070] In summary, the embodiment of the present invention provides a unified database version management method, which synchronizes the database script from the local microservice resource directory to the scheduling center, thereby realizing two modes of script interface operation and client automatic upload execution to meet the needs of microservices with different development languages. In the process of script execution scheduling, the test environment and the production environment are configured respectively, and the execution order of the script is defined by the version number naming rule, and an automatic or manual execution method is provided to schedule the script execution, thereby realizing the management of different versions of databases.

[0071] In some embodiments of the present invention, a database version unified management platform architecture is provided as a reference for an embodiment. Specifically, please refer to Figure 2 , Figure 2 The following is a diagram showing the architecture of a unified database management platform in one embodiment of the present invention. The above management architecture is described in detail below.

[0072] from Figure 2 It can be seen that the database management platform designed in the embodiment of the present invention adopts a microservice architecture, including a management and scheduling center and client components, and is a front-end and back-end separated design, with service integration gateway, nacos and other mainstream microservice components.

[0073] First, the configuration of this architecture is described:

[0074] Client service: refers to the service that integrates the client plug-in of the database unified management platform. By integrating the client plug-in, the database script can be synchronized. The plug-in supports two modes: code integration and non-invasive integration. Non-invasive integration only requires dynamic injection through commands when the service is started.

[0075] Client: refers to the user who can upload scripts through the page for scheduling, querying audit logs, etc.

[0076] Application Management Service: An interface for operating the service management page and receiving client service synchronization requests.

[0077] Script scheduling engine: refers to the service responsible for scheduling and executing database scripts.

[0078] Microservice database: refers to the microservice database that needs to update database operations, which is scheduled by the script scheduling engine.

[0079] Service registration center: nacos registration center.

[0080] Service Configuration Center: nacos Configuration Center.

[0081] Service gateway: gateway.

[0082] It can be seen that the database version unified management platform architecture of the embodiment of the present invention configures the execution mode of the script in the management and scheduling center according to the complexity of the microservices, supporting automatic triggering execution and interface operation execution respectively. In the script automatic execution mode, the management and scheduling center supports GitOps, CI / CD and other modes for automated management, and the automated operation and maintenance tools perform version control and automated deployment execution. It supports containerized deployment, and the startup order of the management and scheduling center can be controlled by the container orchestration tool dockercompose.

[0083] The platform distinguishes services according to the concept of services, establishes services and corresponding data source settings, supports one service corresponding to one data source, and adapts to the scenario of microservice sub-library. In addition to supporting traditional relational databases such as MySQL and PostgreSQL, the data source of the management and scheduling center also supports the distributed database ClickHourse in big data scenarios.

[0084] An embodiment of the present invention provides a unified database version management system. For details, see Figure 3 , Figure 3 The following is a schematic diagram of the structure of a unified database version management system in one embodiment of the present invention, including:

[0085] A database script acquisition module M1 is used to respectively acquire database scripts corresponding to different versions of databases, wherein the database scripts are extracted from the local microservice resource directory in each of the databases;

[0086] A database script uploading module M2, used for automatically uploading each of the database scripts, wherein the automatic uploading supports two modes: client component integration and non-invasive integration;

[0087] The database script test module M3 is used to execute each of the uploaded database scripts in a test environment and publish the execution results;

[0088] The deployment startup module M4 is used to deploy the scheduling source code generated by the publishing result to start the production environment;

[0089] The database script scheduling module M5 is used to schedule each of the database scripts in the confirmed execution order based on the preset microservice orchestration order in the production environment to achieve management of different versions of databases.

[0090] It can be understood that in this embodiment, the database script is saved in the local microservice resource directory through the specification, and the database script acquisition module M1 is used to automatically synchronize the database script to the database management and scheduling center through the client component after the microservice is started, and the management and scheduling center will subsequently schedule the execution of the database script. This operation can actually separate the database script execution operation from the client. For applications that do not support client components, upload them through the interface provided by the management and scheduling center.

[0091] Furthermore, each database script is automatically uploaded through the database script upload module M2, and the database script upload module M2 is specifically used to associate each database script with the corresponding local microservice to automatically upload the database execution script and the database rollback script; the non-invasive integration mode of the automatic upload only dynamically injects the client component through commands when the microservice is started to realize automatic upload. After obtaining the database script stored in the local microservice, uploading the script through these two modes can provide users with more flexible options.

[0092] Specifically, in this embodiment, each of the database scripts is associated with the corresponding local microservice to upload the database execution script and the database rollback script; it is worth noting that the non-invasive integration mode of automatic upload only dynamically injects the client component through commands when the microservice is started to achieve automatic upload. As an example, in some embodiments of the present invention, the database script can be uploaded through the interface provided by the management and scheduling center platform. In other words, both interface operation and client automatic upload execution are supported to meet the needs of microservices with different development languages. Microservices that do not support client components can choose to operate through the interface.

[0093] The database script includes two files: the execution script and the rollback script. During the upload process, you need to fill in the developer, change description and other information. When uploading the script, you need to select the corresponding microservice, so that the uploaded script is associated with the microservice. Therefore, it is understandable that when the management and scheduling center platform schedules the script execution in the dimension of microservices, all related scripts belonging to this service will be executed. And because the microservice is configured with the corresponding database connection information, and the script is associated with the microservice, it is possible to achieve unified scheduling management of different microservice scripts in the same library / sub-library on one platform.

[0094] Furthermore, through the database script test module M3, in the test environment, after the database script is uploaded to the management and scheduling center and executed successfully, the successfully executed database script needs to be published, and the script file after successful publishing can enter the storage path of the production environment. It is worth noting that it can be revoked after publishing.

[0095] Therefore, for operational safety, after the database script is synchronized through the client or uploaded through the interface, it will be automatically triggered for scheduling and execution only when the current environment is a test environment. Database scripts in the production environment will only be scheduled and executed after the operation is published through the interface.

[0096] It is understandable that after the test environment verifies that the database script is uploaded successfully and released, the published script will be downloaded from the management and scheduling center platform, synchronized to the scheduling source code of the management and scheduling center platform, and submitted to wait for production release. The operation of this step provides support for the migration of database scripts from the test environment to the production environment, ensuring the smooth release of the script.

[0097] Furthermore, by deploying the startup module M4, before scheduling in the production environment, the production scheduling source code is packaged and deployed to the production environment, and then the production environment is started, and the execution script will be automatically scheduled.

[0098] And each of the database scripts is scheduled through the database script scheduling module M5.

[0099] As an example, in this implementation, the execution order of the microservices corresponding to the database script is orchestrated, and the first execution order is confirmed according to the orchestration result, that is, the microservice scheduling order is orchestrated, and the microservice scheduling order is confirmed according to the orchestration order.

[0100] In the first execution order, the database script is named according to a preset naming rule, and the second execution order is confirmed according to the version number of the named database script; and the database script is manually or automatically triggered and scheduled for execution according to the second execution order.

[0101] Furthermore, as an example, the system also schedules the database script by manually triggering or automatically triggering the database script through the database script scheduling module M5.

[0102] The system further comprises an audit log view module M6, which is used to query the change audit log view of the database through multiple dimensions during the process of scheduling each of the database scripts; the change audit log view stores the execution status of the database scripts.

[0103] Since the technical features and technical effects of the unified database version management system proposed in the embodiment of the present invention are the same as the technical features and technical effects of the unified database version management method proposed in the embodiment of the present invention, they are not elaborated here.

[0104] The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A method for unified management of database versions, characterized in that: include: Respectively obtain database scripts corresponding to different versions of databases, wherein the database scripts are extracted from the local microservice resource directory in each of the databases; Automatically upload each of the database scripts, wherein the automatic upload supports two modes: client component integration and non-invasive integration; In the test environment, execute each of the uploaded database scripts and publish the execution results; Deploy the scheduling source code generated by the release results to start the production environment; In the production environment, each of the database scripts is scheduled in a confirmed execution order based on a preset microservice orchestration order to achieve management of databases of different versions.

2. The method for unified database version management according to claim 1, characterized in that: The automatic uploading of each database script supports two modes: client component integration and non-invasive integration, including: Each of the database scripts is associated with a corresponding local microservice to automatically upload the database execution script and the database rollback script; the non-invasive integration mode of the automatic upload only dynamically injects the client component through a command when the microservice is started to realize the automatic upload.

3. The method for unified database version management according to claim 1, characterized in that: The scheduling of each of the database scripts in a confirmed execution order based on a preset microservice orchestration order includes: Arrange the execution order of the microservices corresponding to the database script, and confirm the first execution order according to the arrangement result; In the first execution order, the database script is named according to a preset naming rule, and the second execution order is determined according to the version number of the named database script; The database script is scheduled for execution according to the second execution order.

4. The method for unified database version management according to claim 1, characterized in that: The step of scheduling each of the database scripts in the confirmed execution order further includes: The database script is scheduled to be executed by manual triggering or automatic triggering.

5. The method for unified database version management according to claim 1, characterized in that: Also includes: In the process of scheduling each of the database scripts, query the change audit log view of the database through multiple dimensions; The change audit log view stores the execution status of the database script.

6. A unified database version management system, characterized in that: The system comprises: A database script acquisition module is used to respectively acquire database scripts corresponding to different versions of databases, wherein the database scripts are extracted from the local microservice resource directory in each of the databases; A database script uploading module, used for automatically uploading each of the database scripts, wherein the automatic uploading supports two modes: client component integration and non-invasive integration; A database script testing module is used to execute each of the uploaded database scripts in a test environment and publish the execution results; The deployment startup module is used to deploy the scheduling source code generated by the publishing results to start the production environment; The database script scheduling module is used to schedule each of the database scripts in a confirmed execution order based on a preset microservice orchestration order in the production environment to achieve management of databases of different versions.

7. The unified database version management system according to claim 6, characterized in that: The database script upload module is specifically used for: Each of the database scripts is associated with a corresponding local microservice to automatically upload the database execution script and the database rollback script; the non-invasive integration mode of the automatic upload only dynamically injects the client component through a command when the microservice is started to realize the automatic upload.

8. The unified database version management system according to claim 6, characterized in that: The database script scheduling module is specifically used for: Arrange the execution order of the microservices corresponding to the database script, and confirm the first execution order according to the arrangement result; In the first execution order, the database script is named according to a preset naming rule, and the second execution order is determined according to the version number of the named database script; The database script is scheduled for execution according to the second execution order.

9. The unified database version management system according to claim 6, characterized in that: The database script scheduling module is also used for: The database script is scheduled to be executed by manual triggering or automatic triggering.

10. The unified database version management system according to claim 6, characterized in that: The system also includes an audit log view module, which is specifically used to: In the process of scheduling each of the database scripts, a change audit log view of the database is queried through multiple dimensions; the change audit log view stores the execution status of the database script.

Images