One-stop data table inspection method, device and equipment and storage medium

Abstract

The application discloses a one-stop data table inspection method and device, equipment and a storage medium, and relates to the technical field of financial technology, which comprises the following steps: obtaining production object list information; based on the production object list information, analyzing the reconstruction table features corresponding to the production contents of multiple production objects to determine the reconstruction table information; based on the reconstruction table information, inspecting the backup table name information, comparison range information and association condition information in the corresponding system temporary table to determine the inspection result; and based on the check result and the registration result in the inspection result, controlling the system to monitor the production object and push the production progress. The application analyzes the reconstruction table features corresponding to the production contents of multiple production objects, inspects the backup table name, comparison range and association condition in the system temporary table, generates an inspection result, monitors the production object and pushes the production progress, realizes the full-process automation from object identification to result registration, improves the verification efficiency and accuracy, and enhances the controllability of production.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a one-stop data table verification method, apparatus, equipment and storage medium. Background Technology

[0002] As business systems continue to iterate and technology upgrades, database tables in the data warehouse often undergo structural adjustments due to business changes or system restructuring. To ensure that data warehouse objects remain consistent with the business system, it is necessary to rebuild, initialize, and perform related verification work on the changed tables to ensure data accuracy and system stability. Therefore, multiple concurrent projects are involved, and the verification objects are complex and numerous.

[0003] Currently, existing practices require reviewing the deployment details of each production object individually, which has different verification content and standards. During the verification process, SQL needs to be manually written and executed, and the verification results also need to be registered in offline tables one by one. However, due to the lack of unified automation tools, the existing practices are not intuitive in obtaining verification objects, are prone to omissions, have non-standard verification processes, are difficult to trace results, and have low operational efficiency. They cannot cope with concurrent scenarios of multiple projects, and offline registration is cumbersome and information integration is difficult. Therefore, how to conduct one-stop data table verification more accurately and effectively has become an urgent problem to be solved.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a one-stop data table verification method, apparatus, equipment and storage medium, aiming to solve the technical problem of how to perform one-stop data table verification more accurately and effectively.

[0006] To achieve the above objectives, this application proposes a one-stop data table verification method, the method comprising:

[0007] Obtain the list of projects to be put into production; Based on the production object list information, the reconstruction table features corresponding to the production content of multiple production objects are parsed to determine the reconstruction table information; Based on the reconstructed table information, the backup table name information, comparison range information, and association condition information in the corresponding system temporary table are checked to determine the check result. Based on the verification and registration results in the inspection results, the system monitors the objects put into production and pushes the production progress.

[0008] In one embodiment, the step of obtaining the list of objects to be put into production includes: Get scheduled task information; Based on the time interval in the timed task information, scan the production object records in the predefined production registration database to determine the production object record information; The production object list information is obtained based on the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time in the production object record information.

[0009] In one embodiment, the step of parsing the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information to determine the reconstruction table information includes: Determine the corresponding exchange scenario type and table type based on the production object list information; Based on the parsing rules corresponding to the exchange scenario type and the table type, the reconstruction table features corresponding to the production content of multiple production objects are parsed to obtain reconstruction table information, which includes cluster name, data area, mode name, table name, and production object name.

[0010] In one embodiment, the step of verifying the backup table name information, comparison range information, and association condition information in the corresponding system temporary table based on the reconstruction table information, and determining the verification result, includes: Based on the reconstruction table information, the backup table name in the corresponding system temporary table is queried using pattern matching to determine the backup table name information. Based on the backup table name information, the comparison range and association conditions corresponding to different table types are identified, and the comparison range information and association condition information are determined. The backup table name information, the comparison range information, and the association condition information are verified to obtain the verification results.

[0011] In one embodiment, the step of identifying the comparison range and association conditions corresponding to different table types based on the backup table name information, and determining the comparison range information and association condition information, includes: Based on the backup table name information, the current table, snapshot table, and transaction table in the corresponding table type are identified to determine the table type information; Based on the table form information, the corresponding comparison range information is determined from the preset comparison range options. The comparison range information includes full table comparison information, snapshot date comparison information, and data date comparison information. Based on the backup table name information, query the primary key field of the reconstruction table in the corresponding system configuration table to determine the primary key field information of the reconstruction table. Based on the primary key field information of the reconstructed table, corresponding association condition information is generated according to the preset association syntax.

[0012] In one embodiment, the step of verifying the backup table name information, the comparison range information, and the association condition information to obtain the verification result includes: Based on the backup table name information, the comparison range information, and the association condition information, generate corresponding table-level verification scripts and field-level verification scripts; Based on the table-level verification script and the field-level verification script, the structural differences and correlation results between the reconstructed table and the backup table are verified to obtain the verification results.

[0013] In one embodiment, the step of controlling the production-initiated object and pushing production progress based on the verification results and registration results in the inspection results includes: Based on the verification results in the test results, the corresponding verification records, verification clusters and verification results are verified to determine the target verification result; The comparison result is determined by comparing the target verification result with the registration result in the inspection result. Based on the comparison results, the system monitors the objects to be put into production and pushes the production progress.

[0014] Furthermore, to achieve the above objectives, this application also proposes a one-stop data table verification device, which includes: The production object acquisition module is used to obtain the production object list information; The reconstruction table acquisition module is used to parse the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information, and determine the reconstruction table information. The verification and registration module is used to verify the backup table name information, comparison range information and association condition information in the corresponding system temporary table based on the reconstruction table information, and determine the verification result; The monitoring and notification module is used to control the production monitoring objects and push production progress based on the verification results and registration results in the inspection results.

