Version control method and system for database

Abstract

The invention discloses a database version control method and system, and relates to a database technology, and the method comprises the steps: configuring an engineering table, a version submission table and various business data tables for a database; based on the field of the current version in the project table, under the condition that a project is created, the value of the field of the current version is configured to be an initial value, and progressive increase is carried out when any submission is carried out subsequently; forming a recorded database version state based on a first version field, a last version field and a submission state field of the business data table in combination with a current version field in the engineering table; and realizing a version control process according to operation and submission conditions based on records of database version states. According to the method and the device, a version control function similar to Git can be provided for a scene in which a database is used as a data storage mode and version control is business.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database version control method and system. Background Art

[0002] Currently, version control technologies are relatively mature for text-based data such as program code, such as Git and SVN, which facilitate operations such as version submission, version query, version rollback, and version comparison. However, in real-world scenarios, a large amount of data is stored in a structured form in databases, and this data also generally requires version control. For example, industrial design, financial information, and personnel information maintained in databases cannot be version controlled using tools such as Git and SVN because this data is not stored in text format.

[0003] In the database field, there are also some database version control tools, such as Liquibase and Flyway. These tools implement version control for the entire database. They are mainly used for historical rollback of the entire database. The management granularity is too coarse, and it is impossible to directly query historical data without rolling back the database. It is even more impossible to achieve direct record-level comparison between historical versions.

[0004] Some existing invention patents related to "database" and "version control", such as "Database version management method, device and electronic device (Application Publication No. CN 115167841 A)", "XML-based database version management and automatic structure migration method (Application Publication No. CN 116166635 A)", "Method, device, equipment and medium for data model version management based on metamodel (Application Publication No. CN 118012847 A)", "A database version management method based on database snapshots (Application Publication No. CN 108255994 A)", "A database DDL management method and device (Application Publication No. CN112445781 A)", etc., all perform version management on the entire database for the purpose of rollback, migration and upgrade of database data or database structure, but cannot achieve version control when different versions of data coexist, that is, they do not have the capability of version control itself, which is a business. Summary of the Invention

[0005] The embodiments of the present application provide a database version control method and system, which can provide version control functions similar to Git for scenarios where a database is used as a data storage method and version control is a business.

[0006] The present invention provides a database version control method, including:

[0007] The database is configured with a project table, a version submission table, and business data tables of various categories, wherein the project table, the version submission table, and business data tables of various categories have corresponding fields set based on the project ID;

[0008] Based on the current version field in the project table, when a project is created, the value of the current version field is configured as the initial value, and is incremented for each subsequent submission;

[0009] Based on the first version field, the last version field and the submission status field of the business data table, combined with the current version field in the engineering table, a database version status of the record is formed;

[0010] Based on the record of database version status, the version control process is implemented according to operations and submissions.

[0011] Optionally, the project table includes the following fields: project ID, project name, current version, and project creation time, which is recorded as project_table(id, project_name, current_version, project_create_time);

[0012] The version submission table contains the following fields: submission ID, project ID, version, submission time, and description information, which is recorded as commit_table(id, project_id, version, commit_time, commit_msg);

[0013] The auxiliary fields of the business data table used for version control include: record ID, project ID, entity ID, first version, last version, and submission status, which are recorded as data_table(id, project_id, entity_id, first_version, last_version, committed, [property1], [property2], ...). The remaining fields are business attributes, among which the project ID is a foreign key pointing to the project table ID field, the first version is the version when the record is first added to the business data table; the last version is the last version before the record is deleted, and the submission status indicates whether the record has been submitted.

[0014] Optionally, based on the first version field, the last version field, and the submission status field of the business data table, combined with the current version field in the engineering table, the database version status of the record includes: added unsubmitted status, available submitted status, deleted unsubmitted status, and deleted submitted status, where:

[0015] Added records with uncommitted status satisfying {first_version: current_version, last_version:NULL, committed: FALSE};

[0016] Available committed status is the record that satisfies {last_version: NULL, committed: TRUE};

[0017] Delete the records whose uncommitted status satisfies {last_version: current_version-1, committed:TRUE};

[0018] The records whose committed status satisfies {last_version <= current_version-2, committed:TRUE} have been deleted.

