Field deletion method of target database and related device

Abstract

Embodiments of the present application disclose a field deletion method of a target database and related equipment, which are used for deleting fields of the target database while improving the field deletion efficiency of the target database. The method comprises the following steps: obtaining entity table fields of the target database; determining and analyzing target code resources of a to-be-analyzed application based on an identifier of the to-be-analyzed application, so as to extract dynamic domain model fields of the to-be-analyzed application; comparing the entity table fields of the target database with the dynamic domain model fields; determining at least one invalid field that exists in the target database but does not exist in the dynamic domain model, the invalid field being a field in the target database without business reference; and generating a deletion script corresponding to the at least one invalid field.

Description

Technical Field

[0001] This application relates to the field of field deletion in a target database, and more specifically, to a method for deleting fields in a target database, a device for deleting fields in a target database, a computer-readable storage medium, and a computer program product containing instructions. Background Technology

[0002] As enterprise information systems continue to evolve, frequent changes in business requirements lead to shorter system iteration cycles, resulting in continuous adjustments to database table structures and the generation of a large number of legacy, obsolete fields. These obsolete fields not only occupy storage space and reduce database performance, but may also cause data confusion and security risks. Therefore, it is necessary to regularly identify and clean up invalid fields.

[0003] Existing technologies employ a manual approach for field cleanup: First, the dynamic domain model fields are extracted manually from the code, and information such as field name and type is recorded. Then, a list of entity table fields is exported using database tools such as Navicat and manually compiled into an Excel spreadsheet. Next, the domain model fields are manually compared with the database fields to mark potentially invalid fields, and personal experience is used to determine whether a field can be deleted. For the marked invalid fields, a deletion script adapted to the target database (such as MySQL or Oracle) is manually written, and finally, the script is executed to complete the cleanup.

[0004] However, existing technologies have the following drawbacks: First, they lack automated parsing capabilities, relying on manual extraction of dynamic fields. When the number of models exceeds 100, the extraction process can take several hours, resulting in low code parsing efficiency and poor fault tolerance. Second, from field extraction and comparison to script writing and execution, extensive manual intervention is required. Adapting to a cleanup scenario with 100 tables takes more than a day, demonstrating low automation and inefficiency. Third, there is no risk grading mechanism, making it easy to accidentally delete core fields during manual judgment, resulting in high cleanup risk. Therefore, existing technologies have low field deletion efficiency in target databases. Summary of the Invention

[0005] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product containing instructions for deleting fields in a target database, thereby improving the efficiency of field deletion in the target database.

[0006] In a first aspect, embodiments of this application provide a method for deleting fields in a target database, including:

[0007] Retrieve the entity table fields from the target database;

[0008] Based on the identifier of the application to be parsed, the target code resources of the application to be parsed are identified and parsed in order to extract the dynamic domain model fields of the application to be parsed.

[0009] The entity table fields of the target database are compared with the fields of the dynamic domain model to identify at least one invalid field that exists in the target database but does not exist in the dynamic domain model. The invalid field is a field in the target database that has no business reference.

[0010] Generate a deletion script corresponding to the at least one invalid field.

[0011] Secondly, embodiments of this application provide a field deletion device for a target database, comprising:

[0012] The retrieval unit is used to retrieve entity table fields from the target database.

[0013] The determining unit is used to determine and parse the target code resources of the application to be parsed based on the identifier of the application to be parsed, so as to extract the dynamic domain model field of the application to be parsed.

[0014] The determining unit is further configured to compare the differences between the entity table fields of the target database and the fields of the dynamic domain model, and determine at least one invalid field that exists in the target database but does not exist in the dynamic domain model, wherein the invalid field is a field in the target database that has no business reference;

[0015] The generation unit is used to generate the deletion script corresponding to the at least one invalid field.

[0016] Thirdly, embodiments of this application provide a field deletion device for a target database, comprising:

[0017] Central processing unit, memory, input / output interfaces, wired or wireless network interfaces, and power supply;

[0018] The memory is either a short-term storage memory or a persistent storage memory;

[0019] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the field deletion method of the aforementioned target database.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the aforementioned field deletion method for the target database.

[0021] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the aforementioned field deletion method for the target database.

[0022] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: by automatically parsing the code to obtain dynamic domain model fields and automatically obtaining database entity table fields, accurate cross-layer comparison is achieved to identify invalid fields without business references, thereby automatically generating a directly executable deletion script. This replaces the existing manual operations of multiple steps such as extraction, sorting, comparison, and script writing, eliminating the time consumption and error risk of manual processing, and realizing full automation of the field cleaning process. Therefore, the field deletion efficiency of the target database in this application is high.