[0015] In addition, to achieve the above objectives, this application also proposes a one-stop data table verification device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the one-stop data table verification method as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the one-stop data table verification method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This embodiment proposes a one-stop data table verification method, which obtains a list of objects to be put into production; based on the list of objects, it analyzes the reconstruction table features corresponding to the production content of multiple objects to determine the reconstruction table information; based on the reconstruction table information, it verifies the backup table name information, comparison range information, and association condition information in the corresponding system temporary table to determine the verification result; and based on the verification results and registration results in the verification results, it controls the system to monitor the objects to be put into production and push the production progress. This application automates the entire process of reconstruction table verification from object identification and data comparison to result registration, significantly improving verification efficiency and accuracy, reducing the workload of offline registration, and enhancing the overall controllability of the production process. Attached Figure Description

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

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a system architecture diagram of the one-stop data table verification method of this application; Figure 2 This is a flowchart illustrating an embodiment of the one-stop data table verification method of this application. Figure 3 This application presents a diagram illustrating the entity relationship between the table objects in the one-stop data table verification method and the table object during production and reconstruction. Figure 4 Reconstruct the table list and the entity relationship diagram of the field verification results for the one-stop data table verification method in this application; Figure 5 This is a flowchart illustrating Embodiment 2 of the one-stop data table verification method of this application; Figure 6 A simplified flowchart illustrating the one-stop data table verification method provided in this application embodiment; Figure 7 This is a schematic diagram of the module structure of the one-stop data table verification device according to an embodiment of this application; Figure 8 This is a schematic diagram of the hardware operating environment involved in the one-stop data table verification method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is: to obtain the production object list information; to parse the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information, and to determine the reconstruction table information; to verify the backup table name information, comparison range information and association condition information in the corresponding system temporary table based on the reconstruction table information, and to determine the verification result; and to control the system to monitor the production objects and push the production progress based on the verification result and registration result in the verification result.

[0025] In this embodiment, for ease of description, the following description will focus on a one-stop data sheet verification device.

[0026] Due to the lack of unified automated tools in existing technologies, the acquisition of verification objects is not intuitive and is prone to omission. The verification process is not standardized, the results are difficult to trace, and the operation efficiency is low. It cannot cope with concurrent scenarios of multiple projects, offline registration is cumbersome, and information integration is difficult.

[0027] This application provides a solution, such as Figure 1 As shown, Figure 1 This is a system architecture diagram for the one-stop data table verification method of this application. The one-stop data table verification system includes a production object acquisition module, a reconstruction table acquisition module, a verification registration module, and a monitoring and notification module. The system connects to the production deployment platform through the production object acquisition module and automatically obtains the production object list information based on the scheduled task configuration. The reconstruction table acquisition module parses the production content and identifies the reconstruction table information involving table changes. The verification registration module obtains the corresponding backup table information from the system's temporary table through pattern matching, and, combined with the user-supplemented association conditions and comparison range, calls the data verification platform to perform verification. It also supports verification registration, review registration, and log viewing. The monitoring and notification module tracks the verification status in real time through verification review progress monitoring and data verification monitoring, thereby realizing closed-loop control of the entire process of table reconstruction verification.

[0028] As can be seen from the above embodiments, this application determines the reconstruction table information by parsing the reconstruction table features corresponding to the production content of multiple production objects. Based on the reconstruction table information, the backup table name, comparison range and association conditions in the system temporary table are checked to generate the check results. Based on the verification and registration status in the check results, the production objects are monitored and the production progress is pushed. The entire process of reconstruction table verification from object identification, data comparison to result registration is automated, which significantly improves the verification efficiency and accuracy, reduces the workload of offline registration, and enhances the overall controllability of the production process.

[0029] Based on this, the embodiments of this application provide a one-stop data table verification method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the one-stop data table verification method of this application.

[0030] In this embodiment, the one-stop data table verification method includes steps S10 to S40: Step S10: Obtain the list of objects to be put into production; It should be noted that the production object list information is a collection of information automatically generated by the deployment platform after the object deployment is completed during the system upgrade or data reconstruction process. It is used to record all the required production objects. The production object is a database entity that needs to be deployed, modified or verified, which may include exchange scenarios, data processing jobs, database tables and views, etc. After the deployment platform completes the deployment operation, the relevant information of the production object will be recorded and stored in the production registration database. The production object collection module can scan the production registration database in the form of a scheduled task to obtain the latest production object list information.

[0031] In a specific embodiment, as an optional implementation, timed task information is obtained; based on the time interval in the timed task information, the production object records in the predefined production registration database are scanned to determine the production object record information; based on the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time in the production object record information, a production object list information is obtained. That is, when obtaining the production object list information, the production objects to be deployed will register production information in the database and provide a query interface after deployment on the deployment platform. High-frequency scanning is performed by setting a timed task. This timed task is based on a predefined time interval, such as every 5 minutes or 10 minutes, and automatically performs a scan operation. During the scanning process, the system queries the predefined production registration database, which stores all... For deployed objects that have been put into production, the system extracts their record information, including the object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time. The object name uniquely identifies each object, the verification completion flag indicates whether data verification is complete, the verifier is the account of the person performing the verification operation, and the verification time is the timestamp of verification completion. The review completion flag indicates whether review is complete, the reviewer is the account of the person performing the review operation, and the review time is the timestamp of review completion. The production time is the planned or actual production time. Based on this information, the system can promptly obtain a list of completed objects, i.e., the production object record information, and assign corresponding verifiers and reviewers to the deployers for subsequent verification and registration.

[0032] In a specific embodiment, as another optional implementation, in order to cope with high-frequency production scenarios with multiple projects running concurrently and to prevent objects from being missed, the scanning frequency of the scheduled task can be dynamically adjusted according to the density of the production window. For example, on monthly concentrated production days, the system can shorten the scanning interval to 1 minute to ensure that newly registered production objects can be captured almost in real time. At the same time, the acquisition of production object list information is not limited to passive scanning. The system can also actively listen to the message queue sent by the deployment platform. When a new production object is deployed, the deployment platform will send a notification message containing the object information to the message queue. The production object acquisition module can receive and parse the message content in real time by subscribing to the message queue and update the production object list information in real time, thereby further improving the timeliness and accuracy of object acquisition.

[0033] In a specific embodiment, during the process of obtaining the list of objects to be put into production, the system also supports filtering and grouping according to project groups, business lines, or production windows. For example, when it is necessary to verify the current production window of the core deposit system, the system can filter out the objects to be put into production belonging to that window from the complete list according to the production time range and project identifier, and generate a sub-list. This allows the objects to be verified that are scattered in multiple integration packages or deployment details to be uniformly collected and displayed. This approach can focus on verification tasks within a specific scope, avoid interference from irrelevant information, and improve the accuracy of task allocation.

