Incremental change method and system based on version number

Abstract

The invention discloses an incremental change method and system based on a version number, and the method comprises the steps: configuring three types of identification fields of version, state and deletion for business data, defining the value rule and business mapping relation of each field, and achieving the unified identification of the attribute, effective state and deletion state of the data version. And receiving a data change request, identifying a change type and the target data, only executing an operation on the changed data, and keeping the original information of the unchanged data. And synchronously updating the three types of fields during change, copying the target data to generate new data, keeping a historical state, and not modifying the core content of the original version. A traceable storage mode is adopted, data and field information of all iteration versions are stored, key operation information is recorded, unchanged data are not stored repeatedly, and data full-life-cycle tracing is achieved. And receiving a version query request, screening according to a screening rule, and returning a complete and effective data set of a target version. And the requirement of service iteration on the accuracy of data management is met.

Description

Technical Field

[0001] This invention belongs to the field of business data management and version control technology, and more specifically, relates to an incremental change method and system based on version number. Background Technology

[0002] In the field of business data management, as business scale expands and iteration speed accelerates, the frequency of data changes continues to increase, making the requirements for data version management, change tracking, and storage efficiency increasingly stringent. Currently, some mainstream data change management methods adopt a full update model, meaning that every time data changes, the entire dataset is re-stored without distinguishing between changed and unchanged data. Under this model, even a change to a single data item requires the same storage resources as the entire dataset, leading to a significant increase in storage redundancy. Simultaneously, the full update process consumes substantial computing resources, reducing data change processing efficiency and making it difficult to adapt to the high-frequency business iteration needs.

[0003] While some management methods attempt incremental processing, they lack standardized version and status identification mechanisms. They simply distinguish data versions by recording update times or modification logs, failing to accurately identify the validity and deletion status of data in different iterations. When it is necessary to trace historical version data or query valid data for a specific version, a large amount of log information must be screened and verified one by one. This is not only inefficient but also prone to omissions or errors in the screening results due to ambiguous identification, making it impossible to quickly obtain a complete and valid dataset of the target version.

[0004] Meanwhile, most existing change management solutions lack a robust historical data retention mechanism. Some directly overwrite existing data, leading to the loss of historical version data and an inability to trace data change tracing. When business issues arise requiring a rollback to a previous version or investigation of the cause of a change, reliable data is lacking. The few solutions that retain historical data fail to establish a mapping between data and operational information, making it difficult to accurately match the operational details corresponding to data changes during tracing, increasing the difficulty of problem localization. These issues collectively result in insufficient accuracy, efficiency, and traceability in business data management, hindering the improvement of business iteration efficiency and problem-solving capabilities. Therefore, a highly efficient versioned incremental change management technology is urgently needed to address these pain points. Summary of the Invention

[0005] This invention aims to solve the problems of storage redundancy, difficulty in version tracing, and easy loss of historical data in business data changes. By configuring three types of identification fields, performing incremental change operations, adopting traceable storage and precise filtering rules, it achieves standardized management of data versions, improves change processing efficiency, ensures traceability of data throughout its entire lifecycle, and meets the precise data management requirements of business iteration.

[0006] To address the aforementioned deficiencies or improvement needs of existing technologies, this invention provides an incremental change method based on version numbers, comprising: S1. Configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of business data version attribute, valid status and deletion status through the three types of fields; S2. Receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is preserved by generating new data by copying the target data, and the core content of the original version data is not directly modified. S3. Adopt a storage method with traceability function to store business data and corresponding field information of each iteration version, synchronously record key operation information in the data change process, complete the traceability management of the entire life cycle of business data, and do not duplicate store unchanged data; S4. When receiving a target version query request, filter the stored business data according to preset filtering rules, and return the complete and valid dataset corresponding to the target version.

[0007] Furthermore, in S1, the version identifier field is used to distinguish the iteration version to which the data belongs, the status identifier field is used to identify the validity of the data in the corresponding version, and the deletion identifier field is used to identify the deletion status of the data.

