A cloud database-based engineering archiving and approval data management method and system

Abstract

The application discloses a kind of engineering archiving approval data management method and system based on cloud database, it is related to engineering archiving approval technical field, to solve the problem of low efficiency of multi-department cooperation, data version control confusion, complex authority management in traditional engineering archiving approval data management, the method comprises: in response to the parallel approval operation of at least two approval terminals to the same engineering archiving data, record each parallel approval operation corresponding approval event, according to each approval event associated with engineering archiving data in the recorded approval event flow and the approval authority rule corresponding to each approval department, the independent approval state and the overall approval state of engineering archiving data under each approval department dimension are aggregated and calculated;Each independent approval state and overall approval state calculated are written into the approval state view table for query display.

Description

Technical Field

[0001] This application relates to the field of engineering archiving and approval technology, and in particular to a method and system for managing engineering archiving and approval data based on a cloud database. Background Technology

[0002] Throughout the lifecycle of large-scale engineering projects, the management of archived and approved project documents is a core and complex task. These documents encompass everything from planning documents, design drawings, and material specifications at the project initiation stage, to progress reports and quality inspection records during construction, and finally to acceptance reports and final delivery documents upon project completion. Traditionally, the management and approval processes for these documents have often faced challenges such as inefficient collaboration between multiple departments, chaotic data version control, and complex access control. Summary of the Invention

[0003] This application provides a cloud database-based method and system for managing engineering archive approval documents, aiming to solve the problems of low efficiency in multi-department collaboration, chaotic data version control, complex permission management, and the inability of existing sequential process models to effectively handle the approval needs of multiple departments in parallel, independent judgment and time-sensitive situations, resulting in complex status management and coordination difficulties in the traditional management of engineering archive approval documents.

[0004] Firstly, to address the aforementioned technical problems, this invention provides a method for managing engineering archive approval documents based on a cloud database, applied to an engineering archive approval system deployed in a cloud database. The method includes: responding to parallel approval operations initiated by at least two approval terminals on the same engineering archive document; recording approval events corresponding to each parallel approval operation; wherein, before recording the approval event, verifying whether the current document version identifier of the engineering archive document is consistent with the document version identifier used during the operation; allowing the writing of the approval event only if they are consistent, otherwise rejecting the writing; the approval event includes an event type, operator identifier, operation timestamp, the targeted engineering archive document identifier, and the document version identifier used during the operation; aggregating and calculating the independent approval status and overall approval status of the engineering archive document at each approval department dimension based on each approval event associated with the engineering archive document in the recorded approval event stream and the preset approval permission rules corresponding to each approval department; and writing the calculated independent approval status and overall approval status into an approval status view table for querying and display.

[0005] Secondly, this application provides a cloud database-based engineering archive approval data management system. The system includes: a recording unit, used to respond to parallel approval operations initiated by at least two approval terminals on the same engineering archive data, recording the approval events corresponding to each parallel approval operation. Before recording the approval event, it verifies whether the current data version identifier of the engineering archive data is consistent with the data version identifier used during the operation. Only when they are consistent is writing the approval event allowed; otherwise, writing is rejected. The approval event includes an event type, operator identifier, operation timestamp, the targeted engineering archive data identifier, and the data version identifier used during the operation. A processing unit, used to aggregate and calculate the independent approval status and overall approval status of the engineering archive data at each approval department level based on each approval event associated with the engineering archive data in the recorded approval event stream and the preset approval permission rules corresponding to each approval department. An execution unit, used to write the calculated independent approval status and overall approval status into an approval status view table for querying and display.

[0006] This application has at least the following beneficial effects: The cloud database-based engineering archive approval document management method disclosed in this application, by responding to parallel approval operations initiated by at least two approval terminals for the same engineering archive document, strictly verifies the consistency of document version identifiers before recording approval events, and only allows the writing of approval events when they are consistent. This effectively solves the conflict and data chaos caused by inconsistent document versions in multi-department parallel approvals, ensuring the atomicity of approval operations and data accuracy. Simultaneously, based on the recorded approval event flow and preset approval permission rules, this method aggregates and calculates the independent approval status and overall approval status of engineering archive documents at each approval department level, and writes them into the approval status view table. This mechanism overcomes the limitations of existing sequential process models in handling multi-department parallel and independent judgment approvals, avoids the complexity of exponentially increasing status numbers, and achieves clear and real-time management of complex parallel approval statuses. Through event-driven and state projection design, this method can efficiently coordinate independent approval progress, avoid unnecessary waiting, significantly improve approval efficiency and accuracy, and provide a centralized, efficient, and scalable digital management platform for large-scale engineering projects, effectively solving technical problems such as low collaboration efficiency, chaotic data version control, and complex permission management in traditional management. Attached Figure Description

[0007] Figure 1 This is a flowchart illustrating a cloud database-based method for managing engineering archive approval documents, as provided in this application. Detailed Implementation

[0008] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0009] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0010] In the management of large-scale engineering projects, the management of archived approval documents has always been a complex and critical task. Traditional management methods often face challenges such as inefficiency, chaos, and complexity in multi-departmental collaboration, data version control, and access control. Especially when dealing with the approval of as-built documents that involve multiple disciplines, high risks, and tight deadlines, traditional sequential process models struggle to effectively coordinate multiple independent and concurrent approval paths, leading to complex status management, low process efficiency, and potentially causing logical conflicts or unnecessary waiting.

[0011] In view of the above problems, this application provides a cloud database-based method for managing engineering archive approval documents. By introducing an event tracing mechanism and state projection service, this application effectively solves the limitations of traditional sequential processes in handling parallel approvals, ensures data consistency and traceability of the approval process, and significantly improves the efficiency of multi-department collaboration.

[0012] The following specific embodiments will provide a detailed introduction and explanation of the cloud database-based engineering archive approval data management method provided in this application.

[0013] Reference Figure 1 This application provides a method for managing engineering archive approval documents based on a cloud database. The method may include the following steps: S1. In response to parallel approval operations initiated by at least two approval terminals on the same project archive data, record the approval events corresponding to each parallel approval operation.

[0014] Before recording an approval event, it verifies whether the current version identifier of the project archive data is consistent with the version identifier of the data used during the operation. Only if they are consistent is the writing of the approval event allowed; otherwise, the writing is rejected. The approval event includes the event type, operator identifier, operation timestamp, the target project archive data identifier, and the version identifier of the data used during the operation.

[0015] It should be noted that cloud databases refer to database services deployed on cloud computing platforms. They provide high availability, scalability, and elastic scaling capabilities, making them suitable for handling large-scale concurrent access and data storage needs.