[0019] Optionally, based on the record of database version status, the version control process based on operations and submissions includes:

[0020] Based on the new operation, the triggering start state transitions to the new unsubmitted state;

[0021] Based on the delete operation, the available submitted state is triggered to transition to the deleted unsubmitted state, or the newly added unsubmitted state is triggered to transition to the ended state;

[0022] Based on the modification operation, trigger the available submitted state to change to the deleted unsubmitted state, and at the same time trigger the start state of another record to change to the added unsubmitted state, or keep the added unsubmitted state unchanged;

[0023] Based on the version submission operation, the newly added unsubmitted state is converted to the available submitted state, or the deleted unsubmitted state is converted to the deleted submitted state;

[0024] Based on the version rollback operation, the deleted submitted state is triggered to be converted to the deleted unsubmitted state, or the deleted unsubmitted state or the deleted submitted state is triggered to be converted to the available submitted state, or the available submitted state is triggered to be converted to the added unsubmitted state, or the added unsubmitted state, the available submitted state, the deleted unsubmitted state, or the deleted submitted state is triggered to be converted to the ended state;

[0025] Based on the abandoned modification operation, the deletion of the unsubmitted state is triggered to transition to the available submitted state, or the addition of the unsubmitted state is triggered to transition to the end state;

[0026] Based on the version submission operation, a new version submission record of the current version is added when the version is submitted, and the version submission record of the version greater than the target version is deleted when the version is rolled back.

[0027] Optionally, based on the record of database version status, the version control process based on operations and submissions also includes:

[0028] For the new operation, insert a new record, assign first_version to current_version, assign last_version to NULL, and assign committed to FALSE;

[0029] For the deletion operation, for the current version of visible data, the newly added unsubmitted state is directly deleted, and for the available submitted state, the corresponding field is converted to the deleted unsubmitted state;

[0030] For modification operations, for the current version of visible data, directly modify the newly added unsubmitted state. For records in the available submitted state, first convert them to the deleted unsubmitted state and then add a new record.

[0031] For the version commit operation, first determine whether the current version of the business data contains newly added uncommitted records or deleted uncommitted records. If so: for newly added uncommitted records, the committed value is assigned to TRUE; for deleted uncommitted records, no modification is performed; a record is inserted into the version commit table, with version assigned to current_version, commit_time assigned to the current time, and commit_msg assigned to the corresponding descriptive information; the corresponding project record in the project table is updated, and the value of current_version is incremented.

[0032] Optionally, based on the record of database version status, the version control process based on operations and submissions also includes:

[0033] The version rollback operation includes the first mode, which completely rolls back to the specified version, and the second mode, which rolls back to the specified version and deletes all commit records after the specified version.

[0034] For the first mode, delete the records whose first_version is greater than the target version from the database;

[0035] For records where last_version is not NULL and last_version is greater than or equal to the target version, assign last_version to NULL.

[0036] Update the corresponding project record in the project table, and change the value of current_version to the target version increment;

[0037] For the second mode, delete the records whose first_version is greater than the target version and whose last_version is not NULL from the database;

[0038] Change the first_version of records whose first_version is greater than the target version to the target version incremented, and assign committed to FALSE;

[0039] For records where last_version is not NULL and is greater than the target version, assign its last_version to the target version.

[0040] Update the corresponding project record in the project table, and change the value of current_version to the target version increment.

[0041] Optionally, based on the record of database version status, the version control process based on operations and submissions also includes:

[0042] For version comparison operations, specify two versions and execute:

[0043] Query the records where version 1 is visible but version 2 is invisible, and record them as tmp_table1;

[0044] Query the records where version 1 is invisible but version 2 is visible, and record them as tmp_table2;

[0045] Perform a full join operation on tmp_table1 and tmp_table2 based on entity_id to perform version comparison.

[0046] An embodiment of the present application further provides a version control system for a database, comprising a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the steps of the aforementioned method are implemented.

[0047] The embodiments of the present application provide a version control function similar to Git for scenarios where a database is used as a data storage method and version control is a business.

[0048] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present application. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0050] Figure 1 This is a schematic diagram of the implementation process of the version control service under the database data storage method of the embodiment of the present application;