[0008] Furthermore, the version identifier field is a positive integer, with the initial version's version identifier field value set to 1, and the value of the version identifier field for each subsequent iteration increasing sequentially; The status identifier field can be 0 or 1. A value of 1 indicates that the data is valid in the corresponding version and historical traceability, while a value of 0 indicates that the data is invalid in the corresponding version. The deletion flag field can be either 0 or 1. A value of 1 indicates that the data has been marked for deletion, while a value of 0 indicates that the data has not been deleted.

[0009] Furthermore, the change operations in S2 include data modification, deletion, and restoration, wherein: When data is modified, the target data is copied and new data is generated. The version identifier field of the new data is updated to the next version number, the status identifier field is set to 1, and the deletion identifier field is set to 0. At the same time, the status identifier field of the target data in the original version is set to 0. When data is deleted, the status flag field of the target data is set to 0; if it is necessary to mark the deletion status in the current version, copy the target data and update the version flag field of the new data to the current version number, and set the deletion flag field to 1. During data recovery, copy the target data that was inactive in the historical version (i.e., the status identifier field is 0), generate new data and update its version identifier field to the current version number, set the status identifier field to 1, and set the deletion identifier field to 0.

[0010] Furthermore, the process of storing the business data and corresponding field information of each iteration version in S3 is as follows: Let the stored data set be , Any data item in , A unique identifier for data, used to distinguish different business data; data item The corresponding version identifier field value is The status identifier field takes the value of The deletion identifier field takes the value of The key operational information set during the data change process is as follows: , Any operation information is , This is a unique identifier for each operation, used to distinguish different change operations. The target data identifier mapping relationship is as follows: ; in, A positive integer, representing a data item. The iteration version, with an initial value of 1 that increases sequentially in subsequent iterations; The value can be 0 or 1, where 1 represents a data item. Valid in the corresponding version and historical traceability; 0 represents a data item. It is not working in the corresponding version; The value can be 0 or 1, where 1 represents a data item. Marked for deletion, 0 represents a data item. Not deleted; It includes data related to the operation type, target data identifier, version change information, and operation time. Used for association and , express Target data identifier and of Consistent; Storage relationship satisfies and This means that only business data items from each iteration that conform to the field value rules, along with their associated change operation information, are stored; business data items that have not changed are not included repeatedly. Through mapping relationship This enables the association between operational information and data items.

[0011] Furthermore, the key operation information in S3 includes at least the operation type, target data identifier, version change information, and operation time-related data.

[0012] Furthermore, the filtering rules in S4 are constructed based on the deletion identifier field, version identifier field, and status identifier field. The specific construction process is as follows: Let the target version number be The version identifier field of the data to be filtered takes the value of The status identifier field takes the value of The deletion identifier field takes the value of The target version's valid data set is The data validity determination function is: ; in, A positive integer, corresponding to the iteration version number specified in the query request; It is a positive integer representing the iteration version to which the data belongs. The initial value is 1 and it increases sequentially in subsequent iterations. The value can be 0 or 1, where 1 indicates that the data is valid in the corresponding version and historical traceability, and 0 indicates that the data is invalid in the corresponding version. The value can be 0 or 1, where 1 indicates that the data has been marked for deletion, and 0 indicates that the data has not been deleted. This is a binary decision function. A value of 1 indicates that the data meets the requirements of the target version, and a value of 0 indicates that it does not. The filtering rules are constructed based on the mutual exclusion principle of logical operations, and the judgment logic is defined by the following formula: , That is, only when the data deletion identifier field is 0 and the version identifier field is equal to the target version number. Or the version identifier field value is less than the target version number. Furthermore, when the status identifier field is set to 1, the data is considered complete and valid for the target version and is included in the target version's data set; ultimately, through... Build filtering rules.