[0034] In one feasible implementation, step S10 may include steps A11 to A13: Step A11: Obtain scheduled task information; It should be noted that the scheduled task information is a set of task configuration parameters preset in the system for periodically performing scanning operations. These parameters include the task name, execution status, start time, and time interval. The module for collecting production objects loads this information at startup and uses it to control the scanning frequency of the production registration database. This ensures that the latest production object records can be obtained in a timely manner, avoiding manual intervention and omissions.

[0035] Step A12: Scan the production object records in the predefined production registration database based on the time interval in the timed task information to determine the production object record information; It should be noted that the information recorded in the production object is obtained by scanning the original data entries from the production registration database. Each record corresponds to a production object that has been deployed and includes various attribute information generated by the object during the deployment process.

[0036] It is understood that the time interval is the scanning cycle set in the scheduled task, such as once every 5 or 10 minutes, in order to balance the system load and the real-time requirements of data acquisition.

[0037] Additionally, it should be noted that the production registration database is a central database specifically used to store deployment information for all production objects. After the deployment platform completes the deployment of an object, it will actively write the relevant data into it. The production object record is a specific data row in the production registration database, which records the detailed deployment information of each production object and is used to generate a production object list.

[0038] Step A13: Based on the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time and production time in the production object record information, obtain the production object list information.

[0039] It is understood that the production object name is a name field used to uniquely identify each production object; the verification completion flag is used to mark whether the data verification work for the object has been completed; the verifier is a record of the personnel account that performed the verification operation; the verification time is a specific timestamp of the verification completion; the review completion flag is used to indicate whether the review and confirmation of the verification result has been completed; the reviewer is a record of the personnel account that performed the review operation; the review time is the time when the review was completed; and the production time is the planned or actual time when the system is put into production.

[0040] Step S20: Based on the production object list information, parse the reconstruction table features corresponding to the production content of multiple production objects to determine the reconstruction table information; It should be noted that the reconstruction table information is metadata related to database table reconstruction parsed from the detailed production content of the production object. It may include fields such as cluster name, data area, schema name, table name, and the corresponding production object name, which are used to determine the reconstruction table that needs to be verified.

[0041] Understandably, because different types of production objects (such as exchange scenarios, jobs, tables, views, etc.) have different production content structures, the way their reconstructed table features are expressed also differs. For example, a table-type production object's production content includes the cluster name, schema name, and table name of the table, while an exchange scenario-type production object's production content includes multiple tables that need to be reconstructed indirectly through the definition of the source table or the target table. Therefore, the process of parsing reconstructed table features requires applying corresponding parsing rules according to the type of production object to accurately identify and extract detailed information of all tables that need to be reconstructed from the complex production content. That is, reconstructed table features are specific features or parameters embedded in these production contents that can identify the table reconstruction operation required, and are data items used to characterize the database table reconstruction-related attributes.

[0042] In a specific embodiment, as an optional implementation, the corresponding exchange scenario type and table type are determined based on the production object list information; the reconstruction table features corresponding to the production content of multiple production objects are parsed according to the parsing rules corresponding to the exchange scenario type and the table type to obtain reconstruction table information. The reconstruction table information includes cluster name, data area, mode name, table name, and production object name. That is, the exchange scenario type and table type corresponding to each production object can be determined based on the production object list information. The exchange scenario type is used to identify whether the production object belongs to a data exchange scenario (e.g., data extraction, transformation, loading process), and the table type is used to identify... Whether the object is a direct database table object is determined by matching the corresponding parsing rules from a preset parsing rule base based on the exchange scenario type and the table type. These parsing rules define how to extract reconstructed table features from the production content. For example, for a production object of the table type, the parsing rule specifies directly reading the cluster name, data area, schema name, and table name from the "table definition" section of the production content. For a production object of the exchange scenario type, the parsing rule specifies parsing all involved tables from the source table mapping or target table definition and recording the name of the production object to which it belongs. By executing these parsing rules, the production content of multiple production objects can be parsed one by one to obtain the reconstructed table information, such as... Figure 3 As shown, Figure 3 This is a diagram showing the entity relationship between the production and reconstruction objects in the one-stop data table verification method of this application. The production object table mainly stores information related to the production object, such as the production object list information, which may include the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time. The reconstruction table mainly stores reconstruction table information, such as the cluster name, data area, schema name, table name, and production object name. The same table needs to be verified in different clusters, which means it is associated with the production object from which it originated, facilitating subsequent traceability.

[0043] In a specific embodiment, as another optional implementation method, during the parsing process, a production object may be involved in multiple reconstruction tables. For example, a data exchange job may operate on multiple source tables and target tables at the same time. In this case, the parsing rules will circulate through all nodes involving tables in the production content and generate an independent reconstruction table information record for each table. Each record is associated with the same production object name. In order to avoid repeated parsing, the system can also introduce a deduplication mechanism to mark the production objects that have been parsed to ensure that the same objects are not processed repeatedly during the timed scanning process.

[0044] In one feasible implementation, step S20 may include steps B11-B12: Step B11: Determine the corresponding exchange scenario type and table type based on the production object list information; It should be noted that the exchange scenario type refers to the specific role or mode of the production object in the data exchange process. For example, it can be an identifier for different scenarios such as data extraction, data loading, and data transformation, which determines the direction of data flow and processing logic. The table type refers to the business form classification of the database table, which can include the current table (stores the latest data), the snapshot table (stores a data mirror of a certain point in time), and the transaction table (records the historical transaction of business operations), etc.

[0045] It is understood that the exchange scenario type and the table type are key features extracted from the list of objects to be put into production, used to determine whether the object to be put into production involves table reconstruction and what verification strategy should be adopted. For example, different types of tables will have different processing rules in terms of data comparison range (full table, by date) and association conditions.

[0046] Step B12: Based on the parsing rules corresponding to the exchange scenario type and the table type, the reconstruction table features corresponding to the production content of multiple production objects are parsed to obtain reconstruction table information. The reconstruction table information includes cluster name, data area, mode name, table name, and production object name.

[0047] It should be noted that the cluster name is a unique identifier for the database cluster, used to locate the physical or logical cluster environment where the reconstructed table resides; the data area is a data storage area division, such as a business data area or a historical data area, to facilitate the differentiation of data management domains; the schema name is a namespace in the database used to organize objects such as tables and views, corresponding to users or business modules; the table name is the name of the specific database table to be reconstructed; and the production object name is the identifier of the associated original production object, used to trace which specific production task the reconstructed table originated from.