[0016] The engineering archiving approval system is a software system that runs on a cloud database and is used to manage the approval process for various types of archival materials for engineering projects.

[0017] An approval terminal refers to the device or client on which a user (such as an approver) performs an approval operation, such as a personal computer, tablet, or smartphone.

[0018] Engineering archives refer to the collection of various documents, drawings, reports, and other information that need to be approved and archived during the life cycle of an engineering project.

[0019] Document version identifiers are tags used to uniquely identify a specific version of archived project documents, and are typically incremented and updated when the document content changes.

[0020] An approval event refers to a specific operational record that occurs during the approval process, such as approval, rejection, or withdrawal.

[0021] Event types are used to distinguish between different types of approval operations.

[0022] Operator ID is used to uniquely identify the user who performs the approval operation.

[0023] The operation timestamp records the exact time when the approval operation occurred.

[0024] The project archive document identifier is used to uniquely identify the approved project archive documents.

[0025] Specifically, when at least two approval terminals initiate parallel approval operations on the same project archive data, the system records the approval events corresponding to each parallel approval operation. Before recording the approval events, the system verifies whether the current version identifier of the project archive data is consistent with the version identifier used during the operation. This verification mechanism is crucial to ensuring data consistency. For example, when approval terminal A and approval terminal B simultaneously load the same data for approval, they each obtain the current version identifier of the data. If, before approval terminal A submits its approval operation, the content of the data is modified by other operations, causing the version identifier to change, then when approval terminal B submits its approval, the version identifier it uses will be inconsistent with the latest version identifier of the data. In this case, the system will refuse to write the approval event to approval terminal B, thereby avoiding approval based on expired data and effectively preventing the "dirty write" problem. If the version identifiers are consistent, writing the approval event is allowed. The approval event includes the event type, operator identifier, operation timestamp, the target project archive data identifier, and the version identifier used during the operation. This information constitutes a complete historical record of the approval process.

[0026] S2. Based on the recorded approval events associated with the project archive data in the approval event stream and the preset approval authority rules corresponding to each approval department, aggregate and calculate the independent approval status and overall approval status of the project archive data under each approval department dimension.

[0027] Among them, the approval event flow refers to the sequence of all approval events associated with the archived data of a specific project, arranged in chronological order.

[0028] The approval authority rules define the responsibilities and authority of each approval department during the approval process.

[0029] Independent approval status indicates the approval result of the project archived materials under a specific approval department.

[0030] The overall approval status indicates the final approval result of the project archives under the comprehensive judgment of all relevant approval departments.

[0031] In some embodiments, after recording approval events, the system aggregates and calculates the independent approval status and overall approval status of the project archives at each approval department level, based on the approval events associated with the project archives in the recorded approval event stream and the preset approval permission rules corresponding to each approval department. For example, for a set of as-built documents requiring joint approval from the design department, construction department, and supervision department, the system calculates the independent approval status of the design department, construction department, and supervision department respectively, based on the approval events of each department in the event stream. These independent approval status calculations can be based on various rules; for example, a department's independent approval status can be set to "approved" if the department head performed the approval operation, or set to "pending review" if no approval operation has been performed or a previous approval has been withdrawn. After calculating each independent approval status, the system determines the overall approval status of the project archives based on preset approval conditions, such as "all key departments have approved." This separate calculation method allows each department to conduct approvals independently without waiting for approval results from other departments, greatly improving the efficiency of parallel approvals.

[0032] S3. Write the calculated individual approval status and overall approval status into the approval status view table used for querying and display.

[0033] The approval status view table is a data structure used to store and display the approval status of project archives, making it convenient for users to query and monitor.

[0034] In some embodiments, the system writes the calculated individual approval statuses and the overall approval status into an approval status view table for querying and display. The approval status view table is an optimized data structure for fast querying and display. For example, it can be a relational database table containing an engineering archive document identifier, an overall approval status field, and individual approval status fields for each department. When a user needs to view the approval progress of a specific engineering archive document, they can directly retrieve the latest status information from this view table without needing to aggregate and calculate the event stream in real time. This design decouples complex event processing and status calculation logic from the front-end query and display logic, improving system response speed and user experience.

[0035] This application introduces an event sourcing mechanism, recording each approval operation as an independent, immutable approval event and storing it in the event log. This design enables the system to handle parallel approvals in a natural and efficient manner. Regardless of how many approval terminals operate on the same document simultaneously, each operation is recorded as an independent event, without blocking each other. The document version verification mechanism further ensures that all parallel operations are based on the latest document content, effectively avoiding data inconsistency issues.

[0036] In some of the embodiments described above in this application, a parallel approval operation is proposed in response to at least two approval terminals initiating the same project archive data, and the approval events corresponding to each parallel approval operation are recorded. However, in its implementation, if the recording method of the approval events fails to fully guarantee their immutability and integrity, it may lead to difficulties in tracing the approval process, or even the risk of data being illegally modified or deleted, thereby affecting the credibility and compliance of the approval results.

[0037] In this regard, this application further proposes the recording of approval events corresponding to each parallel approval operation, including: The approval events are stored in the event log table of the cloud database in an append-only manner to complete the recording of the approval events corresponding to each parallel approval operation; the event log table only allows the insertion of new records and prohibits modification or deletion of existing records; The event types of the approval events include approval operation types and withdrawal operation types, wherein the approval event corresponding to the withdrawal operation type also includes a withdrawal reason field.

[0038] Specifically, the event log table can be understood as a database table specifically used to store approval events, its core feature being its "append-only" storage mode. This means that once an approval event is recorded and stored in the table, data can only be added by appending new records; existing records cannot be modified or deleted. Its purpose is to ensure that the historical record of all approval operations is complete and tamper-proof, providing a reliable data foundation for subsequent auditing and traceability. The event types for approval events can include approval operation types and withdrawal operation types. Approval operation types record the approver's approval of project archive documents. Withdrawal operation types record the approver's withdrawal of their previous approval. In practical applications, to enhance the transparency and traceability of withdrawal operations, the approval event corresponding to the withdrawal operation type also includes a withdrawal reason field. This field records the specific reason for the approver's withdrawal of approval, such as "incomplete document content" or "requires supplementary attachments," aiming to provide contextual information for the withdrawal operation, facilitating subsequent review and understanding.