[0013] Furthermore, the complete and valid data set in S4 includes newly added but not deleted data in the target version and data from historical versions that have not been deleted and are still valid.

[0014] As a second aspect of the present invention, a version number-based incremental change system is also provided, comprising: The multi-dimensional identifier field configuration unit is used to configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of the version attribute, validity status and deletion status of business data through the three types of fields; The incremental change and historical retention unit is used to receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is retained by generating new data by copying the target data, without directly modifying the core content of the original version data. The traceability storage and redundancy optimization unit is used to store business data and corresponding field information of each iteration version using a traceability storage method, synchronously record key operation information during the data change process, complete the traceability management of the entire life cycle of business data, and avoid duplicate storage of unchanged data. The target version dataset filtering unit is used to filter the stored business data according to preset filtering rules when receiving a target version query request, and then merge and return the complete and valid dataset corresponding to the target version.

[0015] As a third aspect of the invention, a computer-readable storage medium is also provided, on which a computer program is stored, which is executed by a processor as described in any one of the claims, an incremental change method based on a version number.

[0016] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects: 1. The version-number-based incremental change method of this invention achieves unified identification of business data version attributes, validity status, and deletion status by configuring version identifier fields, status identifier fields, and deletion identifier fields for business data, and defining the value rules and business mapping relationships for each field. The version identifier field uses positive integer increments to distinguish iterative versions, with an initial value set to 1 and incrementing sequentially thereafter; the status identifier field uses 0 or 1 to indicate the validity of data in the corresponding version; the deletion identifier field uses 0 or 1 to indicate the deletion status of data. This configuration standardizes the version and status information of the data, providing a foundation for subsequent incremental changes and traceability. Compared with change methods without unified identifiers, it avoids version confusion and status judgment chaos, ensures consistent understanding of data attributes at all stages, lays the foundation for incremental processing and accurate querying, and improves the standardization of data management.

[0017] 2. The version number-based incremental change method of the present invention, upon receiving a data change request, only performs operations on the target data that has changed, while keeping the original information of unchanged data unchanged. It preserves historical states by combining the copying of target data to generate new data, without directly modifying the core content of the original version. When data is modified, the new data version identifier is updated to the next version, the activation status is set, and the original version is set to invalid. When data is deleted, the status is set to invalid; if deletion is required, the data is copied, the version is updated, and the deletion identifier is updated. When restoring, historical inactive data is copied, and the version and activation status are updated. This incremental processing mode avoids the resource consumption of full data processing, operates only on changed data, and completely preserves the historical version state, solving the problems of historical data loss or low efficiency of full processing in traditional changes, improving change processing efficiency and ensuring data traceability.

[0018] 3. The version number-based incremental change method of this invention stores data and field information for each version using a traceable storage method. It synchronously records key operation information such as operation type and target data identifier, and avoids duplicate storage of unchanged data. Combined with filtering rules based on three types of identifier fields, it enables complete and valid data retrieval for the target version. During storage, data and change information are linked to ensure traceability throughout the entire lifecycle. During querying, deletion identifiers are used as the basis, combined with version identifiers and status identifiers to filter newly added data and historically valid data for the target version. This storage and query mechanism reduces redundancy through incremental storage and ensures the completeness of query results through precise filtering. Compared to the redundancy problems of traditional storage and the one-sidedness of queries, it achieves a balance between optimized storage resources and accurate and complete query results, adapting to the actual needs of business data iteration. Attached Figure Description