[0048] Step S30: Based on the reconstruction table information, verify the backup table name information, comparison range information, and association condition information in the corresponding system temporary table, and determine the verification result; It should be noted that the verification results are the conclusion data obtained after verifying the consistency between the reconstructed table and the backup table. They may include table-level verification results (such as differences in table structure, index consistency, record count comparison, etc.) and field-level verification results (such as the matching status of each field value), which are used to determine whether the reconstruction operation was successful and whether the data is accurate.

[0049] It is understood that the system temporary table is a tablespace in the database environment used to store temporary or backup data. During data reconstruction or change, the system will automatically create a backup of the original table and store it in the system temporary table to ensure that the data can be rolled back.

[0050] In a specific embodiment, based on the reconstructed table information, the backup table name in the corresponding system temporary table is queried using pattern matching to determine the backup table name information. That is, the verification and registration module performs the verification task of the reconstructed table. Upon receiving the reconstructed table information from the reconstructed table acquisition module, the system table is queried using pattern matching based on the cluster name, database name, schema name, and table name to obtain the backup table name. It should be understood that the reconstructed table information includes the cluster name, data area, schema name, and table name. Therefore, the system can query the system temporary table using pattern matching. For example, based on the cluster name and data area in the reconstructed table information, the system connects to the corresponding database instance, uses regular expressions to match the naming rules of backup tables containing the original table name, and determines all relevant backup table names by traversing the matching results. These names are recorded as backup table name information. If multiple backup versions exist, the system will select the most recently created one as the default comparison target, or list all backups for the user to choose from.

[0051] Based on the backup table name information, the system identifies the comparison range and association conditions corresponding to different table types, and determines the comparison range and association conditions. That is, after determining the backup table name, the system needs to identify the appropriate comparison range and association conditions based on the table type. Table types are divided into current table, snapshot table, and transaction table. The current table typically stores the latest full data and uses full table comparison by default. Snapshot tables store data snapshots at time intervals and support comparison by snapshot date or full table comparison. Transaction tables record incremental business transactions and support comparison by data date or full table comparison. The system can automatically match the corresponding comparison range information from preset comparison range options, and also supports user customization based on actual needs. For association conditions, the system obtains the primary key field information of the reconstructed table by querying the system configuration table and generates default association condition information according to preset association syntax, for example, table A.field1 = table B.field1 AND table A.field2 = table B.field2. User modification and supplementation are also supported.

[0052] The backup table name information, comparison range information, and association condition information are verified to obtain the verification results. After the backup table name information, comparison range information, and association condition information are submitted to the data verification platform, the system will automatically perform table-level and field-level verification. The table-level verification mainly compares the structural differences between the reconstructed table and the backup table, including identifying the addition, deletion, and type changes of fields, checking whether the indexes are consistent, whether the number of table records is consistent, and the change in data volume after joining by primary key. The field-level verification further compares the values ​​of each field in the two tables in the association result to determine whether they are equal. After the verification is completed, the system will integrate the above results and display them intuitively, so that the verification conclusion can be quickly obtained without manually writing SQL. At the same time, the platform also provides the function of modifying the schema name and cluster name, supporting flexible data verification work in complex environments with multiple clusters and multiple schema names.

[0053] Step S40: Based on the verification results and registration results in the inspection results, control the system to monitor the production objects and push the production progress.

[0054] It should be noted that the verification result is detailed data generated by the verification registration module after performing table-level and field-level verification, which describes the differences between the reconstructed table and the backup table, and objectively represents the consistency and accuracy between the reconstructed table and the backup table. The registration result is an online confirmation record performed after verification is completed.

[0055] In a specific embodiment, as an optional implementation, the corresponding verification record, verification cluster, and verification result are verified based on the verification result in the inspection result to determine the target verification result; the target verification result is compared with the registration result in the inspection result to determine the comparison result; based on the comparison result, the system monitors the production target and pushes the production progress, that is, the system compares the verification result and registration result in the inspection result to check for data inconsistencies, for example, the verification result shows that the table structure fails, but the registration result is marked as passed, or the registration result is missing. Based on the comparison result, the system can dynamically... The system adjusts the monitoring status of objects to be put into production and triggers corresponding progress updates. For example, if the comparison results are consistent and all objects have been registered, the system marks the status as completed and sends a notification to the project team that all reconstruction table verification work in this production window has been completed. If an object is found to be missing registration or the comparison results are abnormal, the system marks it as pending and immediately sends an early warning notification to the designated development manager and administrator, including the specific object name, the reason for the abnormality, and handling suggestions. It should be understood that the verification results can include validation results and registration results. The validation results can be the reconstruction table list validation results and field validation results, such as... Figure 4 As shown, Figure 4The entity relationship diagram for the reconstructed table list and field verification results of the one-stop data table verification method in this application is provided. The reconstructed table list verification results may include cluster name, data area, schema name, table name, table filter conditions, backup table name, backup table filter conditions, association conditions, and verification results. The field verification results may include cluster name, data area, schema name, table name, table field name, backup table name, backup table field name, and verification results. After that, a two-step registration is required through the verification registration module, namely, registering the verification results and reviewing them to obtain the registration results. Once the registration is completed, the verification is considered to be completed.

[0056] In a specific embodiment, as another optional implementation, after data verification and result registration are completed, the system continuously tracks the execution status of the entire production process to ensure that all reconstruction tables are verified and reviewed within the specified time, and promptly detects any anomalies. Scheduled tasks check in real time whether each production object and its associated reconstruction table has generated verification results, completed verification registration, completed review registration, and whether these registration results are consistent with the actual verification results. When the system detects that all production objects have completed verification and review registration, it means that all verification work in this production window has been completed. At this time, the system sends a summary report, for example, notifying that a certain table has completed verification and is awaiting review, reminding a project team that some objects have not yet started verification, or notifying that production can begin after all objects have completed review. If not, the system identifies the objects that have not yet completed registration and their responsible persons, and sends reminders via email or instant messaging tools to ensure that the verification progress is controllable. In specific embodiments, the monitoring of production objects and the push of production progress by the control system are not limited to passive reminders, but can also be actively queried. It should be understood that the verification status dashboard of all production objects can be viewed in real time through the system interface. The dashboard graphically displays the overall progress, the status distribution of each object, anomaly details, etc. Users can also customize monitoring rules. For example, the verification of a certain core business table must be completed before a specified time. If the time is exceeded, it will be upgraded to an emergency alarm. The system will notify the designated personnel by telephone voice or SMS. The system automatically completes status tracking and risk warning, which significantly reduces the management burden and effectively ensures the quality and efficiency of data warehouse production.