[0023] Accordingly, the target database field deletion device, target database field deletion equipment, computer-readable storage medium, and computer program product containing instructions provided in this application also have the above-mentioned technical effects. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the architecture of a field deletion system for a target database disclosed in an embodiment of this application;

[0025] Figure 2 This is a flowchart illustrating a field deletion method for a target database disclosed in an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of the architecture and interaction process of an invalid field cleanup system based on four-module automated linkage disclosed in an embodiment of this application;

[0027] Figure 4 This is a flowchart illustrating a method for differentially cleaning invalid fields based on risk level, as disclosed in an embodiment of this application.

[0028] Figure 5 This is a schematic diagram of the structure of a field deletion device for a target database disclosed in an embodiment of this application;

[0029] Figure 6 This is a schematic diagram of the structure of a field deletion device for a target database disclosed in an embodiment of this application. Detailed Implementation

[0030] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product containing instructions for deleting fields in a target database, thereby improving the efficiency of field deletion in the target database.

[0031] Please see Figure 1 The architecture of the field deletion system for the target database in this application embodiment includes:

[0032] The target database field deletion device 101 and client 102. When deleting fields in the target database, the target database field deletion device 101 can connect to the client 102. The target database field deletion device 101 can obtain the entity table fields of the target database, obtain the identifier of the application to be parsed sent by the client 102, and based on the identifier of the application to be parsed, determine and parse the target code resources of the application to be parsed to extract the dynamic domain model fields of the application to be parsed. The entity table fields of the target database are compared with the dynamic domain model fields to determine at least one invalid field that exists in the target database but does not exist in the dynamic domain model. The invalid field is a field that has no business reference in the target database, and a deletion script corresponding to at least one invalid field is generated.

[0033] based on Figure 1 For the field deletion system of the target database shown, please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a field deletion method for a target database disclosed in an embodiment of this application. The method includes:

[0034] 201. Obtain the entity table fields of the target database.

[0035] In one optional implementation, the target database refers to the database system to be processed that requires field cleanup. Specifically, a connection can be established with the target database through the database connection module to obtain the target database's configuration information and entity table field data; wherein, the configuration information includes connection parameters and database type, and the entity table field data includes field names, field types, and constraint information; the entity table field data is then transmitted to the difference detection module.

[0036] 202. Based on the identifier of the application to be parsed, determine and parse the target code resources of the application to be parsed in order to extract the dynamic domain model fields of the application to be parsed;

[0037] In one alternative implementation, the application to be parsed refers to an application or software system from which dynamic domain model fields need to be extracted. The target code resource refers to a code file or metadata entity set containing the dynamic domain model definition within the application to be parsed. The dynamic domain model fields of the application to be parsed refer to business entity attributes defined in the code that map to database table fields.

[0038] 203. Compare the differences between the entity table fields in the target database and the fields in the dynamic domain model to identify at least one invalid field that exists in the target database but does not exist in the dynamic domain model. The invalid field is a field in the target database that has no business reference.

[0039] In one optional implementation, the difference detection module can receive entity table field data and dynamic domain model fields, compare the differences between the entity table field data and the dynamic domain model fields, and determine invalid fields that exist in the target database but do not exist in the dynamic domain model. Invalid fields are fields that have no business references in the target database. An invalid field list is generated and passed to the script generation module.

[0040] 204. Generate a deletion script corresponding to at least one invalid field.

[0041] In one alternative implementation, the deletion script refers to an executable SQL statement used to delete invalid fields in the database. Specifically, the script generation module generates a deletion script corresponding to at least one invalid field.

[0042] To facilitate understanding of the embodiments of this application, a specific example is given below.

[0043] Please see Figure 3 , Figure 3 This is a schematic diagram of the architecture and interaction process of an invalid field cleanup system based on four-module automated linkage disclosed in an embodiment of this application. Figure 3 As can be seen, after the user selects the application identifier to be parsed, the code parsing module extracts the dynamic domain model fields based on the identifier and passes them to the difference detection module; the database connection module actively obtains the database configuration information and entity table fields and synchronously passes them to the difference detection module; the difference detection module compares the two types of field data, marks invalid fields and passes them to the script generation module; the script generation module generates a deletion script adapted to the target database and outputs it to the user, realizing fully automated processing from code parsing, field acquisition, difference detection and script generation.