[0019] Figure 1 This is a flowchart of the incremental change method based on version number according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the initial data set of version V1 of this invention; Figure 3 This is a schematic diagram illustrating the generation of new data according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating data changes according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating data deletion according to an embodiment of the present invention; Figure 6 This is a schematic diagram of version V2 data in an embodiment of the present invention; Figure 7 This is a system unit diagram of an embodiment of the present invention; Among them, data_id represents the unique identifier of the data; data_content represents the content of the business data; operate_time represents the operation time; version represents the version identifier field; is_activ represents the status identifier field; and deleted represents the deletion identifier field. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0021] Example 1 Please refer to Figure 1 This embodiment 1 provides an incremental change method based on version number, characterized in that it includes: S1. Configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of business data version attribute, valid status and deletion status through the three types of fields; S2. Receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is preserved by generating new data by copying the target data, and the core content of the original version data is not directly modified. S3. Adopt a storage method with traceability function to store business data and corresponding field information of each iteration version, synchronously record key operation information in the data change process, complete the traceability management of the entire life cycle of business data, and do not duplicate store unchanged data; S4. When receiving a target version query request, filter the stored business data according to preset filtering rules, and return the complete and valid dataset corresponding to the target version.

[0022] Please refer to Figures 2-6 This embodiment 1 further elaborates on the above steps.

[0023] (1) Configuration of multi-dimensional identifier fields In the process of business data management, traditional management methods often suffer from problems such as confusion of data from different iteration versions, ambiguity in judging the validity of historical data, and difficulty in tracing deletion status due to the lack of standardized version, validity, and deletion status identifiers. These missing basic identifiers directly affect the accuracy of subsequent data changes and management. The initial configuration phase is set up to solve these basic problems and serves as a prerequisite for the entire version number-based incremental change method.

[0024] This phase involves calling the field configuration module to perform specific tasks. The core is to uniformly configure three types of basic identifier fields with clearly defined functional positioning for business data, achieving standardized identification of core data attributes. In a specific embodiment, the version identifier field is specifically used to distinguish the iteration version to which the data belongs. This field is named `version`, and its value type is set to positive integers. To ensure the continuity and uniqueness of version tracing, the initial value of this field is set to 1. Subsequently, whenever business data completes an iteration change and generates a new version, the value of this field will increase sequentially by a fixed increment of 1. The ordered differences in values ​​clearly define the iteration stage to which the data belongs.

[0025] The status identifier field is named is_active, which is mainly used to identify the validity of data in the corresponding version. Considering the binary attribute of validity determination, the value of this field is limited to two values: 0 or 1. When the value is 1, it not only means that the data is valid in the current version, but also means that the validity of the data in this version can be recognized in the subsequent historical data tracing process. When the value is 0, it clearly means that the data has lost its validity in its version and cannot be used as valid data in business processing.

[0026] The deletion flag field is named "deleted" and is used to accurately identify the deletion status of data. It also uses a binary value method. When the value is 1, it indicates that the data has been marked as deleted by the system. When the value is 0, it indicates that the data has not been marked as deleted and remains in a normal storage and usage state.

[0027] After setting the three types of fields, the field configuration module further clarifies the value rules for each field. For example, the increment trigger condition for the version identifier field is the completion of data iteration changes, and the value changes for the status identifier and deletion identifier fields require the execution of corresponding data validity adjustments or deletion operations. Simultaneously, a mapping relationship is established between field values ​​and actual business scenarios to ensure that field values ​​accurately reflect changes in the status of business data. Once all configurations are complete, the field information, value rules, and business mapping relationships are synchronously stored in the data storage module, forming a standardized and traceable basic data identifier system. This provides reliable foundational support for subsequent incremental data change operations, full lifecycle traceability storage, and target version data filtering.

[0028] (2) Incremental changes and historical retention After configuring the basic identifier fields for business data, the system enters the data change processing phase. Traditional data changes often involve full overwrite or direct modification of the original data, which either wastes a lot of storage resources or leads to the loss of historical version data, making it impossible to trace the change trajectory. This method, through the collaborative design of version iteration judgment and incremental change processing, not only improves change efficiency but also fully preserves the historical data state, solving the pain points of traditional methods.