[0057] In one feasible implementation, step S40 may include steps C11-C13: Step C11: Based on the verification results in the inspection results, verify the corresponding verification records, verification clusters and verification results to determine the target verification result; It should be noted that the target verification result is a conclusion obtained by the system after further verification of the verification results. It is understood that the verification record is the historical information of each verification operation saved by the system, used to trace whether the verification was actually executed. The verification cluster is the set of database clusters involved in the verification, ensuring that all clusters that need to be verified have been covered. The verification result is the status indicator of whether each verification recorded in the original verification result has passed. By reviewing the verification record, verification cluster and verification result, the problem of incomplete verification caused by missing verification records, missing clusters or misjudged results can be effectively avoided.

[0058] Step C12: Compare the target verification result and the registration result in the inspection result to determine the comparison result; It should be noted that the comparison results are the conclusions drawn by comparing the target verification results after system review with the registration results.

[0059] It is understood that the registration result essentially includes the registration verification completion mark and the registration review completion mark, representing the verification status confirmed by humans. By comparison, the system can identify abnormal situations such as verified but not registered, registered but not verified, or registration status not matching the verification result, for monitoring reminders and progress push, to ensure closed-loop management of the verification work.

[0060] Step C13: Based on the comparison results, control the system to monitor the production targets and push the production progress.

[0061] It is understood that the monitoring of production targets involves the system continuously tracking the verification status of production targets through scheduled tasks. For example, it scans whether the production targets that need to be verified that day have generated verification records, whether the verification cluster is complete, and whether the verification results have passed, and compares them with the verification and review registration results to promptly identify anomalies or omissions. The push of production progress means that the system proactively sends the monitored status information to the relevant responsible persons in the form of notifications. For example, it notifies the management personnel after all objects have completed verification and review, or reminds the development manager to follow up in a timely manner when an anomaly is found, thereby achieving transparency, automation, and controllability of the verification process.

[0062] This embodiment proposes a one-stop data table verification method, which obtains a list of production objects; based on the list of production objects, it analyzes the reconstruction table features corresponding to the production content of multiple production objects to determine the reconstruction table information; based on the reconstruction table information, it verifies the backup table name information, comparison range information, and association condition information in the corresponding system temporary table to determine the verification result; and based on the verification result and registration result in the verification result, it controls the system to monitor the production objects and push the production progress. This solves the technical problem of how to perform one-stop data table verification more accurately and effectively. Compared with existing technologies, this application determines the reconstruction table information by analyzing the reconstruction table features corresponding to the production content of multiple production objects, verifies the backup table name, comparison range, and association condition in the system temporary table based on the reconstruction table information, generates verification results, and monitors the production objects and pushes the production progress based on the verification and registration status in the verification results. This achieves full automation of the reconstruction table verification process from object identification and data comparison to result registration, significantly improving verification efficiency and accuracy, reducing the workload of offline registration, and enhancing the overall controllability of the production process.

[0063] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0064] In this embodiment, refer to Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the one-stop data table verification method of this application. Step S30 specifically includes steps S31 to S33: Step S31: Based on the reconstruction table information, query the backup table name in the corresponding system temporary table using pattern matching to determine the backup table name information; It should be noted that the backup table name information is the name of the backup table corresponding to the rebuilt table, which is retrieved from the system temporary table and is used to locate the table copy that was automatically generated before the data change.

[0065] It is understood that the pattern matching is a string search technique based on predefined naming rules or wildcards, used to locate backup tables associated with the original table in the database's metadata table. Since backup tables are usually named according to a fixed pattern, all possible backup versions can be discovered through pattern matching rather than exact queries. This approach can adapt to the naming differences of backup tables due to time, version, or cluster differences, ensuring that no matter what rules the backup table is named according to, as long as it conforms to the preset pattern, it can be accurately identified.

[0066] In a specific embodiment, as an optional implementation, when determining the backup table name information, the system obtains the metadata of the table that needs to be verified from the table reconstruction information, including the cluster name, data area, schema name and table name, and connects to the corresponding database instance to access the database's system metadata view. The system uses the structured query language SQL to perform a fuzzy query. By executing this query, the system can return a list of all table names that match the naming pattern, which is the backup table name information.

[0067] In a specific embodiment, as another optional implementation, to handle more complex naming rules, the pattern matching method can be regular expressions. For example, some systems use the original table name followed by underscores and an 8-digit date. The system can be configured with regular expressions for precise pattern matching. If multiple results are matched, the system can automatically select the latest one as the default comparison target based on the creation time, or return all matched backup table names in a list for the user to manually select or confirm.

[0068] Step S32: Based on the backup table name information, identify the comparison range and association conditions corresponding to different table types, and determine the comparison range information and association condition information; It should be noted that the comparison range information refers to the range of data that needs to be compared during the verification process, such as a full table comparison, a comparison by snapshot date, or a comparison by data date, which determines the granularity of the verification. The association condition information is the field correspondence used to connect the reconstructed table and the backup table for comparison. It can be generated based on the primary key or a specified field to ensure that the two records can be correctly matched.