[0051] Figure 2 The tables and relationships between tables designed for the database of the embodiment of the present application;

[0052] Figure 3 This is a diagram of the life cycle state machine of a record in the business data table of an embodiment of the present application during the version control process;

[0053] Figure 4 This is an example of a service data table before version rollback in an embodiment of the present application;

[0054] Figure 5 This is an example of a service data table after the HARD mode version rollback in an embodiment of the present application;

[0055] Figure 6 This is an example of a business data table after the SOFT mode version is rolled back in an embodiment of the present application. DETAILED DESCRIPTION

[0056] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0057] Currently, a large number of information systems use databases for data storage, and these data also have version control business requirements, such as online version query and comparison, similar to GitHub (an online code version control website). For example, in an API interface management platform development project, the user's API design is stored in the backend in a database. The API design will be continuously iterated as the project develops, thus generating a business need for version control of the API design data. Because API design data is not stored in text format, it cannot be managed using Git or SVN. Some database version control tools, such as Liquibase and Flyway, and other database version control methods, perform version control operations on the entire database. They cannot view version data when different versions of data coexist, nor can they perform record-level comparison of historical data. In other words, these methods are not suitable for scenarios where version control is a business.

[0058] This application provides a database version control method. This method is implemented by designing special data tables, including auxiliary fields related to version control within business-related data tables, and coordinating a series of database operations. Deleting or modifying data that has already been submitted does not actually delete or modify it at the database level. Instead, it marks the outdated data accordingly to facilitate subsequent access to and rollback of historical versions. The specific operation is described in detail in the following embodiments.

[0059] The database design and operation method of the present invention are not limited to a specific type of database. For example, it can be a relational database, a document database, a graph database, etc. As long as the main design and operation methods of the present invention are followed, data version control services can be implemented.

[0060] In the embodiments of this application, the object of version control is a "project." "Project" does not refer to a specific field in the real world. Instead, it represents the data space where business data requiring version control resides. It defines the scope of data requiring version control, and version control between different projects is independent of each other. Data managed within a project can be divided into "classes," and data of different classes can have their own "properties." Data of the same class can have multiple "entities," each entity having properties of that class, and each property of each entity has a corresponding "value."

[0061] A version is a state in which the attribute values ​​of various categories and entities within a project are solidified. This state is identified by a version number, which is also referred to as "version." When data is added, deleted, or modified, it enters an unsolidified state. A "Version Commit" operation solidifies the version, and the version number increments.

[0062] The above content describes "Version Control" as follows: after adding (adding entities), deleting (removing entities), and modifying (changing entity attribute values) entities in different categories of business data in a project, the version can be solidified through version submission. It also supports version rollback, abandonment of modifications, current version query, version history query, specified version business data query, and version comparison.

[0063] This application is applicable to all types of databases. For example, in a relational database, a "category" corresponds to a table, and in a relational database, an "attribute" corresponds to a table field. In a document-based database, a "category" corresponds to a collection, and in a document-based database, an "attribute" corresponds to a field in a document within a collection. In a graph database, a "category" corresponds to a node, and in a graph database, an "attribute" corresponds to a node attribute. For convenience, the embodiments of this application use a description method that favors relational databases.

[0064] The version control method of the embodiment of the present application is as follows Figure 1 As shown, the following steps are included:

[0065] The database is configured with a project table, a version submission table, and business data tables of various categories, wherein the project table, the version submission table, and business data tables of various categories have corresponding fields set based on the project ID.

[0066] In some embodiments, the project table includes fields including: project ID, project name, current version, and project creation time, recorded as project_table(id, project_name, current_version, project_create_time), where the current version (current_version) refers to the version to be submitted.

[0067] The version submission table contains the following fields: submission ID, project ID, version, submission time, and description information, recorded as commit_table(id, project_id, version, commit_time, commit_msg), where project_id is a foreign key pointing to the id field of the project_table table.

[0068] The auxiliary fields of the business data table used for version control include: record ID, project ID, entity ID, first version, last version, and submission status, which are recorded as data_table(id, project_id, entity_id, first_version, last_version, committed, [property1], [property2], ...). The remaining fields are business attributes, among which the project ID is a foreign key pointing to the project table ID field, the first version is the version when the record is first added to the business data table; the last version is the last version before the record is deleted, and the submission status indicates whether the record has been submitted.