[0029] The system first executes a version iteration judgment process. Its core function is to accurately determine whether a new version iteration needs to be triggered after receiving a business data update request. If the received update request is the first update for initial, non-iterated data, the system will directly generate the current version data, in which case the version identifier field will be set to 1 according to the initialization rules. If the update request is for existing historical version data, the system will generate a new version with the previous version number plus 1 as the current version number, according to the incrementing rule of the version identifier field. For example, if the current data is version 2, the new version number generated after the update will be 3. Through this ordered incrementing rule, it ensures that each iteration version can be clearly distinguished.

[0030] After version iteration is determined, the data change processing flow begins, jointly executed by the data change module and the change recording unit. The data change module first parses the business request, accurately identifying the operation type, including add, modify, delete, and restore, and simultaneously locates the target data based on the unique data identifier in the request. During processing, the system only performs the corresponding operation on the target data confirmed to have changed; unchanged data retains all field information unchanged. This incremental processing method significantly reduces unnecessary resource consumption and improves change efficiency. The change recording unit synchronously records key details of each operation, including the specific operation type, the unique identifier of the target data, the version number corresponding to the operation, and the timestamp of the operation execution. This information provides a complete and reliable basis for subsequent data traceability.

[0031] Taking the modification operation from version 1 to version 2 as an example, the specific processing flow is as follows: The first step is to locate the target data. The data change module queries the data to be modified in version 1 from the data storage module based on the unique identifier of the data in the request. At the same time, the data status is verified. Only when the data version identifier is 1, the deletion identifier is 0, and the status identifier is 1 is the data confirmed to be in a valid and modifiable state, so as to avoid performing erroneous operations on invalid or deleted data. The second step is to generate new data. The system copies the core business content of the data to be modified, and then updates the basic identifier field. The version identifier is updated to the current new version number 2, the status identifier is set to 1 to indicate that the new data is valid, the deletion identifier is set to 0 to indicate that the data has not been deleted, and the operation timestamp is updated to the current time. This generates new data of version 2. The third step is to update the original data status. The system locates the original data to be modified in version 1, changes its status identifier from 1 to 0, marks it as invalid historical version data, retains its version identifier as 1, keeps the deletion identifier as 0, and updates the operation timestamp to the current time. By only modifying the status identifier, the core information of the original version data is completely preserved. The fourth step is data storage synchronization. The newly generated version 2 data is inserted into the data storage module, and at the same time, the status identifier field of the original version 1 data is updated. This completes the data synchronization of the entire modification operation.

[0032] For deletion and recovery operations, the system also follows the core principles of incremental processing and historical retention. When performing a deletion operation, the system first sets the status flag of the target data to 0, making it invalid data; if the business scenario requires explicitly marking the deletion status of data in the current version, the target data is copied to generate new data, the version flag of the new data is updated to the current version number, and the deletion flag is set to 1. This achieves accurate marking of the deletion status without affecting the historical records of the original data.

[0033] When performing a recovery operation, the system filters out inactive target data with a status flag of 0 from historical versions, copies the data, generates new data, updates the version flag of the new data to the current version number, sets the status flag to 1 and the deletion flag to 0, so that the recovered data can be directly included in the valid data range of the current version, while preserving the integrity of the original historical data.

[0034] The entire change process completely avoids direct modification of the core data of the original version by copying and generating new data and only updating the status identifier of the original data, thus achieving complete retention of historical data status.

[0035] (3) Traceability storage and redundancy optimization After data change processing is completed, the data storage and update phase begins. Traditional data storage often suffers from loose structure or lack of associated operation information, making it difficult to match data with change records during version tracing, and repeatedly storing unchanged data leads to resource waste. This phase, through structured storage design, not only achieves the association and traceability of data and operation information across versions, but also reduces redundancy through incremental storage.