[0044] In this way, by automatically parsing the code to obtain fields from the dynamic domain model and automatically retrieving fields from the database entity table, accurate cross-layer comparison is achieved to identify invalid fields without business references. This then automatically generates a directly executable deletion script, replacing the existing multi-step manual operation of extraction, sorting, comparison, and script writing. This eliminates the time consumption and error risks associated with manual processing, achieving full automation of the field cleanup process. Therefore, the field deletion efficiency of the target database in this application is high.

[0045] In one optional implementation, generating a deletion script corresponding to at least one invalid field includes: determining the risk level of at least one invalid field, generating a deletion script corresponding to at least one invalid field according to the risk level of at least one invalid field, so as to perform a deletion operation corresponding to the risk level of at least one invalid field.

[0046] Specifically, risk level refers to the degree of danger classified based on factors such as the degree of foreign key dependency of invalid fields, data activity, table type, and historical data volume, including high risk, medium risk, and low risk. Deletion operation refers to the differentiated cleanup actions corresponding to the risk level, including but not limited to deletion after manual confirmation for high risk, soft deletion and backup recovery for medium risk, and hard deletion after automatic verification for low risk.

[0047] In this way, by risk classification and differentiated processing, we can avoid the accidental deletion of core data and achieve automated and rapid cleanup of low-risk fields, thus balancing data security and cleanup efficiency.

[0048] In one optional implementation, a deletion script corresponding to at least one invalid field is generated according to the risk level of at least one invalid field to perform a deletion operation corresponding to the risk level of at least one invalid field. This includes: if the database table containing the invalid field has a foreign key constraint and the table associated with the foreign key constraint is a core business table, or if the data activity of the database table containing the invalid field reaches a preset activity threshold, then the invalid field is determined to be a high-risk field. For high-risk fields, a list of high-risk fields containing the dependencies and reference records of the high-risk field is generated. When the list of high-risk fields meets preset conditions, the foreign key status of the high-risk field is verified. After confirming that the foreign key association has been removed, a deletion script corresponding to the high-risk field is generated.

[0049] Specifically, the core business table is the table whose daily average new data volume reaches a preset data volume threshold, or a core business table specified by the user. The preset conditions can refer to receiving a confirmation instruction from the user (manually) regarding the list of high-risk fields, the high-risk fields meeting pre-set automatic pass rules, or other reasonable conditions; no specific limitations are specified here. In one example, for invalid fields determined to be high-risk, a list of high-risk fields containing field dependencies, referenced records, and foreign key association information is generated and output to the user. After receiving the user's confirmation instruction, a pre-validation is performed to confirm that the foreign key association has been removed. After the validation passes, a deletion script is generated and executed. The deletion script includes instructions to first delete the foreign key constraint and then delete the field.

[0050] More specifically, the quantification standard for high-risk fields can be that fields meeting the following conditions are marked as high-risk: 1. Containing foreign key relationships: A FOREIGN KEY constraint exists in the database table, and the related table is a core business table (automatically upgraded to high-risk when the number of foreign key dependencies is ≥2); 2. Belonging to core business tables: Daily average data increase ≥1000, and within core business processes (contract, change, payment related tables; users can select core business tables from the whitelist). The processing flow is as follows: 1. Generate a "High-Risk Field List," the core content of which includes table name, field name, field type, creation time, and last modified person. If it is a foreign key, the table name and corresponding field of the foreign key relationship are also output. 2. Delete script generation (adapted for manual decision-making). If deletion is confirmed, the system generates a deletion script with pre-validation (to avoid direct execution causing relationship failure). Specifically, through pre-validation, it is confirmed that the foreign key relationship has been removed (for foreign key fields): for example...

[0051] "SELECT COUNT(*) FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE

[0052] WHERE REFERENCED_COLUMN_NAME='[field name]' AND REFERENCED_TABLE_NAME = '[table name]'; If the validation passes, execute the deletion (foreign key fields need to have their constraints deleted first): "ALTER TABLE [table name] DROPFOREIGN KEY [foreign key constraint name]; -- Only foreign key fields need ALTER TABLE [table name] DROP COLUMN [field name]".

[0053] In this way, the dual protection of manual confirmation and pre-verification can effectively avoid deletion failures or data anomalies caused by foreign key conflicts, and ensure the security of core field cleanup.