[0069] In a specific example, Figure 2 As shown, project_id is a foreign key pointing to the id field in the project_table table. The entity ID (entity_id) identifies the same entity. For example, in a toy factory information table, the exterior color might be mistakenly recorded as red when the first version was submitted. Later, when a new version was submitted, it was corrected to blue. Although the business attributes have changed, the two records still refer to the same entity, so the entity ID remains unchanged. The first_version (first_version) refers to the version when the record was first added to the business data table. The last_version (last_version) refers to the last version before the record was deleted and can be NULL. The committed status (committed) indicates whether the record has been committed, with a value of TRUE if committed and FALSE otherwise. [property1], [property2], etc. are business attributes, such as the toy exterior color mentioned earlier. There can be many business attributes, depending on the business category. Multiple business data tables can exist, and version control is achieved by keeping the shared fields consistent.

[0070] The version control of the embodiment of the present application mainly revolves around the current version (current_version) in the engineering table, the entity ID (entity_id), the first version (first_version), the last version (last_version), and the committed status (committed) in the business data table, where committed is TRUE, indicating that the record has been committed.

[0071] In step S101, based on the current version field in the project table, when a project is created, the value of the current version field is configured as an initial value, for example, the initial value is 1, and is incremented for each subsequent submission, for example, the value is increased by 1.

[0072] In step S102, based on the first version field, the last version field, and the submission status field of the business data table, combined with the current version field in the project table, a database version status of the record is formed. In a specific example, based on the first version field, the last version field, and the submission status field of the business data table, combined with the current version field in the project table, the database version status of the record formed includes: newly added unsubmitted state S1, available submitted state S2, deleted unsubmitted state S3, and deleted submitted state S4.

[0073] In step S103, based on the record of the database version status, the version control process is implemented according to the operation and submission status.

[0074] In some embodiments, the database version states of the records formed include: added uncommitted state S1, available committed state S2, deleted uncommitted state S3, deleted committed state S4, and these states constitute the life cycle state machine of a record in the version control process, such as Figure 3 As shown, where:

[0075] Added data records with an uncommitted status that satisfies {first_version: current_version, last_version:NULL, committed:FALSE}.

[0076] The available committed status is the data record that satisfies {last_version: NULL, committed: TRUE}.

[0077] Delete data records whose uncommitted status satisfies {last_version: current_version-1, committed:TRUE}.

[0078] Data records with committed status satisfying {last_version <= current_version-2, committed:TRUE} have been deleted.

[0079] During the version control process of the embodiment of the present application, the state machine state transition is triggered by addition, deletion, modification, version submission, and version rollback.

[0080] The operation that causes the state transition, in some embodiments, based on the record of the database version state, the version control process according to the operation and submission status includes:

[0081] Based on the new operation, the triggering start state transitions to the new uncommitted state S1;

[0082] Based on the delete operation, the available submitted state S2 is triggered to transition to the deleted unsubmitted state S3, or the newly added unsubmitted state S1 is triggered to transition to the end state;

[0083] Based on the modification operation, the available submitted state S2 is triggered to be converted to the deleted unsubmitted state S3, and at the same time, the starting state of another record is triggered to be converted to the added unsubmitted state S1, or the added unsubmitted state S1 remains unchanged.

[0084] Based on the version submission operation, the newly added uncommitted state S1 is converted to the available committed state S2, or the deleted uncommitted state S3 is converted to the deleted committed state S4;

[0085] Based on the version rollback operation, the deleted submitted state S4 is triggered to transition to the deleted unsubmitted state S3, or the deleted unsubmitted state S3 and the deleted submitted state S4 are triggered to transition to the available submitted state S2, or the available submitted state S2 is triggered to transition to the newly added unsubmitted state S1, or the newly added unsubmitted state S1, the available submitted state S2, the deleted unsubmitted state S3, and the deleted submitted state S4 are triggered to transition to the end state.

[0086] Based on the abandonment of the modification operation, the deletion of the uncommitted state S3 is triggered to transition to the available committed state S2, or the addition of the uncommitted state S1 to transition to the end state.