[0039] This application's solution effectively addresses the immutability and integrity issues of approval event records that may exist in the basic solution by introducing an event log table and adopting an append-only writing method. Because the event log table only allows the insertion of new records and prohibits modification or deletion of existing records, every approval operation, whether approval or withdrawal, is permanently recorded as an immutable event. This mechanism ensures the integrity of the approval event flow; any change to the approval status must be reflected by generating a new event, rather than modifying an old one. Furthermore, by clearly distinguishing between approval and withdrawal operation types and adding a withdrawal reason field to withdrawal operation events, this application's solution can clearly record all forward and reverse operations in the approval process and provide detailed background information for withdrawal operations, thereby constructing a highly reliable and easily auditable approval history chain.

[0040] Through the above technical solution, this application can significantly improve the data integrity and traceability of engineering archive approval data management. Because approval events are stored in the event log table in an append-only manner and cannot be modified or deleted, it ensures that the original records of all approval operations are permanently preserved, effectively preventing malicious tampering or accidental loss, and greatly enhancing the credibility of the approval data. Simultaneously, through clear event type classification and the introduction of a withdrawal reason field, every decision point in the approval process and its reasons are clearly traceable, providing a solid and reliable chain of evidence for subsequent audits, compliance checks, and problem tracing, thereby improving the transparency and reliability of the entire approval system.

[0041] In some preferred embodiments, a specific example is given below. Suppose that some project archive documents require approval from Department A and Department B. When an approver in Department A approves the documents, the system generates an approval event of type approval operation and stores it in the event log table of the cloud database in append mode. This event includes the operator identifier (approverr in Department A), operation timestamp, the identifier of the project archive document, and the document version identifier used during the operation. Subsequently, if the approver in Department A finds that their approval needs to be modified and decides to withdraw the approval, the system generates an approval event of type withdrawn operation, which includes a withdrawal reason field, such as "missing document attachments". This withdrawn event is also stored in the event log table in append mode. During this process, existing approval events in the event log table are not modified or deleted; instead, the status change is reflected by appending new withdrawn events. In this way, no matter how complex the approval process is, including multiple approvals and withdrawals, the event log table will faithfully record the complete sequence of all operations, forming an immutable approval history, thereby ensuring the transparency and auditability of the approval process.

[0042] In some of the embodiments described above in this application, the independent approval status and overall approval status of the archived project data are aggregated and calculated based on the recorded approval event stream, and then written into an approval status view table. However, in actual implementation, if the frequency of approval events is high, or if it is necessary to reflect the approval status in real time and consistently, performing aggregation calculations directly during each query or operation may lead to performance bottlenecks, or make it difficult to guarantee the real-time performance and data consistency of the status view table, especially in a distributed cloud database environment.

[0043] In this regard, this application further proposes the following steps for the above-mentioned aggregated calculation of the independent approval status and overall approval status of the project archive data under each approval department dimension: A state projection service, independent of the approval operation processing flow, continuously monitors newly added approval events in the event log table used to store approval events; After detecting a new approval event, the state projection service retrieves all historical approval events associated with the project archive document identifier from the event log table. Based on the preset approval authority rules corresponding to each approval department, the event types in all historical approval events are aggregated and analyzed to determine the independent approval status corresponding to each approval department. Based on the independent approval status of each approval department and the preset approval conditions, the overall approval status of the project archived materials is determined; the approval conditions include the requirements of the approval departments that must reach the approved status in the independent approval status of each approval department.

[0044] Specifically, the state projection service can be understood as a background service or microservice component designed to transform raw event data in the event log table into aggregated state data that is easy to query and display. This service is configured to continuously monitor the event log table, meaning it can detect the writing of any new approval event in real-time or near real-time. This monitoring mechanism can be implemented in various ways, such as utilizing the stream processing capabilities provided by cloud databases (e.g., Change Data Capture (CDC), message queue subscriptions, or periodic polling). Its purpose is to ensure that once a new approval event occurs, the state projection service can respond promptly and update the approval status.

[0045] Upon detecting a new approval event, the state projection service retrieves all historical approval events associated with the specific project archive document identifier from the event log table. This step is crucial for ensuring the completeness and accuracy of state calculations, as determining any approval state requires all historical operation records of that document. The event log table, as an immutable source of facts, stores the complete sequence of all approval operations.