[0054] In one optional implementation, a deletion script is generated for at least one invalid field according to its risk level, to perform deletion operations for at least one invalid field at its corresponding risk level. This includes: if the database table containing the invalid field has no foreign key constraints but has a weak association, the database table containing the invalid field is a regular business table, and the invalid field contains historical data, then the invalid field is determined to be a medium-risk field. For medium-risk fields, a soft deletion script and a recovery script are generated. The soft deletion script is used to rename the medium-risk field to a field name with a deletion marker to retain the original field name of the invalid field. A field-level backup table is created, and an index is built for the field-level backup table. The field-level backup table contains the original field name of the medium-risk field, the primary key of the database table containing the medium-risk field, and time information. The recovery script is used to restore the original field name in the field-level backup table to the renamed field when it is confirmed that the medium-risk field has been mistakenly deleted, and to restore the renamed field to its original field name.

[0055] Specifically, weak associations are represented by views or stored procedures. Regular business tables are non-core process tables with a daily average increase in data volume below a preset threshold. Historical data refers to data where the number of non-empty records reaches a preset threshold. For medium-risk fields (such as non-core fields in regular business tables, or fields without constraints but with historical data), a "soft delete script" is automatically generated to rename the field (preserving the original data and avoiding accidental deletion): `ALTER TABLE [table_name] RENAME COLUMN [field_name] TO [field_name]_deleted`.

[0056] More specifically, the quantification criteria for medium-risk fields can be as follows: Fields meeting the following conditions are marked as medium-risk: 1. No foreign key constraints but with weak associations (e.g., referenced by views or stored procedures, but not subject to mandatory foreign key constraints). 2. Belong to ordinary business tables: meaning daily average data increment < 1000, directly referenced by non-core processes, but with historical data (≥ 100 non-null records). The specific processing flow (soft deletion + quick recovery) can be: 1. Generate an enhanced soft deletion script: The script contains two core operations to avoid loss of original data. One operation is renaming the field (preserving the original value): ALTER TABLE [table name] RENAME COLUMN [field name] TO [field name]_deleted. Another method is to create a field-level backup table (named as table name + field name + batch number, supporting index queries): `CREATE TABLE [table name]_[field name]_backup_20240601_001 AS SELECT id, [field name]_deleted, create_time FROM [table name];` This preserves the primary key and time for easy association: `CREATE INDEX idx_backup_id ON [table name]_[field name]_backup_20240601_001(id);` -- This speeds up recovery queries. 2. One-click recovery mechanism (reducing manual operation costs): The system automatically generates a "Recovery Script Template". After the user selects "Recover", the system automatically fills in the parameters and executes the script: First, restore the original values ​​from the backup table (only restore non-null records): "UPDATE [table name] t JOIN [table name]_[field name]_backup_20240601_001 bON t.id = b.id SET t.[field name]_deleted = b.[field name]_deleted"; Then, restore the field names: "ALTER TABLE [table name] RENAME COLUMN [field name]_deleted TO [field name]"; Finally, mark the status of the backup table (to avoid duplicate recovery): "ALTER TABLE [table name]_[field name]_backup_20240601_001 ADDCOLUMN is_restored TINYINT DEFAULT 1".

[0057] In this way, by retaining data through soft deletion and using a one-click recovery mechanism, the safe and efficient cleanup of ordinary business fields can be achieved while avoiding the risk of accidental deletion.

[0058] In one optional implementation, a deletion script corresponding to at least one invalid field is generated according to the risk level of at least one invalid field to perform a deletion operation corresponding to the risk level of at least one invalid field. This includes: if the database table where the invalid field is located is a temporary table or a log table, the invalid field has no non-null records in a preset first time period and no read / write operations in a preset second time period, and the invalid field has no references, then the invalid field is determined to be a low-risk field. After confirming that the low-risk field has no non-null records in both the database table and the historical table, the invalid field is not referenced, and / or the database table is a temporary table, a hard deletion script that can be directly executed corresponding to the low-risk field is generated. The hard deletion script is used to delete the invalid field and generates an operation log to record the deletion operation information.