[0087] Other operations (current version query, version history query, specified version business data query, and version comparison) are query operations and do not trigger state transitions. Instead, retrieval is performed based on the record's state.

[0088] Based on the version submission operation, a new version submission record of the current version is added when the version is submitted, and the version submission record of the version greater than the target version is deleted when the version is rolled back.

[0089] Based on the aforementioned version control design, several necessary operations for version control are implemented, including adding, deleting, modifying, version submission, version rollback, abandoning modification, current version query, version history query, specified version business data query, and version comparison. These operations vary in complexity, but all revolve around current_version, first_version, last_version, committed, etc. Each operation should be performed according to the steps in each operation instruction to ensure that the data version is controllable. If state modification operations (adding, deleting, modifying, version submission, version rollback, abandoning modification) are not performed according to the steps, illegal records that jump out of the S1-S4 state may appear, resulting in uncontrolled versions; if query operations (current version query, version history query, specified version business data query, version comparison) are not performed according to the steps, the queried version, version data, or comparison results may be incorrect.

[0090] In some embodiments, based on the record of database version status, the version control process according to the operation and submission status further includes:

[0091] For new operations, insert a new record, set first_version to current_version, last_version to NULL, and committed to FALSE. A unique entity_id is automatically generated and assigned, and other fields are assigned values ​​based on business needs.

[0092] For the delete operation, for the visible data of the current version, including S1 and S2 state records, the common feature is {last_version: NULL}. For the newly added uncommitted state, it is directly deleted. For the available committed state S2, the corresponding field is converted to the deleted uncommitted state S3. The specific steps are as follows:

[0093] Check whether the record is a record that can be deleted by using the condition that last_version is NULL;

[0094] If the deletion operation is possible, for uncommitted records (i.e. {committed: FALSE}), the record is directly deleted from the database. For committed records (i.e. {committed: TRUE}), last_version is assigned to current_version-1.

[0095] For modification operations, for the visible data of the current version, directly modify the newly added unsubmitted state S1. For the records in the available submitted state S2, first convert them to the deleted unsubmitted state S3, and then add a new record. The entity_id must be consistent, indicating that these two records are the same business entity. The specific steps are as follows:

[0096] Check whether the record can be modified by checking the condition that last_version is NULL;

[0097] If the modification operation is allowed, for uncommitted records (i.e., {committed: FALSE}), directly assign values ​​to the business attribute fields of the record according to business needs. For committed records (i.e., {committed: TRUE}), assign last_version to current_version - 1, then insert a record with first_version assigned to current_version, last_version assigned to NULL, committed assigned to FALSE, and entity_id assigned to the entity_id of the record just operated on. Assign values ​​to other fields according to business needs.

[0098] For the version commit operation, first determine whether the current version of the business data contains newly added uncommitted status S1 records or deleted uncommitted status S3 records. If so: for newly added uncommitted status records, committed is assigned a value of TRUE; for deleted uncommitted status records, no modification is performed; a record is inserted into the version commit table, version is assigned to current_version, commit_time is assigned to the current time, commit_msg is assigned to the corresponding descriptive information, the corresponding project record in the project table is updated, and the value of current_version is incremented, for example, the value of current_version is +1.

[0099] In some embodiments, based on the record of database version status, the version control process according to the operation and submission status further includes:

[0100] For version rollback operations, there are two modes: the first mode, which completely rolls back to the specified version, and the second mode, which rolls back to the specified version and deletes all committed records of versions after it. For example, these modes are defined as HARD mode and SOFT mode. In SOFT mode, all business data records that are currently invisible after the specified version are deleted (real deletion), while visible ones are retained, and current_version is modified to the target version plus 1.

[0101] For the first mode (HARD mode), delete the records whose first_version is greater than the target version from the database;

[0102] For records where last_version is not NULL and last_version is greater than or equal to the target version, assign last_version to NULL.

[0103] Update the corresponding project record in the project table, and change the value of current_version to the target version increment, for example, the value of current_version +1.

[0104] For the second mode (SOFT mode), records whose first_version is greater than the target version and whose last_version is not NULL are deleted from the database.

[0105] Change the first_version of records whose first_version is greater than the target version to the target version incremented, and assign committed to FALSE.