[0069] In a specific embodiment, based on the backup table name information, the current table, snapshot table, and transaction table in the corresponding table structure are identified to determine the table structure information. Based on the table structure information, the corresponding comparison range information is determined from preset comparison range options. The comparison range information includes full table comparison information, snapshot date comparison information, and data date comparison information. That is, the system comprehensively judges the table structure by analyzing the backup table name, table structure comments, field naming rules, and partition information. For example, a table name containing SNAP or snapshot and having a snapshot_date field can be identified as a snapshot table. A table containing LOG, transaction, transaction number, or having date fields such as data_date or trans_date and having a large amount of data can be identified as a snapshot table. Tables identified as transaction tables are generally considered current tables if they lack the aforementioned characteristics. For current tables, the comparison range is typically set to full table comparison to ensure that the reconstructed table contains all original data. For snapshot tables, the system supports two options: comparison by snapshot date (comparing only data partitions for a specific snapshot date) and full table comparison. Users can choose according to their verification objectives. For transaction tables, the system supports comparison by data date (comparing only transaction data for a specific business date) and full table comparison. Furthermore, the system allows users to customize the comparison range according to business needs, such as adding additional filtering conditions to further narrow the comparison range and improve verification efficiency. This allows the acquisition of comparison range information, which includes full table comparison information, snapshot date comparison information, and data date comparison information.

[0070] Based on the backup table name information, the system queries the primary key field of the reconstruction table in the corresponding system configuration table to determine the primary key field information of the reconstruction table. Based on the primary key field information of the reconstruction table, the system generates corresponding association conditions according to a preset association syntax. That is, regardless of the table form, the system queries the primary key field of the reconstruction table in the corresponding system configuration table based on the backup table name information. If a primary key configuration exists, the system automatically generates association conditions according to the preset association syntax: Reconstruction table.primary key field 1 = Backup table.primary key field 1 AND Reconstruction table.primary key field 2 = Backup table.primary key field 2. If the reconstruction table does not define a primary key, the system prompts the user to manually specify the field combination used for association, thereby obtaining the association conditions. It should be understood that for snapshot tables and transaction tables, when generating association conditions, the system will also intelligently determine whether the snapshot date field or data date field needs to be included in the association conditions to ensure that when comparing by date range, the association operation can work in conjunction with the date filtering conditions to avoid data misalignment. For example, when comparing a transaction table by data date, the generated association conditions can be: Reconstruction table.primary key field = Backup table.primary key field AND Reconstruction table.data_date = Backup table .data_date.

[0071] In one feasible implementation, step S32 may include steps D11 to D14: Step D11: Based on the backup table name information, identify the current table, snapshot table, and transaction table in the corresponding table type to determine the table type information; It should be noted that the table format information is a type identifier based on the business characteristics and data storage rules of the database table. It is used to distinguish the update methods and query scenarios of different tables and can include three categories: current table, snapshot table, and transaction table.

[0072] It is understood that the current table is the table that stores the latest business data, and the data will be updated in real time with business operations. The snapshot table is the table that performs a full backup of the data at a specific point in time (such as the end of each day) and is used to trace the historical status. The transaction table is the table that records the details of each business operation. The data is stored in an append-only manner and will not modify the historical records.

[0073] Step D12: Based on the table form information, determine the corresponding comparison range information from the preset comparison range options. The comparison range information includes full table comparison information, snapshot date comparison information, and data date comparison information. It should be noted that the comparison range information refers to the data scanning range defined during verification, which determines the granularity of the verification and can include three types: full table comparison, snapshot date comparison, and data date comparison.

[0074] It is understood that the full table comparison information is a non-discriminatory comparison of all data rows in the rebuilt table and the backup table, which is suitable for the current table or tables with a small amount of data. The snapshot date comparison information only compares the data partitions corresponding to the specified snapshot date, which is suitable for snapshot tables and can avoid scanning the entire table. The data date comparison information is a comparison of data on specific dates filtered by the business date field, which is suitable for transaction tables.

[0075] Step D13: Based on the backup table name information, query the primary key field of the reconstruction table in the corresponding system configuration table to determine the primary key field information of the reconstruction table; It should be noted that the primary key field information of the reconstructed table is the name of the primary key column used to uniquely identify the record in the reconstructed table, which is obtained from the system configuration table. It is either a primary key constraint field in the table definition or a combination of fields that are unique in business terms.

[0076] Understandably, the system uses the backup table name as a query condition to retrieve the corresponding primary key field configuration of the table in the pre-maintained system configuration table, thereby ensuring that the rebuilt table and the backup table can be correctly matched by unique identifier.

[0077] Step D14: Based on the primary key field information of the reconstructed table, generate corresponding association condition information according to the preset association syntax.

[0078] It is understood that the aforementioned association syntax is an SQL join condition expression used to connect the reconstructed table and the backup table for data comparison. It clarifies which fields the two tables are matched with, thereby providing accurate connection logic for subsequent field-level comparisons and avoiding syntax errors or logical deviations that may occur when manually writing SQL.

[0079] Step S33: Verify the backup table name information, the comparison range information, and the association condition information to obtain the verification result.

[0080] Understandably, table-level and field-level verification scripts can be generated based on the backup table name, comparison range, and association conditions. The table-level verification script compares the overall structure of the reconstructed table and the backup table, including the number of fields, field names, data types, field lengths, whether they are nullable, index information, and the number of table records. The field-level verification script, based on the association conditions, compares the data values ​​of corresponding records in the two tables row by row and field by field to see if they are completely consistent. The system submits these two scripts to the data verification platform for execution. The platform extracts data from the two tables according to the filtering conditions in the comparison range, connects them according to the association conditions, and then executes the comparison algorithm. After execution, the platform collects all differences, including structural differences and association result comparison information, and integrates them into the verification result.

[0081] In a specific embodiment, as an optional implementation, a corresponding table-level verification script and field-level verification script are generated based on the backup table name information, the comparison range information, and the association condition information. Based on the table-level verification script and the field-level verification script, the structural differences and association result comparison information between the reconstructed table and the backup table are verified to obtain the verification results. Specifically, the system queries the metadata of the reconstructed table and the backup table using the backup table name information, the comparison range information, and the association condition information to generate field definition lists for both tables. By comparing these two lists, fields existing only in the reconstructed table (field addition), fields existing only in the backup table (field deletion), and fields with the same field name but different data types or lengths (field type change) can be identified. Simultaneously, the script also compares the structural differences and association result comparison information between the two tables, i.e., comparing index information (such as the names and field combinations of primary key indexes, unique indexes, and ordinary indexes) and counting the current total number of records, thereby obtaining the verification results.