[0059] Specifically, for low-risk fields (such as temporary table fields, fields with no historical data and no references): A "hard delete script" (e.g., ALTER TABLE [table name] DROP COLUMN [field name]) is automatically generated, supporting one-click execution. The quantification criteria for low-risk fields can be as follows: fields meeting the following conditions are marked as low-risk: 1. Belongs to a temporary table / log table: the table name contains the prefix or suffix "temp_" or "log_"; 2. No historical data: the number of non-null records in the last 30 days = 0, and there have been no read / write operations in the last 90 days (confirmed through database audit logs); 3. No references: not referenced by code, views, or stored procedures. The specific processing flow (automatic verification + secure deletion) can be as follows: 1. Automatic verification before deletion (double protection to avoid accidental deletion): Verification 1: Confirm no data (including historical versions): "SELECT COUNT(*) FROM [table name] WHERE [field name] IS NOTNULL; -- the result must be 0; SELECT COUNT(*) FROM [table name]_history WHERE [field name] IS NOTNULL; if there is a historical table, the result must be 0.". Verification 2: Confirm no references (through database dependency views): "SELECT *FROM sys.dm_sql_referencing_entities('[table name].[field name]', 'COLUMN'); the result must be empty.". Verification 3: Confirm the table type is a temporary table (for temporary table fields): "SELECT is_tempdb_table FROM sys.tables WHERE name = '[table name]'; temporary tables return 1." 2. Generate a hard delete script (with operation logs). The script contains deletion operations and log records to ensure traceability. Perform a hard delete: "ALTER TABLE [table_name] DROPCOLUMN [field_name]; Write an immutable operation log (stored in the system audit table). INSERT INTO sys_field_delete_log (table_name, column_name, delete_time, operator, reason, checksum) VALUES ('[table_name]', '[field_name]', CURRENT_TIMESTAMP, 'sys_auto', 'low-risk invalid field cleanup', CHECKSUM(NEWID()))."

[0060] In this way, for invalid fields that are determined to be low-risk, after triple verification confirms that there is no data, no references, and that they are temporary tables, a hard deletion script is automatically generated and executed, realizing one-click safe cleanup without manual intervention. At the same time, the operation log is used to store evidence to meet audit traceability requirements, which significantly improves cleanup efficiency and reduces labor costs.

[0061] It is worth mentioning that this application adopts invalid field quantitative classification technology, which constructs a quantitative evaluation standard based on data activity threshold, business process correlation and constraint or reference relationship, automatically classifies high-risk, medium-risk and low-risk fields, replaces manual subjective judgment, and can avoid the risk of accidental deletion of core fields.

[0062] In one optional implementation, before parsing the target code resources of the application to be parsed, the method further includes: filtering out valid metadata in the code resources of the application to be parsed, and removing metadata whose names contain obsolete identifiers, to obtain the target code resources of the application to be parsed. Furthermore, parsing the target code resources of the application to be parsed includes: during the parsing process, if the field type of the currently parsed field does not match correctly, skipping the current field, recording an error log containing the error location and error type of the current field, and continuing to parse other fields. Furthermore, after parsing the target code resources of the application to be parsed, the method further includes: calculating the field extraction completeness; if the field extraction completeness is lower than a first preset threshold, initiating a second parsing to extract the unextracted fields; if the field extraction completeness after the second parsing is lower than a second preset threshold, generating and outputting a parsing exception report.

[0063] Specifically, the code parsing exception handling mechanism in this implementation can be as follows: 1. Pre-parsing verification: Filter metadata containing entity table configurations, and remove metadata whose names contain words such as "obsolete," "deprecated," or "invalid." 2. Real-time fault tolerance during parsing: If a field type mismatch occurs during parsing, the computer automatically skips the erroneous logic, records the error log (including the error line number and error type), and continues to parse other valid fields to avoid terminating the entire process. 3. Post-parsing exception fallback: After parsing, the computer calculates the field extraction completeness (number of extracted fields / expected number of fields). If the completeness is less than 90%, a second parsing is automatically initiated (only parsing files that were not successfully extracted). If the completeness is still less than 80% after the second parsing, a "Parsing Exception Report" (including an error list, estimated missing fields, and suggestions for manual intervention) is generated and synchronized to the user and system maintenance module.

[0064] Thus, the code parsing layered fault tolerance technology of this application achieves automated extraction of fields from dynamic domain models through a three-layer fault tolerance mechanism: pre-parsing verification, real-time fault tolerance during parsing, and post-parsing exception fallback. This avoids single-point errors that could cause the entire process to terminate, improves parsing efficiency, and ensures that the completeness of field extraction is above 90%.

[0065] In one optional implementation, generating a deletion script corresponding to at least one invalid field includes: determining the database type of the target database; and, based on the invalid field and the database type, calling the syntax rule corresponding to the database type from the database syntax rule base to generate a deletion script corresponding to the invalid field that is adapted to the database type.