[0106] For records where last_version is not NULL and is greater than the target version, assign its last_version to the target version.

[0107] Update the corresponding project record in the project table, and change the value of current_version to the target version increment, for example, the value of current_version +1.

[0108] Attachment Figure 4 , Attachment Figure 5 , Attachment Figure 6 Examples are shown before version rollback, after version rollback in hard mode, and after version rollback in soft mode. The horizontal axis represents versions, and the vertical axis represents entities. Boxes such as A1 represent records, each showing the record's status (S1-S4), first_version, last_version, and committed (T represents TRUE, F represents FALSE). These three figures illustrate the changes in each record before and after the version rollback.

[0109] It also includes the following operations:

[0110] The abandon modification operation abandons uncommitted changes in the current version, including records in status S1 and S3. It is a special case of the version rollback operation, so the specific steps of this operation are:

[0111] Roll back to current_version-1 in HARD mode.

[0112] The current version query operation is as follows: query the current_version field of the corresponding project in the project table.

[0113] The specific steps for version history query operation are: query the version submission record of the corresponding project in the version submission table.

[0114] The query operation for business data of a specified version queries the visible data of a certain version. The specific steps are: query the data whose first_version is less than or equal to the specified version and whose last_version is NULL or whose last_version is greater than or equal to the specified version.

[0115] In some embodiments, based on the record of database version status, the version control process according to the operation and submission status further includes:

[0116] For version comparison operations, specify two versions and execute:

[0117] Query the records where version 1 is visible but version 2 is invisible, and record them as tmp_table1;

[0118] Query the records where version 1 is invisible but version 2 is visible, and record them as tmp_table2;

[0119] Perform a full join operation on tmp_table1 and tmp_table2 based on entity_id to perform version comparison.

[0120] Assume one is version 1 and the other is version 2. If the entity_id exists in version 1 but not in version 2, the entity is considered added. If the entity_id does not exist in version 1 but exists in version 2, the entity is considered deleted. If the entity_id exists in both version 1 and version 2, and they are different records, the entity is considered modified.

[0121] The method of the embodiment of the present application is aimed at the scenario where a database is used as a data storage method and version control is a business, and discloses a database design and operation method for version control business. Different from the traditional database without version control, it can realize version data viewing in the case of coexistence of different versions of data, and can also realize record-level comparison of historical data. It supports multiple version control operations including addition, deletion, modification and version submission, version rollback, abandonment of modification, current version query, version history query, specified version business data query, and version comparison operation.

[0122] An embodiment of the present application further provides a version control system for a database, comprising a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the steps of the aforementioned method are implemented.

[0123] It should be noted that, in the various embodiments of the present application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0124] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0125] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a more preferred embodiment. Based on this understanding, the technical solution of this application, or the part that contributes to the existing technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of this application.

[0126] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are protected by this application.

Claims

1. A database version control method, characterized in that: include: The database is configured with a project table, a version submission table and business data tables of various categories, wherein the project table, the version submission table and business data tables of various categories have corresponding fields set based on the project ID; Based on the current version field in the project table, when a project is created, the value of the current version field is configured as the initial value, and is incremented for each subsequent submission; Based on the first version field, the last version field and the submission status field of the business data table, combined with the current version field in the engineering table, a database version status of the record is formed; Based on the record of database version status, the version control process is implemented according to operations and submissions.

2. The database version control method according to claim 1, characterized in that: The fields included in the project table include: project ID, project name, current version, and project creation time, recorded as project_table(id, project_name, current_version, project_create_time); The fields included in the version submission table include: submission ID, project ID, version, submission time, and description information, recorded as commit_table(id, project_id, version, commit_time, commit_msg); The auxiliary fields of the business data table used for version control include: record ID, project ID, entity ID, first version, last version, and submission status, which are recorded as data_table(id, project_id, entity_id, first_version,last_version, committed, [property1], [property2], …), and the remaining fields are business attributes, among which the project ID is a foreign key pointing to the project table ID field, the first version is the version when the record is first added to the business data table; the last version is the last version before the record is deleted, and the submission status is whether the record has been submitted.