[0046] In practical applications, the state projection service aggregates and analyzes all event types from all historical approval events acquired, based on preset approval authority rules corresponding to each approval department. For example, for a specific approval department, its independent approval status may depend on the latest status of all approval and withdrawal operations performed by that department. Approval authority rules can define which event types (such as approval and withdrawal) affect the approval status of a specific department, and how to determine the final status based on these events (e.g., the latest operation determines the status, or all members' approval is required). Through this aggregated analysis, the independent approval status of each approval department can be accurately determined.

[0047] Furthermore, after determining the independent approval status of each approval department, the status projection service determines the overall approval status of the project archive documents based on these independent statuses and preset approval conditions. The approval conditions are the core of the business logic; they define the conditions required for project archive documents to be considered "approved." For example, it might require all designated approval departments to reach the "approved" status, or it might only require approval from some key departments. This hierarchical calculation allows for flexible management of complex approval processes and clearly reflects the overall approval progress of the documents.

[0048] Through the above technical solution, this application can achieve real-time, efficient, and consistent updates of approval status. Since the status projection service operates independently of the approval operation process, the response speed of the approval operation is not affected by the computational complexity of the status, thereby improving the system's concurrent processing capabilities and user experience. Furthermore, by aggregating and calculating all historical approval events as fact sources, the accuracy and traceability of the approval status are ensured, avoiding inconsistencies caused by concurrent operations or data delays. This design pattern is particularly suitable for cloud database environments with high concurrency and strong consistency requirements, significantly improving the robustness and maintainability of the engineering archiving approval system.

[0049] In some preferred embodiments, it is assumed that an engineering archive requires approval from three departments: the Design Department, the Quality Inspection Department, and the Finance Department. When the Design Department and the Quality Inspection Department submit their approval actions for the archive almost simultaneously, these two actions are appended to the event log table as independent approval events. The state projection service continuously monitors the event log table, and upon detecting these two new events, it immediately retrieves all historical approval events for the engineering archive from the event log table. For example, if there are no other events beforehand, it will retrieve the approval events from the Design Department and the Quality Inspection Department.

[0050] Specifically, the state projection service performs aggregated analysis based on preset approval permission rules. For example, the rules might stipulate that the design department and the quality control department only need one approval operation for their independent approval status to be "approved"; while the finance department requires approval from its head. In the current example, the independent approval status of the design department and the quality control department will be determined as "approved".

[0051] Furthermore, suppose the approval conditions stipulate that the overall approval status of the project archives is "Approved" only when the Design Department, Quality Control Department, and Finance Department all reach the "Approved" status. In this case, since the Finance Department has not yet approved, even if the Design Department and Quality Control Department have approved, the overall approval status of the project archives will still be determined as "Pending Review" or "Partially Approved." Ultimately, these calculated individual approval statuses and the overall approval status will be written into the approval status view table for the approval terminal to query and display. When the Finance Department subsequently submits an approval operation, the status projection service will trigger the calculation again and update the approval status view table, ultimately updating the overall approval status to "Approved." This mechanism ensures the dynamic and accurate updating of the approval status and effectively supports complex approval process management.

[0052] In some of the embodiments described above in this application, although verifying the document version identifier before recording approval events is proposed to ensure data consistency, in actual engineering archiving approval processes, when multiple approval terminals operate on the same archived engineering documents in parallel, if the document content changes during the approval process, the approval terminals may perform approval operations based on outdated document versions. Even if the system ultimately refuses to write the approval event, it may still reduce the work efficiency of the approvers and cause unnecessary inconvenience. Without a clear mechanism to guide approval terminals to obtain the latest document version and promptly notify users of document updates, the user experience and the smoothness of the approval process may be affected.

[0053] In this regard, this application further proposes a method that includes: When the approval terminal loads the archived project data, it sends the current data version identifier back to the approval terminal. Receive approval operation requests submitted by the approval terminal based on the loaded data version, the request carrying the data version identifier on which it is based; Before converting the approval operation request into an approval event and writing it into the event log table, query the cloud database for the latest data version identifier of the project archive data; If the latest document version identifier matches the document version identifier carried in the approval request, then writing to the approval event is allowed; If the latest data version identifier does not match the data version identifier carried in the approval request, the write will be rejected and a prompt message indicating that the data has been updated will be returned to the approval terminal.

[0054] Specifically, when an approval terminal performs an approval operation for the first time or reloads project archive data, the project archive approval system proactively sends the current data version identifier to the terminal. This data version identifier is a snapshot of the data at the time of loading and is used for version comparison during subsequent approval operations. When the approval terminal completes the approval operation and submits the approval request, the request carries the data version identifier used by the approval terminal when loading the data. This is to ensure that the system can identify the data version on which the user's operation is based. Further, before converting the approval operation request into an approval event and attempting to write it to the event log table, the system queries the cloud database for the latest data version identifier of the project archive data. This step is to obtain the current, latest version status of the data. The system then compares the latest data version identifier found with the data version identifier carried in the approval request. If they match, it indicates that the data version operated by the approval terminal is consistent with the current latest version, allowing the approval event to be written to the event log table. Conversely, if the latest data version identifier does not match the data version identifier carried in the approval request, it indicates that the data being processed by the approval terminal is no longer the latest version. The system will refuse to write the approval event and return a prompt message to the approval terminal indicating that the data has been updated, so that the user is informed that the data has changed and that the latest data needs to be reloaded before proceeding with the approval operation.

[0055] Through the above technical solution, this application effectively avoids approval terminals from performing approval operations based on outdated data, thereby ensuring the validity of approval events and the real-time consistency of data. When data changes during the approval process, the system can promptly detect and reject approval requests based on older versions of data, and clearly inform the user that the data has been updated by returning a prompt message to the approval terminal, significantly improving the user experience and the smoothness of the approval process. This not only reduces invalid operations and repetitive work caused by version conflicts, but also enhances the robustness and reliability of the entire project archiving approval system, ensuring that the accuracy of approval decisions is always based on the latest project archive data.

[0056] In some preferred embodiments, a specific example is given below. Assume that the current version identifier of an archived project document, "Project A Design Drawings," is "V1.0." Approval terminal A loads this document for approval, and the system returns "V1.0." At this time, another user modifies the content of "Project A Design Drawings," causing the latest version identifier of this document in the cloud database to be updated to "V1.1." Subsequently, approval terminal A completes the approval and submits an approval operation request, which carries the version identifier "V1.0" used when loading the document. Before the system attempts to convert the approval operation request into an approval event and write it to the event log table, the system queries the cloud database for the latest version identifier of "Project A Design Drawings," and the query result is "V1.1." Since "V1.1" is inconsistent with "V1.0" carried in the approval request, the system will refuse to write the approval event and return a prompt message to approval terminal A: "Document has been updated, please reload." After receiving the notification, terminal A will reload the "Project A Design Drawing," now obtaining version "V1.1," and can continue the approval process based on the latest version. This mechanism ensures that all approval operations are based on the latest document version, avoiding approval errors or data corruption caused by inconsistent document versions.

[0057] In some of the embodiments described above in this application, although a scheme has been proposed to record approval events, including approval operation types and withdrawal operation types, and to aggregate and calculate the independent approval status and overall approval status of the project archive data under each approval department dimension based on the event flow, in practical applications, if an approval department has completed the approval operation and recorded the corresponding approval event, and if it needs to withdraw the approval for any reason, the basic scheme may need to recalculate the overall status. This may be inefficient in some scenarios, or it may not provide a direct and clear mechanism to quickly respond to and update the withdrawal operation of the approved status, which may affect the flexibility of the approval process and the user experience.

[0058] In response, this application further proposes a method for handling approval withdrawal operations, which specifically includes: When receiving a withdrawal request from the target approval terminal for a recorded approved operation type approval event, a withdrawal operation type approval event corresponding to the withdrawal request is generated; the withdrawal request includes a withdrawal reason field and a document version identifier updated after withdrawal; the withdrawal operation type approval event includes the operator identifier of the target approval terminal, the withdrawal operation timestamp, the identifier of the targeted project archive document, the withdrawal reason field, and the document version identifier updated after withdrawal; The approval event of the withdrawal operation type is stored in the event log table in an append-only manner; After the State Projection Service detects the withdrawal operation type approval event, it reads the withdrawal operation type approval event from the event log table, updates the independent approval status field related to the approval department corresponding to the target approval terminal in the approval status view table from the approved status to the pending review status, and keeps the values ​​of the independent approval status fields corresponding to other approval departments in the approval status view table unchanged.

[0059] Specifically, when a target approval terminal needs to withdraw a previously submitted approval operation, it will initiate a withdrawal request to the project archiving approval system. This withdrawal request is designed to include a withdrawal reason field, explaining the specific reasons for the withdrawal, as well as the updated document version identifier after the withdrawal, to ensure that the withdrawal operation is based on the latest document version. Upon receiving this withdrawal request, the system will generate a corresponding withdrawal operation type approval event. This withdrawal operation type approval event records in detail the operator identifier of the target approval terminal that initiated the withdrawal operation, the timestamp of the withdrawal operation, the identifier of the targeted project archive document, the specific reason for the withdrawal, and the latest version identifier of the document after the withdrawal operation.

[0060] The generated withdrawal operation type approval event is then stored in the event log table in an append-only manner. The event log table is designed to only allow the insertion of new records and prohibits modification or deletion of stored records, thereby ensuring the integrity and immutability of the approval event flow.

[0061] Furthermore, the state projection service, independent of the approval operation processing flow, continuously monitors the event log table for newly added approval events. Once the state projection service detects a new withdrawal operation type approval event being written, it immediately reads the event from the event log table. Based on the event type contained in the withdrawal operation type approval event, the state projection service identifies it as a withdrawal operation and updates the approval status view table accordingly. Specifically, the independent approval status field related to the approval department corresponding to the target approval terminal that initiated the withdrawal operation will be updated from the original approved status to the pending review status. During this update process, the values ​​of the independent approval status fields corresponding to other approval departments in the approval status view table will remain unchanged to ensure the locality and accuracy of the status update.

[0062] Through the above technical solution, this application provides an efficient and accurate approval status revocation mechanism. First, by generating revocation operation type approval events with detailed information and appending them to the event log table, it ensures that all approval operations, including revocations, are recorded in an immutable manner, thereby enhancing the traceability and auditability of the approval process. Second, the real-time monitoring and processing of revocation events by the status projection service allows the approval status view table to reflect revocation operations instantly, avoiding delays that may be caused by re-aggregation calculations. Furthermore, this solution only updates the independent approval status of the department initiating the revocation, while keeping the status of other departments unchanged, greatly improving the efficiency and accuracy of status updates and reducing unnecessary computational resource consumption. Therefore, this application, while ensuring the rigor of the approval process, significantly improves the system's flexibility and response speed when handling approval status changes, optimizing the user experience.

[0063] In some preferred embodiments, a specific example is given below. Suppose that a project filing document needs to be approved by three departments: the "Design Department," the "Quality Inspection Department," and the "Finance Department." Initially, the document is in a "pending review" state.

[0064] 1. The design department first reviews and approves the materials. The system records an approval event of type approval operation, which includes information such as the operator's identifier, operation timestamp, and material identifier from the design department. After the status projection service detects this event, it updates the independent approval status corresponding to the design department in the approval status view table to "Approved". At this time, the overall approval status may still be "Pending Review" or "Partially Approved".

[0065] 2. Subsequently, the Quality Inspection Department also approved the document, and the system recorded an approval event of another approval operation type. The Status Projection Service updated the independent approval status corresponding to the Quality Inspection Department to "Approved".

[0066] 3. After the design department approves the document but before the finance department approves it, the design department discovers a critical error in the document and needs to withdraw its previous approval. The design department initiates a withdrawal request through the approval terminal, which includes the reason for withdrawal (e.g., "incorrect dimensions on the design drawing") and the updated document version identifier after withdrawal.

[0067] 4. Upon receiving this withdrawal request, the project archiving approval system immediately generates an approval event of the withdrawal operation type. This event records in detail the operator's identifier from the design department, the withdrawal operation timestamp, the identifier of the targeted project archived data, the reason for withdrawal, and the identifier of the updated data version after withdrawal.

[0068] 5. The approval event of this withdrawal operation type is stored in the event log table in an append-only manner.

[0069] 6. The State Projection service continuously monitors the event log table and quickly detects this newly added approval event for the revocation operation type.

[0070] 7. The State Projection service reads the retraction event and identifies it as a retraction operation based on its event type.

[0071] 8. The Status Projection service immediately updates the approval status view table: the independent approval status field corresponding to the Design Department is updated from "Approved" to "Pending Review". Meanwhile, the values ​​of the independent approval status fields corresponding to the Quality Inspection Department and the Finance Department remain unchanged.

[0072] 9. As a result, the approval status view table can reflect in real time and accurately that the design department has withdrawn its approval, and the overall approval status of the project archives may also be rolled back to the "pending review" or "partial approval" status, waiting for the design department to review and approve it again.

[0073] Specifically, the aforementioned approval status view table is used to store and display the approval status of project archive documents.

[0074] The approval status view table includes an overall approval status field for the project archive data and independent approval status fields corresponding to each approval department. The overall approval status field is a comprehensive status identifier calculated based on the values ​​of each independent approval status field and preset approval conditions.

[0075] The overall approval status field indicates the final approval result of a project archive under the combined efforts of all relevant approval departments, such as "Approved," "Pending Review," or "Rejected." This field provides users with a macro-level understanding of the approval progress. The individual approval status fields corresponding to each approval department indicate the approval result for that specific department, such as "Department A Approved" or "Department B Pending Review." These individual status fields reflect the approval progress and decisions of each department.

[0076] Specifically, the calculation of the overall approval status field is accomplished by comprehensively considering the values ​​of all individual approval status fields and combining them with preset approval conditions. For example, approval conditions can specify "all departments have approved" or "at least N key departments have approved," etc. Therefore, the logic for overall approval can be flexibly defined according to actual business needs.

[0077] Through the above technical solution, the approval status view table can present the approval progress of project archives in a structured and easy-to-understand manner. Users can obtain the overall approval results at a glance, while also gaining in-depth understanding of the specific decisions made by each approval department, thereby improving the efficiency and accuracy of approval status queries. This clear field division helps improve the readability and user experience of the system, and provides clear data support for subsequent approval process management and decision-making.

[0078] In some of the embodiments described above in this application, although the engineering archiving approval system can record the approval events corresponding to each parallel approval operation through an event log table and ensure its immutability, for users or auditors, how to conveniently and systematically trace the complete approval process of specific engineering archival materials and present it as a reliable chain of evidence in a clear and orderly manner remains an aspect that needs further improvement. Without providing a clear traceability mechanism and interface, when auditing, reviewing, or resolving disputes in the approval process is required, it will be difficult to efficiently obtain and display complete historical information, thereby affecting the transparency and credibility of the system. Therefore, this application further proposes a scheme for the engineering archiving approval system to provide an approval history traceability interface to achieve comprehensive traceability of the engineering archival material approval process.

[0079] In the above method, the project archiving approval system also provides an approval history tracing interface. When a tracing request for the target project archive materials is received, the approval history tracing interface is used to retrieve all approval events associated with the target project archive material identifier from the event log table, arrange them in the order of the operation timestamps in each approval event, and return them for display. The arranged sequence of approval events constitutes a traceable evidence chain of the approval process of the target project archive materials.

[0080] Specifically, the approval history tracing interface is a functional entry point provided by the system, allowing authorized users or system callers to query the complete approval history of archived materials for a specific project. Upon receiving a tracing request, this interface queries the event log table in the cloud database based on the target project archived material identifier contained in the request. The event log table, as persistent storage for all approval events, contains detailed information such as event type, operator identifier, operation timestamp, the targeted project archived material identifier, and the material version identifier used during the operation. The retrieval operation aims to accurately identify all approval events related to the target project archived material identifier. The retrieved approval events are sorted in ascending order based on their internally recorded operation timestamps. The operation timestamp is precise time information automatically recorded by the system when each approval event occurs; sorting it ensures that the order of approval events is completely consistent with the actual timeline. The sorted sequence of approval events is returned to the requester for display, for example, presented as a list or timeline on the user interface. Thus, this sequence constitutes a traceable chain of evidence for the approval process of the target project's archived documents, with the aim of providing a complete, tamper-proof, and easily understandable approval history to support auditing, compliance checks, and dispute resolution.

[0081] Through the aforementioned technical solution, this application provides a comprehensive and reliable mechanism for tracing approval history. Compared to basic solutions that only record approval events, this application integrates scattered approval events and presents them in chronological order through an approval history tracing interface, forming a complete traceable chain of evidence for the approval process. This not only greatly simplifies auditing and review work and improves efficiency, but also ensures the authenticity and completeness of the approval history due to the immutability of the event log table and the precise sorting of timestamps, effectively avoiding the risk of information omission or tampering. Therefore, this application significantly enhances the transparency, credibility, and compliance of the engineering archiving approval system, providing users with powerful historical query and auditing support capabilities.

[0082] In some preferred embodiments, suppose a project manager needs to query the complete approval history of an archived project document named "Bridge Design Scheme". The project manager can use the user interface provided by the project archive approval system to select "Bridge Design Scheme" and click the "View Approval History" button. At this time, the system's internal approval history tracing interface is invoked and receives a tracing request for "Bridge Design Scheme". This interface then queries the event log table in the cloud database to retrieve all approval events associated with the "Bridge Design Scheme" identifier, such as "Zhang San submitted approval on January 1, 2023", "Li Si approved on January 2, 2023", "Wang Wu withdrew approval with reasons on January 3, 2023", and "Zhao Liu re-approved on January 4, 2023", etc. After retrieval, these events are sorted according to their respective operation timestamps, for example, arranged in the order of January 1, 2023, January 2, 2023, January 3, 2023, and January 4, 2023. Finally, the system returns this orderly sequence of approval events to the project manager and displays it on the user interface in the form of a timeline. It clearly presents every operational detail of the "bridge design plan" from submission to final approval, including the operator, operation type, operation time, and any relevant notes (such as the reason for withdrawal), thus forming a complete and auditable chain of evidence for the approval process.

[0083] In some of the embodiments described above in this application, a method for managing engineering archive approval documents based on a cloud database is proposed. Approval events are stored in an event log table via append-only writing, and aggregated and calculated using a state projection service before being written to an approval status view table. However, in actual implementation, if the underlying technology of the cloud database is not properly selected, it may not effectively support the high-concurrency writing of approval operations, the immutability of event logs, and the real-time query requirements for approval status. This is especially true in scenarios involving large-scale engineering archive documents and numerous approval departments, potentially leading to performance bottlenecks and data consistency challenges.

[0084] In this regard, this application further proposes: The cloud database uses a NoSQL database service that supports distributed append write operations. The event log table uses an append write-optimized table structure stored by primary key partitioning in the NoSQL database service. The approval status view table uses a relational database table or a document-oriented NoSQL collection that supports fast point-and-click lookup.

[0085] Specifically, the NoSQL database service supporting distributed append-only write operations refers to a non-relational database system whose design philosophy focuses on achieving high availability, scalability, and data consistency, and is particularly optimized for append-only write performance. This type of service typically distributes data across multiple nodes to handle high-concurrency write requests and ensures that data is immutable once written, thus naturally supporting the immutability requirements of event logs.

[0086] The event log table employs an append-write optimized table structure with primary key partitioning in this NoSQL database service. This means that the data in the event log table is distributed across different physical storage partitions based on its primary key (e.g., project archive identifier or event timestamp). This partitioning strategy, combined with append-write characteristics, minimizes write conflicts, improves write throughput, and ensures the integrity and order of historical event records.

[0087] In practical applications, the approval status view table employs either a relational database table that supports fast point-and-click lookup or a document-oriented NoSQL collection. Relational database tables, with their structured query language and transactional features, provide robust data consistency and complex query capabilities, making them suitable for displaying approval statuses that require precise aggregation and multi-dimensional queries. Document-oriented NoSQL collections, with their flexible schema and native support for complex data structures, also enable fast reading and display of approval statuses, making them particularly suitable for scenarios where the status data structure may change dynamically. Both types of databases excel at efficient data retrieval based on specific identifiers (such as engineering archive document identifiers) to meet the query and display requirements of the approval status view table.

[0088] Through the above technical solutions, this application can significantly improve the performance and scalability of the engineering archiving and approval system when handling high-concurrency approval operations. Specifically, by using a NoSQL database service that supports distributed append writes to store event logs, the fast and reliable recording of approval events is ensured, and the immutability of events is naturally supported, providing strong data protection for the traceability and auditing of the approval process. At the same time, by deploying the approval status view table in a relational database or document-oriented NoSQL collection that supports fast point-and-click queries, the query efficiency of approval status is greatly optimized, enabling approvers to obtain the approval progress of engineering archive materials in real time and accurately, thereby improving the response speed and user experience of the entire approval process. This combination of heterogeneous databases effectively solves the performance bottlenecks and data management problems that may occur in traditional single database architectures when dealing with complex business scenarios.

[0089] In some preferred embodiments, this application is implemented as follows: As a specific implementation, the cloud database can employ a NoSQL database service that supports distributed append-only write operations, such as Amazon DynamoDB or Apache Cassandra. The event log table can be designed in DynamoDB with the project archive identifier as the partition key and the operation timestamp as the sort key, thereby achieving primary key partitioned storage and efficient append-only writes. When an approval event occurs, a new event record is appended to the corresponding partition, and DynamoDB's characteristics ensure that these records cannot be modified once written.

[0090] Furthermore, the approval status view table can be a relational database table in Amazon Aurora (a relational database service compatible with MySQL or PostgreSQL), or a document-oriented NoSQL collection such as MongoDB. For example, in Aurora, a table named "ApprovalStatusView" can be created, containing fields such as project archive document identifier, overall approval status, and individual approval status for each approval department. After the status projection service detects new events in the event log table, it aggregates and calculates the latest approval status based on these events and updates the result to the "ApprovalStatusView" table. Since both Aurora and MongoDB support fast point-and-click operations, the approval terminal can quickly obtain the required information from this view table when querying the approval status of specific project archive documents. This combination enables the system to handle both high-concurrency event writes and provide efficient real-time status queries.

[0091] In some embodiments described above, this application proposes verifying the consistency between the current version identifier of the project archive data and the version identifier used during the operation before recording the approval event, to ensure the atomicity and data consistency of the approval operation. However, in its implementation, if the content of the project archive data changes between the time period after loading it on the approval terminal and before submitting the approval operation, the approval terminal may perform the approval based on an outdated version, resulting in a discrepancy between the approval result and the latest data content, affecting the accuracy and effectiveness of the approval.

[0092] In this regard, this application further proposes a method for managing data version identification, including: When the content of the project archive data is changed, the data version identifier field in the master record of the corresponding project archive data stored in the cloud database is incremented and updated. The changed data version identifier is used to represent the latest content version of the project archive data. When the approval terminal loads the project archive data for the first time to perform the approval operation, the project archive approval system records the first data version identifier corresponding to the loading time of the approval terminal, and uses the first data version identifier as the data version identifier based on the subsequent submission of approval operations by the approval terminal. When at least one content change operation occurs on the same project archive data between the initial loading and the submission of the approval operation, the data version identifier field in the master record of the project archive data stored in the cloud database is incremented and updated according to each content change operation. When the project archive approval system detects that the first data version identifier used by the approval terminal when submitting the approval operation is inconsistent with the latest data version identifier, it refuses to write the approval event corresponding to the approval terminal and returns a prompt message to the approval terminal. The prompt message is used to prompt the approval terminal to reload the project archive data based on the latest data version identifier and then perform the approval operation again.

[0093] Specifically, any modification, replacement, or update to the actual content of the project archive materials (such as documents, images, attachments, etc.) is considered a "content change operation." At this time, the document version identifier field in the master record storing the project archive materials in the cloud database will be automatically incremented. This increment can be a simple numerical increment, or it can generate a new unique identifier based on a timestamp or hash value. The core purpose is to ensure that a new, unique document version identifier is generated for each content change, accurately reflecting the latest content status of the project archive materials.

[0094] Specifically, when an approval terminal loads a project archive document from the project archive approval system for the first time in preparation for approval, the system immediately records the document version identifier corresponding to that loading moment and marks it as the "first document version identifier." Subsequently, this first document version identifier will serve as the base version used by the approval terminal when submitting approval operations in subsequent transactions.

[0095] In practical applications, if the content of the project archive data undergoes at least one change after being loaded by the approval terminal but before the terminal submits the approval operation, the data version identifier field of the master record of the project archive data in the cloud database will be updated accordingly based on each content change operation. When the approval terminal attempts to submit the approval operation, the project archive approval system will perform a verification: comparing the first data version identifier used by the approval terminal when submitting the operation with the latest data version identifier of the project archive data in the current cloud database. If the two are inconsistent, it indicates that the approval terminal is attempting to approve an outdated data version. At this time, the system will refuse to write the approval event corresponding to the approval terminal, return a prompt message to the approval terminal, clearly informing it that the data has been updated, and guide the approval terminal to reload the latest version of the project archive data before attempting the approval operation again.

[0096] Through the above technical solution, this application can significantly improve the data consistency and accuracy in the engineering archiving and approval process. This solution ensures that approvers always review the latest version of the archived engineering documents, effectively avoiding discrepancies between the approval results and the actual documents caused by changes in document content during the approval process. Furthermore, by returning clear prompts to the approval terminal, guiding users to reload the latest documents, not only is the system's robustness improved, but the user experience is also optimized, reducing the risk of operational errors and thus ensuring the rigor and reliability of the engineering archiving and approval process.

[0097] The following is a specific example to illustrate this. Suppose that the current version of the archived project data "Project A Design Drawings" is identified as V1.

[0098] At a certain moment, approver Zhang San loads "Project A Design Drawing" into the approval terminal for approval. At this time, the project archiving approval system records the document version identifier that Zhang San used when loading the document as V1, and uses it as the "first document version identifier" for Zhang San's subsequent approval operations.

[0099] While Zhang San was reviewing the "Project A Design Drawing," another designer, Li Si, modified and saved the content of the "Project A Design Drawing." At this moment, the data version identifier field of the master record of the "Project A Design Drawing" in the cloud database will automatically increment and update to V2, making V2 the latest version of the data.

[0100] When Zhang San completes the review and attempts to submit the approval operation for "Project A Design Drawing" through the approval terminal, the engineering archiving approval system will first verify whether the "first document version identifier" (V1) used by Zhang San when submitting the operation is consistent with the latest document version identifier (V2) of "Project A Design Drawing". Since V1 and V2 are inconsistent, the system will reject Zhang San's approval event writing and return a prompt message to Zhang San's approval terminal, such as "The document you are approving has been updated. Please reload the latest version and approve again".

[0101] After receiving the notification, Zhang San reloads the "Project A Design Drawing," where he will see the V2 version of the documentation. Zhang San reviews and submits the document for approval based on version V2. When the system verifies the document again, it finds that the version identifier (V2) he used matches the latest version identifier (V2), thus allowing the write of the approval event and completing the approval process.

[0102] In some embodiments, this application proposes a cloud database-based engineering archive approval data management system, comprising: a recording unit, configured to respond to parallel approval operations initiated by at least two approval terminals on the same engineering archive data, and record approval events corresponding to each parallel approval operation, wherein before recording the approval event, it verifies whether the current data version identifier of the engineering archive data is consistent with the data version identifier used during the operation, and only allows writing the approval event if they are consistent, otherwise it refuses to write, the approval event including event type, operator identifier, operation timestamp, the targeted engineering archive data identifier, and the data version identifier used during the operation; a processing unit, configured to aggregate and calculate the independent approval status and overall approval status of the engineering archive data under each approval department dimension according to each approval event associated with the engineering archive data in the recorded approval event stream and the preset approval permission rules corresponding to each approval department; and an execution unit, configured to write the calculated independent approval status and overall approval status into an approval status view table for query and display.

[0103] This system aims to address the challenges of traditional engineering archiving and approval processes in terms of multi-departmental parallel collaboration, data version control, and access management. By introducing a recording unit, a processing unit, and an execution unit, the system can efficiently handle concurrent approval requests, ensuring accurate recording of approval events and consistency of document versions. The recording unit is responsible for capturing and verifying all approval operations, forming a complete event flow; the processing unit, based on this event flow and preset rules, intelligently calculates the independent approval status of documents in each department and the overall approval status; the execution unit persists these statuses for quick querying and display. This modular design enables the system to effectively coordinate multiple independent approval processes, avoiding the state explosion and logical conflicts problems of traditional sequential processes, significantly improving approval efficiency and data reliability.

[0104] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing engineering archiving and approval documents based on a cloud database, characterized in that, The method, applied to an engineering archiving and approval system deployed in a cloud database, includes: In response to at least two approval terminals initiating parallel approval operations on the same project archive data, the approval events corresponding to each parallel approval operation are recorded. Before recording the approval event, it is verified whether the current data version identifier of the project archive data is consistent with the data version identifier used during the operation. Only when they are consistent is the writing of the approval event allowed; otherwise, the writing is rejected. The approval event includes event type, operator identifier, operation timestamp, the target project archive data identifier, and the data version identifier used during the operation. Based on the recorded approval events associated with the project archives in the approval event stream and the preset approval authority rules corresponding to each approval department, the independent approval status and overall approval status of the project archives under each approval department dimension are aggregated and calculated. The calculated individual approval statuses and overall approval status are written into the approval status view table used for querying and display.

2. The method according to claim 1, characterized in that, The record of approval events corresponding to each parallel approval operation includes: The approval events are stored in the event log table of the cloud database in an append-only manner to complete the recording of the approval events corresponding to each parallel approval operation; the event log table only allows the insertion of new records and prohibits modification or deletion of existing records; The event types of the approval events include approval operation types and withdrawal operation types, wherein the approval event corresponding to the withdrawal operation type also includes a withdrawal reason field.

3. The method according to claim 1, characterized in that, The process involves aggregating and calculating the independent approval status and overall approval status of the project archive data at each approval department level, based on each approval event associated with the project archive data in the recorded approval event stream and the preset approval authority rules corresponding to each approval department. This includes: A state projection service, independent of the approval operation processing flow, continuously monitors newly added approval events in the event log table used to store approval events; After detecting a new approval event, the state projection service retrieves all historical approval events associated with the project archive document identifier from the event log table. Based on the preset approval authority rules corresponding to each approval department, the event types in all historical approval events are aggregated and analyzed to determine the independent approval status corresponding to each approval department. Based on the independent approval status of each approval department and the preset approval conditions, the overall approval status of the project archived materials is determined; the approval conditions include the requirements of the approval departments that must reach the approved status in the independent approval status of each approval department.

4. The method according to claim 2, characterized in that, The method further includes: When the approval terminal loads the archived project data, it sends the current data version identifier back to the approval terminal. Receive approval operation requests submitted by the approval terminal based on the loaded data version, the request carrying the data version identifier on which it is based; Before converting the approval operation request into an approval event and writing it into the event log table, query the cloud database for the latest data version identifier of the project archive data; If the latest document version identifier matches the document version identifier carried in the approval request, then writing to the approval event is allowed; If the latest data version identifier does not match the data version identifier carried in the approval request, the write will be rejected and a prompt message indicating that the data has been updated will be returned to the approval terminal.

5. The method according to claim 2, characterized in that, The method further includes: When receiving a withdrawal request from the target approval terminal for a recorded approved operation type approval event, a withdrawal operation type approval event corresponding to the withdrawal request is generated; the withdrawal request includes a withdrawal reason field and a document version identifier updated after withdrawal; the withdrawal operation type approval event includes the operator identifier of the target approval terminal, the withdrawal operation timestamp, the identifier of the targeted project archive document, the withdrawal reason field, and the document version identifier updated after withdrawal; The approval event of the withdrawal operation type is stored in the event log table in an append-only manner; After the State Projection Service detects the withdrawal operation type approval event, it reads the withdrawal operation type approval event from the event log table, updates the independent approval status field related to the approval department corresponding to the target approval terminal in the approval status view table from the approved status to the pending review status, and keeps the values ​​of the independent approval status fields corresponding to other approval departments in the approval status view table unchanged.

6. The method according to claim 1, characterized in that, The approval status view table includes an overall approval status field for the project archive data and independent approval status fields corresponding to each approval department. The overall approval status field is a comprehensive status identifier calculated based on the values ​​of each independent approval status field and preset approval conditions.

7. The method according to claim 2, characterized in that, The project archiving approval system also provides an approval history tracing interface. When a tracing request for the archived data of the target project is received, the approval history tracing interface is used to retrieve all approval events associated with the target project archived data identifier from the event log table, arrange them in the order of the operation timestamps in each approval event, and return them for display. The arranged sequence of approval events constitutes a traceable evidence chain of the approval process of the target project archived data.

8. The method according to claim 2, characterized in that, The cloud database uses a NoSQL database service that supports distributed append write operations. The event log table uses an append write-optimized table structure stored by primary key partitioning in the NoSQL database service. The approval status view table uses a relational database table or a document-oriented NoSQL collection that supports fast point-and-click lookup.

9. The method according to claim 1, characterized in that, The method further includes: When the content of the project archive data is changed, the data version identifier field in the master record of the corresponding project archive data stored in the cloud database is incremented and updated. The changed data version identifier is used to represent the latest content version of the project archive data. When the approval terminal loads the project archive data for the first time to perform the approval operation, the project archive approval system records the first data version identifier corresponding to the loading time of the approval terminal, and uses the first data version identifier as the data version identifier based on the subsequent submission of approval operations by the approval terminal. When at least one content change operation occurs on the same project archive data between the initial loading and the submission of the approval operation, the data version identifier field in the master record of the project archive data stored in the cloud database is incremented and updated according to each content change operation. When the project archive approval system detects that the first data version identifier used by the approval terminal when submitting the approval operation is inconsistent with the latest data version identifier, it refuses to write the approval event corresponding to the approval terminal and returns a prompt message to the approval terminal. The prompt message is used to prompt the approval terminal to reload the project archive data based on the latest data version identifier and then perform the approval operation again.

10. A cloud database-based engineering archiving and approval document management system, characterized in that, include: The recording unit is used to respond to parallel approval operations initiated by at least two approval terminals on the same project archive data, and to record the approval events corresponding to each parallel approval operation. Before recording the approval event, it verifies whether the current data version identifier of the project archive data is consistent with the data version identifier used during the operation. Only when they are consistent is the writing of the approval event allowed; otherwise, the writing is rejected. The approval event includes event type, operator identifier, operation timestamp, the target project archive data identifier, and the data version identifier used during the operation. The processing unit is used to aggregate and calculate the independent approval status and overall approval status of the project archive data under each approval department dimension based on each approval event associated with the project archive data in the recorded approval event stream and the preset approval authority rules corresponding to each approval department. The execution unit is used to write the calculated individual approval status and overall approval status into the approval status view table for query and display.

Images