[0082] In a specific embodiment, as another optional implementation, the system can display the verification results to developers in a visual manner. For example, the verification results can include table-level differences and field-level differences. Table-level differences can be displayed through a comparison table, highlighting newly added, deleted, or modified fields with different colors. Field-level differences can be displayed in a list format, showing the ID of the inconsistent record, the difference field, the value of the reconstructed table, and the value of the backup table. Clicking on a difference record allows viewing the complete field comparison for that record. For verified items, the system will display a "consistent" or "passed" marker, along with the timestamp and script ID of the verification execution for traceability.

[0083] In one feasible implementation, step S33 may include steps E11-E12: Step E11: Generate corresponding table-level verification scripts and field-level verification scripts based on the backup table name information, the comparison range information, and the association condition information; It should be noted that the table-level verification script is used to check the overall structural differences between the rebuilt table and the backup table, including field definition comparison, index consistency check, table record count statistics, and data volume change analysis after primary key association. The field-level verification script is used to compare field values. After connecting the two tables according to the association conditions, it judges whether the data content matches completely field by field.

[0084] Step E12: Based on the table-level verification script and the field-level verification script, the structural differences and correlation results between the reconstructed table and the backup table are verified to obtain the verification results.

[0085] It is understood that the structural difference information is the comparison result of the rebuilt table and the backup table at the physical structure level obtained by executing the table-level verification script. It may include the addition, deletion, and type change of fields, the consistency status of index definitions, and the change in the number of table records and the amount of data after joining by primary key. The association result comparison information is the matching status of the two tables at the data content level obtained by executing the field-level verification script, that is, whether the values ​​of each corresponding field are completely equal after joining by association conditions, and the specific fields and details of the differences.

[0086] This embodiment proposes a one-stop data table verification method. Based on the reconstructed table information, it queries the backup table name in the corresponding system temporary table using pattern matching to determine the backup table name information. Based on the backup table name information, it identifies the comparison range and association conditions corresponding to different table types, determining the comparison range information and association condition information. It then verifies the backup table name information, the comparison range information, and the association condition information to obtain the verification result. This solves the technical problem of how to perform one-stop data table verification more accurately and effectively. Compared with existing technologies, this application automatically determines the backup table name information, identifies the comparison range and association conditions corresponding to different table types based on the backup table name, and performs verification by combining the above information to generate verification results. This significantly improves the efficiency and accuracy of data verification, avoids omissions or errors that may occur when manually querying backup tables, ensures that the optimal comparison scheme is used for different table types, and automatically generates association conditions, reducing the workload and error risk of manually writing SQL. It provides a unified and standardized verification basis, enhancing the reliability and traceability of the data change process.

[0087] For example, to help understand the implementation process of the one-stop data table verification method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 6 , Figure 6 A simplified flowchart of a one-stop data table validation method is provided, specifically: Referring to Example 1, obtain the list of objects to be put into production; based on the list of objects to be put into production, parse the reconstruction table features corresponding to the production content of multiple objects to be put into production, and determine the reconstruction table information; based on the reconstruction table information, verify the backup table name information, comparison range information, and association condition information in the corresponding system temporary table, and determine the verification result; based on the verification result and registration result in the verification result, control the system to monitor the objects to be put into production and push the production progress. Referring to Example 2, based on the reconstruction table information, query the backup table name in the corresponding system temporary table using pattern matching to determine the backup table name information; based on the backup table name information, identify the comparison range and association conditions corresponding to different table forms, and determine the comparison range information and association condition information; verify the backup table name information, the comparison range information, and the association condition information to obtain the verification result. The system processes the objects to be put into production, determining whether they involve table reconstruction. If not, the process ends directly. If they do, the system automatically obtains the reconstruction table information and further retrieves the corresponding backup table name, supplements necessary filtering conditions and related information, forms complete verification parameters, and submits them to the verification platform for verification. After verification, the verification result needs to be registered, thus entering the review stage. If the review fails, it needs to be returned for adjustment or re-verification. If the review passes, the review result registration is completed, marking the official end of the entire verification process for the object to be put into production. This process realizes online closed-loop management of the entire process from object identification and data verification to result confirmation, ensuring the integrity and accuracy of the verification work.

[0088] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the one-stop data table verification method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0089] This application also provides a one-stop data sheet verification device, please refer to... Figure 7 The one-stop data table verification device includes: The production object acquisition module 10 is used to obtain the production object list information; The reconstruction table acquisition module 20 is used to parse the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information, and determine the reconstruction table information. The verification and registration module 30 is used to verify the backup table name information, comparison range information and association condition information in the corresponding system temporary table based on the reconstruction table information, and to determine the verification result. The monitoring and notification module 40 is used to control the system to monitor the production objects and push the production progress based on the verification results and registration results in the inspection results.

[0090] The production object acquisition module 10 is also used to acquire timed task information; Based on the time interval in the timed task information, scan the production object records in the predefined production registration database to determine the production object record information; The production object list information is obtained based on the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time in the production object record information.

[0091] The reconstruction table acquisition module 20 is also used to determine the corresponding exchange scenario type and table type based on the production object list information; Based on the parsing rules corresponding to the exchange scenario type and the table type, the reconstruction table features corresponding to the production content of multiple production objects are parsed to obtain reconstruction table information, which includes cluster name, data area, mode name, table name, and production object name.

[0092] The verification and registration module 30 is also used to query the backup table name in the corresponding system temporary table based on the reconstruction table information in a pattern matching manner, and determine the backup table name information; Based on the backup table name information, the comparison range and association conditions corresponding to different table types are identified, and the comparison range information and association condition information are determined. The backup table name information, the comparison range information, and the association condition information are verified to obtain the verification results.

[0093] The verification and registration module 30 is also used to identify the current table, snapshot table and transaction table in the corresponding table form based on the backup table name information, and determine the table form information; Based on the table form information, the corresponding comparison range information is determined from the preset comparison range options. The comparison range information includes full table comparison information, snapshot date comparison information, and data date comparison information. Based on the backup table name information, query the primary key field of the reconstruction table in the corresponding system configuration table to determine the primary key field information of the reconstruction table. Based on the primary key field information of the reconstructed table, corresponding association condition information is generated according to the preset association syntax.

[0094] The verification and registration module 30 is also used to generate corresponding table-level verification scripts and field-level verification scripts based on the backup table name information, the comparison range information and the association condition information; Based on the table-level verification script and the field-level verification script, the structural differences and correlation results between the reconstructed table and the backup table are verified to obtain the verification results.