3. The database version control method according to claim 2, characterized in that: Based on the first version field, the last version field and the submission status field of the business data table, combined with the current version field in the engineering table, the database version status of the record formed includes: added unsubmitted status, available submitted status, deleted unsubmitted status, deleted submitted status, where: Added records with uncommitted status satisfying {first_version: current_version, last_version: NULL, committed: FALSE}; Available committed status is the record that satisfies {last_version: NULL, committed: TRUE}; Delete the records whose uncommitted status satisfies {last_version: current_version-1, committed: TRUE}; The records whose committed status satisfies {last_version <= current_version-2, committed:TRUE} have been deleted.

4. The database version control method according to claim 3, characterized in that: Based on the record of database version status, the version control process is implemented according to the operation and submission status, including: Based on the new operation, the triggering start state is converted to the new unsubmitted state; Based on the delete operation, trigger the available submitted state to transition to the deleted unsubmitted state, or the added unsubmitted state to transition to the ended state; Based on the modification operation, trigger the available submitted state to change to the deleted unsubmitted state, and at the same time trigger the start state of another record to change to the added unsubmitted state, or keep the added unsubmitted state unchanged; Based on the version submission operation, trigger the conversion of the added unsubmitted state to the available submitted state, or the conversion of the deleted unsubmitted state to the deleted submitted state; Based on the version rollback operation, trigger the deleted submitted state to transition to the deleted unsubmitted state, or trigger the deleted unsubmitted state and the deleted submitted state to transition to the available submitted state, or trigger the available submitted state to transition to the added unsubmitted state, or trigger the added unsubmitted state, the available submitted state, the deleted unsubmitted state, and the deleted submitted state to transition to the ended state; Based on the abandonment of modification operation, the deletion of unsubmitted state is triggered to be converted to available submitted state, or the addition of unsubmitted state is triggered to be converted to end state; Based on the version submission operation, a new version submission record of the current version is added when the version is submitted, and the version submission records greater than the target version are deleted when the version is rolled back.

5. The database version control method according to claim 4, characterized in that: Based on the record of database version status, the version control process based on operations and submissions also includes: For the new operation, insert a new record, assign first_version to current_version, assign last_version to NULL, and assign committed to FALSE; For the deletion operation, for the visible data of the current version, the newly added unsubmitted state is directly deleted, and for the available submitted state, the corresponding field is converted to the deleted unsubmitted state; For modification operations, for the visible data of the current version, the newly added unsubmitted state is modified directly, and for the records in the available submitted state, the unsubmitted state is first converted to be deleted, and then a new record is added; For the version submission operation, first determine whether the current version of the business data contains newly added unsubmitted records or deleted unsubmitted records. If so: for newly added unsubmitted records, committed is assigned a value of TRUE; for deleted unsubmitted records, no modification is performed; a record is inserted into the version submission table, version is assigned to current_version, commit_time is assigned to the current time, commit_msg is assigned to the corresponding descriptive information, the corresponding project record in the project table is updated, and the value of current_version is incremented.

6. The database version control method according to claim 5, characterized in that: Based on the record of database version status, the version control process based on operations and submissions also includes: The version rollback operation includes the first mode of completely rolling back the specified version and the second mode of rolling back to the specified version and deleting all the version submission records after the specified version, where: For the first mode, the records whose first_version is greater than the target version are deleted from the database; For records where last_version is not NULL and last_version is greater than or equal to the target version, assign last_version to NULL. Update the corresponding project record in the project table, and change the value of current_version to the target version increment; For the second mode, the records whose first_version is greater than the target version and whose last_version is not NULL are deleted from the database; Change the first_version of records whose first_version is greater than the target version to the target version incremented, and assign committed to FALSE; For records where last_version is not NULL and last_version is greater than the target version, assign its last_version to the target version; Update the corresponding project record in the project table, and change the value of current_version to the target version increment.

7. The database version control method according to claim 5, characterized in that: Based on the record of database version status, the version control process based on operations and submissions also includes: For version comparison operations, specify two versions and execute: Query the records that are visible in version 1 but invisible in version 2, and record them as tmp_table1; Query the records where version 1 is invisible but version 2 is visible, and record them as tmp_table2; Perform a full join operation on tmp_table1 and tmp_table2 regarding entity_id to perform version comparison.

8. A version control system for a database, characterized in that: The method comprises a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images