[0066] Specifically, addressing the issue that existing technologies require manual adjustment of script syntax and are prone to errors, this implementation method can construct a "database syntax rule base" that covers the differences in ALTER TABLE syntax among mainstream databases such as MySQL, Oracle, and SQL Server, and automatically generate scripts for the compared database syntax without manual intervention, achieving full-process automation.

[0067] In this way, this cross-database syntax adaptive technology can automatically generate adaptive deletion scripts by building a mainstream database syntax rule base, without the need for manual adjustment, and can solve the problem of cumbersome script adaptation in multi-database environments.

[0068] To facilitate understanding of the embodiments of this application, a specific example is given below:

[0069] Please see Figure 4 , Figure 4 This is a flowchart illustrating a risk-level-based method for differentiating and cleaning invalid fields, as disclosed in an embodiment of this application. Figure 4 As can be seen, after identifying invalid fields, different processing strategies are adopted according to the risk level (high risk / medium risk / low risk). High-risk fields (core business fields / foreign keys) are marked for manual confirmation, and a list containing dependencies is generated. After user confirmation, a deletion script is generated. Medium-risk fields (non-core fields in ordinary tables / existing historical data) automatically generate soft deletion scripts (renaming fields while retaining data). Low-risk fields (temporary tables / no data, no references) automatically generate hard deletion scripts (direct deletion) and support one-click execution. All three strategies ultimately terminate the process, achieving safe, hierarchical, and automated cleanup of invalid fields.

[0070] It is worth mentioning that this application achieves the following technical effects: First, this differentiated intelligent cleanup method adopts differentiated cleanup strategies for invalid fields with different risk levels. High-risk fields use manual approval and pre-verification, medium-risk fields use soft deletion and backup recovery, and low-risk fields use triple verification and log evidence storage, thus balancing cleanup efficiency and data security. Second, by parsing the code to establish the binding relationship between entities and database tables, it accurately identifies the field ownership and business references in multi-entity shared table scenarios, solving the problem of misjudgment in existing technologies where manual judgment of whether shared table fields can be deleted is not effective, thus enabling accurate identification of shared table fields of multiple entities. Next, by replacing manual extraction with automated parsing, the field extraction time is reduced from 3 hours to 5 minutes; through a three-layer fault tolerance mechanism of pre-verification before parsing, real-time fault tolerance during parsing, and post-parsing exception fallback, the parsing exception termination rate is reduced from 30% to below 1%, improving parsing efficiency and stability. Furthermore, through risk classification and differentiated cleanup processes, the false deletion rate of core fields is close to zero, and the backup mechanism for soft deletion and log evidence storage for hard deletion meet data traceability and compliance requirements. Furthermore, risk grading and differentiated cleanup processes bring the accidental deletion rate of core fields close to zero, and the backup mechanism meets data traceability and compliance requirements, ensuring the security and compliance of the cleanup process. Finally, after invalid field cleanup, single-table storage is reduced by 15%-30%, query I / O counts are reduced by 20%-25%, and single-table query response time is shortened from 500ms to less than 300ms, resulting in significant system performance optimization.

[0071] For further details, please refer to Figure 5 One embodiment of the field deletion device for the target database in this application includes:

[0072] The retrieval unit is used to retrieve entity table fields from the target database.

[0073] The determining unit is used to determine and parse the target code resources of the application to be parsed based on the identifier of the application to be parsed, so as to extract the dynamic domain model field of the application to be parsed.

[0074] The determining unit is further configured to compare the differences between the entity table fields of the target database and the fields of the dynamic domain model, and determine at least one invalid field that exists in the target database but does not exist in the dynamic domain model, wherein the invalid field is a field in the target database that has no business reference;

[0075] The generation unit is used to generate the deletion script corresponding to the at least one invalid field.

[0076] In one alternative implementation, the generating unit may be used for:

[0077] Determine the risk level of the at least one invalid field;

[0078] Based on the risk level of the at least one invalid field, generate a deletion script corresponding to the at least one invalid field to perform the deletion operation corresponding to the risk level of the at least one invalid field.

[0079] In one alternative implementation, the generating unit may be used for:

[0080] If the database table containing the invalid field has a foreign key constraint and the table associated with the foreign key constraint is a core business table, or if the data activity of the database table containing the invalid field reaches a preset activity threshold, then the invalid field is determined to be a high-risk field. The core business table is a table whose daily average new data volume reaches a preset data volume threshold, or a core business table specified by the user.