[0036] The data storage module receives the modified data set, which includes historical versions and newly generated data, excluding unchanged data to avoid resource consumption from duplicate storage. To ensure storage standardization and traceability, a structured storage method, such as relational database tables, is adopted. The designed storage fields cover unique data identifiers, version identifiers, status identifiers, deletion identifiers, business data content, and operation time. Each field corresponds one-to-one with the fields in the previous configuration and change phases, ensuring data consistency throughout the process. Specifically, the unique data identifier distinguishes different business data, ensuring each piece of data has a unique identity throughout its entire lifecycle; the business data content stores the core business information of the data and is the core carrier of data value; and the operation time accurately records the time point of data change, providing a temporal basis for traceability.

[0037] During storage, not only are the business data and corresponding field information for each iteration version stored, but also key operation information during data changes is stored synchronously, and a mapping relationship is established between the two. Specifically, the process of storing the business data and corresponding field information for each iteration version is as follows: Let the stored data set be , Any data item in , A unique identifier for data, used to distinguish different business data; data item The corresponding version identifier field value is The status identifier field takes the value of The deletion identifier field takes the value of The key operational information set during the data change process is as follows: , Any operation information is , This is a unique identifier for each operation, used to distinguish different change operations. The target data identifier mapping relationship is as follows: ; in, A positive integer, representing a data item. The iteration version, with an initial value of 1 that increases sequentially in subsequent iterations; The value can be 0 or 1, where 1 represents a data item. Valid in the corresponding version and historical traceability; 0 represents a data item. It is not working in the corresponding version; The value can be 0 or 1, where 1 represents a data item. Marked for deletion, 0 represents a data item. Not deleted; It includes data related to the operation type, target data identifier, version change information, and operation time. Used for association and , express Target data identifier and of Consistent; Storage relationship satisfies and This means that only business data items from each iteration that conform to the field value rules, along with their associated change operation information, are stored; business data items that have not changed are not included repeatedly. Through mapping relationship This enables the association between operational information and data items.

[0038] This storage design ensures that the data set contains only business data items from each iteration that conform to the field value rules, and the operation information set contains only change operation information associated with the data items in the data set. Through structured field design, data-operation information mapping, and incremental storage strategy, it achieves traceable management of the entire lifecycle of business data, enabling the tracing of all iteration versions and corresponding operation details through unique data identifiers. Furthermore, it optimizes storage resources by storing unchanged data without duplication, thus solving the dual problems of difficult traceability and resource redundancy in traditional storage.

[0039] (4) Target version dataset filtering After completing incremental data changes and structured storage, the system enters the version data query stage. Traditional data query methods often suffer from problems such as inaccurate target version data filtering and omission of historical valid data, making it impossible to quickly obtain a complete and valid dataset corresponding to a specific version. In this stage, a preset filtering rule based on three types of identifier fields is used to achieve accurate filtering and efficient return of target version data.

[0040] The data query module receives target version query requests from users or business systems. These requests must explicitly specify the target version number, which is a positive integer and must match the value of the version identifier field used during data storage. Upon receiving the request, the data query module automatically invokes preset filtering rules. These rules are built upon the deletion identifier field, version identifier field, and status identifier field. The core logic revolves around the data's deletion status, version attribution, and validity, ensuring that the filtering results include both newly added data from the target version and valid data carried over from historical versions.

[0041] The filtering process must simultaneously meet two core conditions. Specifically, the filtering rules are constructed based on the deletion identifier field, the version identifier field, and the status identifier field. The specific construction process is as follows: Let the target version number be The version identifier field of the data to be filtered takes the value of The status identifier field takes the value of The deletion identifier field takes the value of The target version's valid data set is The data validity determination function is: ; in, A positive integer, corresponding to the iteration version number specified in the query request; It is a positive integer representing the iteration version to which the data belongs. The initial value is 1 and it increases sequentially in subsequent iterations. The value can be 0 or 1, where 1 indicates that the data is valid in the corresponding version and historical traceability, and 0 indicates that the data is invalid in the corresponding version. The value can be 0 or 1, where 1 indicates that the data has been marked for deletion, and 0 indicates that the data has not been deleted. This is a binary decision function. A value of 1 indicates that the data meets the requirements of the target version, and a value of 0 indicates that it does not. The filtering rules are constructed based on the mutual exclusion principle of logical operations, and the judgment logic is defined by the following formula: , That is, only when the data deletion identifier field is 0 and the version identifier field is equal to the target version number. Or the version identifier field value is less than the target version number. Furthermore, when the status identifier field is set to 1, the data is considered complete and valid for the target version and is included in the target version's data set; ultimately, through... Build filtering rules.