[0095] The monitoring and notification module 40 is also used to verify the corresponding verification record, verification cluster and verification result based on the verification result in the inspection result, and determine the target verification result; The comparison result is determined by comparing the target verification result with the registration result in the inspection result. Based on the comparison results, the system monitors the objects to be put into production and pushes the production progress.

[0096] The one-stop data table verification device provided in this application, employing the one-stop data table verification method described in the above embodiments, can solve the technical problem of how to perform one-stop data table verification more accurately and effectively. Compared with the prior art, the beneficial effects of the one-stop data table verification device provided in this application are the same as those of the one-stop data table verification method provided in the above embodiments, and other technical features in the one-stop data table verification device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0097] This application provides a one-stop data table verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the one-stop data table verification method in Embodiment 1 above.

[0098] The following is for reference. Figure 8 The diagram illustrates a structural schematic of a one-stop data sheet verification device suitable for implementing embodiments of this application. The one-stop data sheet verification device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The one-stop data sheet verification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0099] like Figure 8As shown, the one-stop data sheet verification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the one-stop data sheet verification device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the one-stop datasheet verification device to communicate wirelessly or wiredly with other devices to exchange data. Although a one-stop datasheet verification device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0100] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0101] The one-stop data table verification device provided in this application, employing the one-stop data table verification method described in the above embodiments, can solve the technical problem of how to perform one-stop data table verification more accurately and effectively. Compared with the prior art, the beneficial effects of the one-stop data table verification device provided in this application are the same as those of the one-stop data table verification method provided in the above embodiments, and other technical features of this one-stop data table verification device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0102] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0103] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0104] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the one-stop data table verification method described in the above embodiments.

[0105] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0106] The aforementioned computer-readable storage medium may be included in a one-stop data sheet verification device; or it may exist independently and not be assembled into a one-stop data sheet verification device.

[0107] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the one-stop data table verification device, the one-stop data table verification device: acquires the production object list information; parses the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information to determine the reconstruction table information; verifies the backup table name information, comparison range information, and association condition information in the corresponding system temporary table based on the reconstruction table information to determine the verification result; and controls the system to monitor the production objects and push the production progress based on the verification result and registration result in the verification result.

[0108] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0111] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described one-stop data table verification method, thereby solving the technical problem of how to perform one-stop data table verification more accurately and effectively. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the one-stop data table verification method provided in the above embodiments, and will not be repeated here.

[0112] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A one-stop data table verification method, characterized in that, The method includes: Obtain the list of projects to be put into production; Based on the production object list information, the reconstruction table features corresponding to the production content of multiple production objects are parsed to determine the reconstruction table information; Based on the reconstructed table information, the backup table name information, comparison range information, and association condition information in the corresponding system temporary table are checked to determine the check result. Based on the verification and registration results in the inspection results, the system monitors the objects put into production and pushes the production progress.

2. The method as described in claim 1, characterized in that, The steps for obtaining the list of production targets include: Get scheduled task information; Based on the time interval in the timed task information, scan the production object records in the predefined production registration database to determine the production object record information; The production object list information is obtained based on the production object name, verification completion flag, verifier, verification time, review completion flag, reviewer, review time, and production time in the production object record information.

3. The method as described in claim 1, characterized in that, The step of parsing the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information to determine the reconstruction table information includes: Determine the corresponding exchange scenario type and table type based on the production object list information; Based on the parsing rules corresponding to the exchange scenario type and the table type, the reconstruction table features corresponding to the production content of multiple production objects are parsed to obtain reconstruction table information, which includes cluster name, data area, mode name, table name, and production object name.

4. The method as described in claim 1, characterized in that, The step of verifying the backup table name information, comparison range information, and association condition information in the corresponding system temporary table based on the reconstructed table information, and determining the verification result includes: Based on the reconstruction table information, the backup table name in the corresponding system temporary table is queried using pattern matching to determine the backup table name information. Based on the backup table name information, the comparison range and association conditions corresponding to different table types are identified, and the comparison range information and association condition information are determined. The backup table name information, the comparison range information, and the association condition information are verified to obtain the verification results.

5. The method as described in claim 4, characterized in that, The step of identifying the comparison range and association conditions corresponding to different table types based on the backup table name information, and determining the comparison range information and association condition information, includes: Based on the backup table name information, the current table, snapshot table, and transaction table in the corresponding table type are identified to determine the table type information; Based on the table form information, the corresponding comparison range information is determined from the preset comparison range options. The comparison range information includes full table comparison information, snapshot date comparison information, and data date comparison information. Based on the backup table name information, query the primary key field of the reconstruction table in the corresponding system configuration table to determine the primary key field information of the reconstruction table. Based on the primary key field information of the reconstructed table, corresponding association condition information is generated according to the preset association syntax.

6. The method as described in claim 4, characterized in that, The step of verifying the backup table name information, the comparison range information, and the association condition information to obtain the verification result includes: Based on the backup table name information, the comparison range information, and the association condition information, generate corresponding table-level verification scripts and field-level verification scripts; Based on the table-level verification script and the field-level verification script, the structural differences and correlation results between the reconstructed table and the backup table are verified to obtain the verification results.

7. The method as described in claim 1, characterized in that, The steps of controlling the production object and pushing the production progress based on the verification results and registration results in the inspection results include: Based on the verification results in the test results, the corresponding verification records, verification clusters and verification results are verified to determine the target verification result; The comparison result is determined by comparing the target verification result with the registration result in the inspection result. Based on the comparison results, the system monitors the objects to be put into production and pushes the production progress.

8. A one-stop data table verification device, characterized in that, The device includes: The production object acquisition module is used to obtain the production object list information; The reconstruction table acquisition module is used to parse the reconstruction table features corresponding to the production content of multiple production objects based on the production object list information, and determine the reconstruction table information. The verification and registration module is used to verify the backup table name information, comparison range information and association condition information in the corresponding system temporary table based on the reconstruction table information, and determine the verification result; The monitoring and notification module is used to control the production monitoring objects and push production progress based on the verification results and registration results in the inspection results.

9. A one-stop data sheet verification device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the one-stop data table verification method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the one-stop data table verification method as described in any one of claims 1 to 7.

Images