[0081] For the high-risk fields, generate a list of high-risk fields that include the dependencies of the high-risk fields and the reference records;

[0082] After the list of high-risk fields is manually reviewed and confirmed, the foreign key status of the high-risk fields is verified. Once it is confirmed that the foreign key association has been removed, a deletion script corresponding to the high-risk field is generated.

[0083] In one alternative implementation, the generating unit may be used for:

[0084] If the database table containing the invalid field has no foreign key constraints but has a weak association, the database table containing the invalid field is a regular business table, and the invalid field has historical data, then the invalid field is determined to be a medium-risk field; wherein, the weak association indicates that it is referenced by a view or stored procedure, the regular business table is a non-core process table whose daily average new data volume is lower than a preset data volume threshold, and the historical data is data whose number of non-empty records reaches a preset record number threshold;

[0085] For the intermediate-risk fields, generate soft-deletion scripts and recovery scripts;

[0086] The soft deletion script is used to rename the intermediate risk field to a field name with a deletion mark, so as to retain the original field name of the invalid field, create a field-level backup table, and create an index for the field-level backup table. The field-level backup table contains the original field name of the intermediate risk field, the primary key of the database table where the intermediate risk field is located, and time information.

[0087] The recovery script is used to restore the original field name in the field-level backup table to the renamed field when it is confirmed that the intermediate-risk field has been mistakenly deleted, and to restore the renamed field to the original field name.

[0088] In one alternative implementation, the generating unit may be used for:

[0089] If the database table containing the invalid field is a temporary table or a log table, and the invalid field has no non-empty records within a preset first time period and no read / write operations within a preset second time period, and the invalid field has no references, then the invalid field is determined to be a low-risk field.

[0090] After confirming that the low-risk field has no non-empty records in the database table and the historical table, that the invalid field is not referenced, and / or that the database table is a temporary table, a hard delete script corresponding to the low-risk field is generated. The hard delete script is used to delete the invalid field and generate an operation log to record the deletion operation information.

[0091] In one alternative implementation, the generating unit may be used for:

[0092] The acquisition unit is also used to filter out valid metadata in the code resources of the application to be parsed, and remove metadata whose names contain obsolete identifiers, so as to obtain the target code resources of the application to be parsed.

[0093] The determining unit is specifically used to, during the process of parsing the target code resources of the application to be parsed, skip the current field if the field type of the current field being parsed is incorrect, record an error log containing the error location and error type of the current field, and continue to parse other fields;

[0094] The generation unit is also used to calculate the field extraction completeness. If the field extraction completeness is lower than a first preset threshold, a second parsing is initiated to extract the fields that were not successfully extracted. If the field extraction completeness after the second parsing is lower than a second preset threshold, a parsing error report is generated and output.

[0095] In one alternative implementation, the generating unit may be used for:

[0096] Determine the database type of the target database;

[0097] Based on the invalid field and the database type, the syntax rule corresponding to the database type is called from the database syntax rule library to generate a deletion script that is adapted to the invalid field of the database type.

[0098] For further details, please refer to Figure 6 One embodiment of the field deletion device for the target database in this application includes:

[0099] Central processing unit 601, memory 605, input / output interface 604, wired or wireless network interface 603, and power supply 602;

[0100] Memory 605 is either a short-term storage memory or a persistent storage memory;

[0101] The central processing unit 601 is configured to communicate with the memory 605 and execute instructions stored in the memory 605 to perform the aforementioned operations. Figure 2 The method in the illustrated embodiment.

[0102] Furthermore, embodiments of this application also provide a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the aforementioned... Figure 2 The method in the illustrated embodiment.

[0103] Furthermore, embodiments of this application also provide a computer program product containing instructions, which, when run on a computer, causes the computer to perform the aforementioned... Figure 2 The method in the illustrated embodiment.

[0104] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0107] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for deleting a field in a target database, characterized in that, include: Retrieve the entity table fields from the target database; Based on the identifier of the application to be parsed, the target code resources of the application to be parsed are identified and parsed in order to extract the dynamic domain model fields of the application to be parsed. The entity table fields of the target database are compared with the fields of the dynamic domain model to identify at least one invalid field that exists in the target database but does not exist in the dynamic domain model. The invalid field is a field in the target database that has no business reference. Generate a deletion script corresponding to the at least one invalid field.