[0042] Through this filtering rule, the final complete and valid dataset contains two parts: one part is the new, non-deleted data added in the target version, and the other part is the data from historical versions that has not been deleted and is still valid. This ensures the integrity of the target version data and avoids interference from invalid and duplicate data, solving the pain point of inaccurate data filtering in traditional query methods and meeting the needs of business scenarios for tracing and using specific version data.

[0043] Example 2 Please refer to Figure 7 This embodiment 2 provides an incremental change system based on version numbers, including: The multi-dimensional identifier field configuration unit is used to configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of the version attribute, validity status and deletion status of business data through the three types of fields; The incremental change and historical retention unit is used to receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is retained by generating new data by copying the target data, without directly modifying the core content of the original version data. The traceability storage and redundancy optimization unit is used to store business data and corresponding field information of each iteration version using a traceability storage method, synchronously record key operation information during the data change process, complete the traceability management of the entire life cycle of business data, and avoid duplicate storage of unchanged data. The target version dataset filtering unit is used to filter the stored business data according to preset filtering rules when receiving a target version query request, and then merge and return the complete and valid dataset corresponding to the target version.

[0044] Example 3 This embodiment 3 also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement any step of a version number-based incremental change method.

[0045] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0046] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.

[0047] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for incremental changes based on version numbers, characterized in that, include: S1. Configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of business data version attribute, valid status and deletion status through the three types of fields; S2. Receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is preserved by generating new data by copying the target data, and the core content of the original version data is not directly modified. S3. Adopt a storage method with traceability function to store business data and corresponding field information of each iteration version, synchronously record key operation information in the data change process, complete the traceability management of the entire life cycle of business data, and do not duplicate store unchanged data; S4. When receiving a target version query request, filter the stored business data according to preset filtering rules, and return the complete and valid dataset corresponding to the target version.

2. The incremental change method based on version number according to claim 1, characterized in that, In S1, the version identifier field is used to distinguish the iteration version to which the data belongs, the status identifier field is used to identify the validity of the data in the corresponding version, and the deletion identifier field is used to identify the deletion status of the data.

3. The incremental change method based on version number according to claim 2, characterized in that, The version identifier field is a positive integer. The initial version's version identifier field value is set to 1, and the version identifier field value of each subsequent iteration version increases sequentially. The status identifier field can be 0 or 1. A value of 1 indicates that the data is valid in the corresponding version and historical traceability, while a value of 0 indicates that the data is invalid in the corresponding version. The deletion flag field can be either 0 or 1. A value of 1 indicates that the data has been marked for deletion, while a value of 0 indicates that the data has not been deleted.

4. The incremental change method based on version number according to claim 1, characterized in that, The change operations in S2 include data modification, deletion, and restoration, wherein: When data is modified, the target data is copied and new data is generated. The version identifier field of the new data is updated to the next version number, the status identifier field is set to 1, and the deletion identifier field is set to 0. At the same time, the status identifier field of the target data in the original version is set to 0. When data is deleted, the status flag field of the target data is set to 0; if it is necessary to mark the deletion status in the current version, copy the target data and update the version flag field of the new data to the current version number, and set the deletion flag field to 1. During data recovery, copy the target data that was inactive in the historical version (i.e., the status identifier field is 0), generate new data and update its version identifier field to the current version number, set the status identifier field to 1, and set the deletion identifier field to 0.

5. The incremental change method based on version number according to claim 1, characterized in that, The process of storing the business data and corresponding field information of each iteration version in S3 is as follows: Let the stored data set be , Any data item in , A unique identifier for data, used to distinguish different business data; data item The corresponding version identifier field value is The status identifier field takes the value of The deletion identifier field takes the value of ; The key operational information set during the data change process is as follows , Any operation information is , This is a unique identifier for each operation, used to distinguish different change operations. The target data identifier mapping relationship is as follows: ; in, A positive integer, representing a data item. The iteration version, with an initial value of 1 that increases sequentially in subsequent iterations; The value can be 0 or 1, where 1 represents a data item. Valid in the corresponding version and historical traceability; 0 represents a data item. It is not working in the corresponding version; The value can be 0 or 1, where 1 represents a data item. Marked for deletion, 0 represents a data item. Not deleted; It includes data related to the operation type, target data identifier, version change information, and operation time. Used for association and , express Target data identifier and of Consistent; Storage relationship satisfies and This means that only business data items from each iteration that conform to the field value rules, along with their associated change operation information, are stored; business data items that have not changed are not included repeatedly. Through mapping relationship This enables the association between operational information and data items.

6. The incremental change method based on version number according to claim 1, characterized in that, The key operation information in S3 includes at least the operation type, target data identifier, version change information, and operation time-related data.

7. The incremental change method based on version number according to claim 1, characterized in that, The filtering rules in S4 are constructed based on the deletion identifier field, the version identifier field, and the status identifier field. The specific construction process is as follows: Let the target version number be The version identifier field of the data to be filtered takes the value of The status identifier field takes the value of The deletion identifier field takes the value of The target version's valid data set is The data validity determination function is: ; in, A positive integer, corresponding to the iteration version number specified in the query request; It is a positive integer representing the iteration version to which the data belongs. The initial value is 1 and it increases sequentially in subsequent iterations. The value can be 0 or 1, where 1 indicates that the data is valid in the corresponding version and historical traceability, and 0 indicates that the data is invalid in the corresponding version. The value can be 0 or 1, where 1 indicates that the data has been marked for deletion, and 0 indicates that the data has not been deleted. This is a binary decision function. A value of 1 indicates that the data meets the requirements of the target version, and a value of 0 indicates that it does not. The filtering rules are constructed based on the mutual exclusion principle of logical operations, and the judgment logic is defined by the following formula: ， That is, only when the data deletion identifier field is 0 and the version identifier field is equal to the target version number. Or the version identifier field value is less than the target version number. Furthermore, when the status identifier field is set to 1, the data is considered complete and valid for the target version and is included in the target version's data set; ultimately, through... Build filtering rules.

8. The incremental change method based on version number according to claim 1, characterized in that, The complete and valid data set in S4 includes newly added but not deleted data in the target version and data from historical versions that have not been deleted and are still valid.

9. A version number-based incremental change system, characterized in that, include: The multi-dimensional identifier field configuration unit is used to configure version identifier field, status identifier field and deletion identifier field for business data, define the value rules of each field and the business mapping relationship, and complete the unified identification of the version attribute, validity status and deletion status of business data through the three types of fields; The incremental change and historical retention unit is used to receive data change requests, identify the change type and target data, and only perform corresponding change operations on the target data that has changed. The original field information of the unchanged data remains unchanged. During the change process, the version identifier field, status identifier field and deletion identifier field corresponding to the target data are updated synchronously. The historical data status is retained by generating new data by copying the target data, without directly modifying the core content of the original version data. The traceability storage and redundancy optimization unit is used to store business data and corresponding field information of each iteration version using a traceability storage method, synchronously record key operation information during the data change process, complete the traceability management of the entire life cycle of business data, and avoid duplicate storage of unchanged data. The target version dataset filtering unit is used to filter the stored business data according to preset filtering rules when receiving a target version query request, and then merge and return the complete and valid dataset corresponding to the target version.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is executed by a processor as described in any one of claims 1-8, a version number-based incremental change method.

Images