2. The method according to claim 1, characterized in that, The step of generating the deletion script corresponding to the at least one invalid field includes: Determine the risk level of the at least one invalid field; Based on the risk level of the at least one invalid field, generate a deletion script corresponding to the at least one invalid field to perform the deletion operation corresponding to the risk level of the at least one invalid field.

3. The method according to claim 2, characterized in that, The step of generating a deletion script corresponding to the at least one invalid field according to its risk level, and performing a deletion operation corresponding to the risk level of the at least one invalid field, includes: If the database table containing the invalid field has a foreign key constraint and the table associated with the foreign key constraint is a core business table, or if the data activity of the database table containing the invalid field reaches a preset activity threshold, then the invalid field is determined to be a high-risk field. For the high-risk fields, generate a list of high-risk fields that include the dependencies of the high-risk fields and the reference records; When the list of high-risk fields meets the preset conditions, the foreign key status of the high-risk fields is verified. After confirming that the foreign key association has been removed, a deletion script corresponding to the high-risk fields is generated.

4. The method according to claim 2, characterized in that, The step of generating a deletion script corresponding to the at least one invalid field according to its risk level, and performing a deletion operation corresponding to the risk level of the at least one invalid field, includes: If the database table containing the invalid field has no foreign key constraints but has a weak association, the database table containing the invalid field is a regular business table, and the invalid field contains historical data, then the invalid field is determined to be a medium-risk field. For the intermediate-risk fields, generate soft-deletion scripts and recovery scripts; The soft deletion script is used to rename the intermediate risk field to a field name with a deletion mark, so as to retain the original field name of the invalid field, create a field-level backup table, and create an index for the field-level backup table. The field-level backup table contains the original field name of the intermediate risk field, the primary key of the database table where the intermediate risk field is located, and time information. The recovery script is used to restore the original field name in the field-level backup table to the renamed field when it is confirmed that the intermediate-risk field has been mistakenly deleted, and to restore the renamed field to the original field name.

5. The method according to claim 2, characterized in that, The step of generating a deletion script corresponding to the at least one invalid field according to its risk level, and performing a deletion operation corresponding to the risk level of the at least one invalid field, includes: If the database table containing the invalid field is a temporary table or a log table, and the invalid field has no non-empty records within a preset first time period and no read / write operations within a preset second time period, and the invalid field has no references, then the invalid field is determined to be a low-risk field. After confirming that the low-risk field has no non-empty records in the database table and the historical table, that the invalid field is not referenced, and / or that the database table is a temporary table, a hard delete script corresponding to the low-risk field is generated. The hard delete script is used to delete the invalid field and generate an operation log to record the deletion operation information.

6. The method according to claim 1, characterized in that, Before parsing the target code resources of the application to be parsed, the method further includes: Valid metadata in the code resources of the application to be parsed is filtered out, and metadata whose names contain obsolete identifiers is removed to obtain the target code resources of the application to be parsed. The process of parsing the target code resources of the application to be parsed includes: During the parsing of the target code resources of the application to be parsed, if the field type of the current field being parsed is incorrect, the current field is skipped, an error log containing the error location and error type of the current field is recorded, and other fields are parsed. After parsing the target code resources of the application to be parsed, the method further includes: The system calculates the completeness of field extraction. If the completeness of field extraction is lower than a first preset threshold, a second parsing is initiated to extract the fields that were not successfully extracted. If the completeness of field extraction after the second parsing is lower than a second preset threshold, a parsing error report is generated and output.

7. The method according to claim 1, characterized in that, The step of generating the deletion script corresponding to the at least one invalid field includes: Determine the database type of the target database; Based on the invalid field and the database type, the syntax rule corresponding to the database type is called from the database syntax rule library to generate a deletion script that is adapted to the invalid field of the database type.

8. A field deletion device for a target database, characterized in that, include: The retrieval unit is used to retrieve entity table fields from the target database. The determining unit is used to determine and parse the target code resources of the application to be parsed based on the identifier of the application to be parsed, so as to extract the dynamic domain model field of the application to be parsed. The determining unit is further configured to compare the differences between the entity table fields of the target database and the fields of the dynamic domain model, and determine at least one invalid field that exists in the target database but does not exist in the dynamic domain model, wherein the invalid field is a field in the target database that has no business reference; The generation unit is used to generate the deletion script corresponding to the at least one invalid field.

9. A field deletion device for a target database, characterized in that, include: Central processing unit and memory; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

11. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 7.

Images