SQL file verification and execution method and device, equipment and storage medium

Abstract

The invention discloses an SQL file verification and execution method and device, equipment and a storage medium, and relates to the technical field of database processing, and the method comprises the following steps: disassembling a to-be-processed SQL file by using a preset grammar parser to obtain a plurality of to-be-verified objects; verifying each to-be-verified object by using a preset normative verifier, verifying each to-be-verified object by using a preset object existence verifier if an obtained first verification result represents that verification is passed, and verifying each to-be-verified object by using a preset risk verifier to obtain a third verification result if an obtained second verification result represents that verification is passed; if the third verification result represents that the verification is passed, executing the to-be-processed SQL file in a plurality of execution environments in sequence according to a preset execution sequence by utilizing a preset executor; the execution environment comprises a test environment, a pre-expansion environment and a user actual use environment. In this way, the security of SQL file execution can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of database processing, and in particular to a method, device, equipment and storage medium for checking and executing an SQL file. Background Art

[0002] In today's Internet industry, up to 90% of data is stored in the database, and the underlying layer of each page function corresponds to one or more tables and corresponding data. With the continuous iteration of functions, the table structure and configuration data are also constantly updated.

[0003] At present, the traditional processing method is that the developers of each function write the corresponding SQL (Structured Query Language) statements for database object changes or data changes, and then deploy and verify them in various environments, and the corresponding SQL statements will also be executed in various environments. However, in this process, SQL statements are written by different developers, and each person's writing habits vary greatly, making it extremely difficult to guarantee the quality of SQL statements. In addition, the time from development to release of a function is quite long, and the SQL statements may undergo repeated modifications and adjustments. At the same time, the SQL statements are saved locally by the developers. When the function is released, it is very likely that the file will be missed. In addition, the previous SQL statements were all executed in an environment that is not actually used by the user, and no pre-check operation was performed in the actual user environment. Therefore, when the SQL statements are executed in the actual user environment, errors and data update errors may occur, which will not only hinder the release of the function and fail the function verification, but also prolong the release time, and even cause a series of problems such as invisible online failures. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a method, device, equipment and storage medium for checking and executing SQL files, which can use a preset normativeness checker, a preset object existence checker and a preset risk checker to check each object to be checked respectively, and use a preset executor to execute the SQL file to be processed after all the checks pass. The specific scheme is as follows:

[0005] In a first aspect, the present application provides a method for verifying and executing an SQL file, comprising:

[0006] Determine the SQL file to be processed based on the developer's needs, and use a preset syntax parser to disassemble the SQL file to be processed to obtain several objects to be verified;

[0007] Using a preset normativeness checker to check each of the objects to be checked, if the first check result obtained indicates that the check is passed, then using a preset object existence checker to check each of the objects to be checked, if the second check result obtained indicates that the check is passed, then using a preset risk checker to check each of the objects to be checked, to obtain a third check result;

[0008] If the third verification result indicates that the verification is passed, the SQL file to be processed is executed in several execution environments in sequence using a preset executor according to a preset execution order; the execution environments include a test environment, a pre-release environment, and an actual user use environment.

[0009] Optionally, the SQL file to be processed is disassembled by using a preset syntax parser to obtain a number of objects to be verified, including:

[0010] Using a preset reader in the preset syntax parser to read each character in the SQL file to be processed in order from left to right, and recording the reading start position and the reading end position until the preset reader finishes reading the SQL file to be processed; wherein the condition for triggering the preset reader to finish reading is that the read content is a line break character;

[0011] The characters between each of the reading start positions and the corresponding reading end positions are combined according to a preset combination rule to obtain a plurality of word combinations, and the word combinations are set as objects to be verified.

[0012] Optionally, after the SQL file to be processed is disassembled by a preset syntax parser to obtain a number of objects to be verified, the method further includes:

[0013] Using a preset grammar checker in the preset grammar parser and based on preset grammar rules, each of the objects to be checked is checked respectively to obtain a corresponding fourth check result;

[0014] Determine whether each of the fourth verification results satisfies the first preset verification pass condition, and if the fourth verification results satisfy the first preset verification pass condition, send the SQL file to be processed and each of the objects to be verified to the preset normative verifier;

[0015] If the fourth verification result does not meet the first preset verification pass condition, abnormal information and prompt information are generated and returned based on the fourth verification result.

[0016] Optionally, the verifying each of the objects to be verified by using a preset normative verifier includes:

[0017] Acquire the object to be standardized and verified from each of the objects to be verified based on user needs;

[0018] A preset standardization checker is used and a corresponding verification method is determined based on corresponding verification rules and verification logic, so as to use the corresponding verification method to verify the object name, name length, comment information and field length corresponding to each object to be standardized and verified, and obtain a first verification result, and send the SQL file to be processed and each object to be verified to the preset object existence checker.

[0019] Optionally, before verifying each of the objects to be verified by using a preset object existence verifier, the method further includes:

[0020] The preset data dictionary synchronization component in the preset data support component is used to store the data dictionary information corresponding to the changed business database in the local memory in a preset structure, and the information in the local memory is scanned. Then, several threads in the preset thread pool are used to update the scanned data dictionary information to the preset data dictionary library; the data dictionary information includes a data table and the table name, field name and index name corresponding to the data table.

[0021] Optionally, the verifying each of the objects to be verified by using a preset object existence verifier includes:

[0022] Using the corresponding verification rules in the preset object existence verifier, the SQL file to be processed is verified with the data dictionary information corresponding to the SQL file to be processed in the preset data dictionary library to obtain a fifth verification result;

[0023] Determine whether the preset business database has a unique index. If the preset business database has the unique index, use the preset business data synchronization component in the preset data support component to store the business data corresponding to the changed business database into the preset business database based on the unique index;

[0024] Utilizing the preset object existence verifier to query the data corresponding to each of the objects to be verified from the preset business database to obtain a query result;

[0025] A second verification result is determined based on the fifth verification result and the query result.

[0026] Optionally, the step of executing the SQL file to be processed in a plurality of execution environments in sequence using a preset executor and in accordance with a preset execution order includes:

[0027] Execute the SQL file to be processed in the test environment, the pre-release environment and the user's actual use environment in sequence by using a preset executor and in a preset execution order; several core attributes corresponding to the SQL file to be processed during the execution process include the current execution environment, the next execution environment and the execution result;

[0028] It is determined whether the obtained execution result meets the preset archiving condition. If the execution result meets the preset archiving condition, the SQL file to be processed is archived to the preset archiving pool.

[0029] In a second aspect, the present application provides a SQL file verification and execution device, including:

[0030] A file disassembly module is used to determine the SQL file to be processed based on the developer's needs, and disassemble the SQL file to be processed using a preset syntax parser to obtain a number of objects to be verified;

[0031] An object verification module is used to verify each of the objects to be verified using a preset normative verifier. If the first verification result obtained indicates that the verification is passed, the preset object existence verifier is used to verify each of the objects to be verified. If the second verification result obtained indicates that the verification is passed, the preset risk verifier is used to verify each of the objects to be verified to obtain a third verification result;

[0032] The file execution module is used to execute the SQL file to be processed in several execution environments in sequence using a preset executor and in accordance with a preset execution order if the third verification result indicates that the verification has passed; the execution environment includes a test environment, a pre-release environment, and an actual user use environment.

[0033] In a third aspect, the present application provides an electronic device, including:

[0034] Memory, used to store computer programs;

[0035] The processor is used to execute the computer program to implement the aforementioned SQL file verification and execution method.

[0036] In a fourth aspect, the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned SQL file verification and execution method when executed by a processor.

[0037] As can be seen from the above, before verifying and executing SQL files, the present application needs to determine the SQL files to be processed based on the developer's needs, and use a preset syntax parser to disassemble the SQL files to be processed to obtain several objects to be verified; use a preset normative verifier to verify each of the objects to be verified, and if the first verification result obtained indicates that the verification is passed, then use a preset object existence verifier to verify each of the objects to be verified, and if the second verification result obtained indicates that the verification is passed, then use a preset risk verifier to verify each of the objects to be verified to obtain a third verification result; if the third verification result indicates that the verification is passed, use a preset executor and execute the SQL files to be processed in several execution environments in sequence according to a preset execution order; the execution environment includes a test environment, a pre-release environment, and an actual user use environment.

[0038] It can be seen that the present application first determines the SQL file to be processed based on the developer's needs, and uses the preset syntax parser to disassemble the SQL file to be processed to obtain several objects to be verified, and then uses the preset normative verifier to verify each object to be verified. If the first verification result obtained indicates that the verification is passed, the preset object existence verifier is used to verify each object to be verified. If the second verification result obtained indicates that the verification is passed, the preset risk verifier is used to verify each object to be verified to obtain a third verification result. Finally, if the third verification result indicates that the verification is passed, the preset executor is used to execute the SQL file to be processed in several execution environments in accordance with the preset execution order; the execution environment includes a test environment, a pre-release environment, and an actual user use environment. In this way, the security and speed of SQL file execution are improved, thereby improving the efficiency of the actual application process and enhancing the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0040] Figure 1 A flow chart of a method for verifying and executing an SQL file disclosed in this application;

[0041] Figure 2 It is a flow chart for writing and applying SQL files;

[0042] Figure 3 A schematic diagram of a component for verifying and executing an SQL file disclosed in the present application;

[0043] Figure 4 This is a specific schematic diagram of putting a verified SQL file into an executable SQL pool disclosed in this application;

[0044] Figure 5 A specific SQL statement splitting diagram disclosed in this application;

[0045] Figure 6 Another specific SQL statement splitting schematic diagram disclosed in this application;

[0046] Figure 7 A schematic diagram of a specific process of verifying an object to be verified disclosed in this application;

[0047] Figure 8 A schematic diagram of the execution flow of a specific SQL file to be processed disclosed in this application;

[0048] Fig. 9 This is a schematic diagram of initial attribute information of a SQL file to be processed disclosed in this application;

[0049] Fig.10 A schematic diagram of attribute information corresponding to a SQL file to be processed disclosed in the present application when it is executed in a test environment;

[0050] Fig.11 A schematic diagram of attribute information corresponding to a SQL file to be processed disclosed in the present application when it is executed in a pre-release environment;

[0051] Fig.12 A schematic diagram of attribute information corresponding to a SQL file to be processed disclosed in the present application when it is executed in a real-line environment;

[0052] Fig.13 A schematic diagram of archiving SQL files using a SQL archiver disclosed in this application;

[0053] Fig.14 A schematic diagram of a specific process of writing and archiving SQL files disclosed in this application;

[0054] Fig.15 A schematic diagram of the structure of a SQL file verification and execution device disclosed in this application;

[0055] Fig.16 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0057] At present, the traditional processing method is that the R&D personnel of each function write the corresponding SQL statements for database object changes or data changes, which are then deployed and verified in various environments, and the corresponding SQL statements are also executed in various environments. However, in this process, SQL statements are written by different R&D personnel, and each person's writing habits vary greatly, making it extremely difficult to ensure the quality of SQL statements. To this end, the present application provides a method for verifying and executing SQL files, which can use a preset normative verifier, a preset object existence verifier, and a preset risk verifier to verify each object to be verified, and use a preset executor to execute the SQL file to be processed after all verifications are passed.

[0058] See also Figure 1 As shown, an embodiment of the present invention discloses a method for checking and executing an SQL file, including:

[0059] Step S11: determine the SQL file to be processed based on the developer's needs, and use a preset syntax parser to disassemble the SQL file to be processed to obtain a number of objects to be verified.

[0060] At present, the flowchart for writing and applying SQL files is as follows Figure 2 As shown: First, write codes and files based on the requirements, and deploy the written codes and files to the test environment so as to perform functional verification on the written codes and files in the test environment. Secondly, after the written codes and files are functionally verified in the test environment, the embodiment of the present application needs to deploy the written codes and files to the pre-release environment so as to perform functional verification on the written codes and files in the pre-release environment. Subsequently, after the written codes and files are functionally verified in the pre-release environment, the embodiment of the present application needs to deploy the written codes and files to the real-line environment so as to perform functional verification on the written codes and files in the real-line environment. Among them, the real-line environment is the environment actually used by users. It is worth mentioning that only when all functional environments have passed the verification of the SQL file can the SQL file be put into use.

[0061] However, different developers will encounter many problems when writing various objects in SQL files. First, due to the different writing habits of each developer, the names of the same object are presented in various forms, including but not limited to table names, index names, regular field names, and regular field lengths. Second, in the actual development process, developers and testers usually do not conduct detailed reviews of the corresponding SQL files, and the SQL files are saved locally by the developers, so other developers and testers are not aware of the specific changes in the SQL files. Once the writing is not standardized or the data is wrong, problems will arise. For example, when adding an index to a large table, the business table may be locked, making it impossible to process the business normally. Third, during the development and testing process, the file may be modified many times. If the developer submits the in-process but not the final file to the real-line environment, it will increase the meaningless testing work when releasing. Fourth, since the verification work of the test can only start after the corresponding SQL files are executed, and since the files are saved locally by the developers who wrote them, the testers need to ask the developers one by one whether the execution is completed. Once the file needs to be modified or switched to another environment for testing, this process needs to be repeated many times. Fifth, since SQL files are all stored locally by R&D personnel, it is impossible to audit the release file status of each business line within a release cycle. In addition, since the files are all stored internally by R&D personnel, this part of the content will be missing when the project resources are finally delivered.

[0062] In this embodiment, the schematic diagram of the components for verifying and executing the SQL file is as follows: Figure 3 As shown: SQL syntax parser, data support component, SQL validator, SQL executor and SQL archiver,

[0063] Among them, the SQL syntax parser has the ability to disassemble SQL files. It can disassemble SQL files into independent SQLs, and further disassemble each SQL file. In a specific implementation, the SQL file can be split into SELECT, *, and FROM objects. The data support component is responsible for synchronizing some data dictionaries and configuration data required for subsequent verification according to the preset time, and providing necessary data support for the verification work. The SQL verifier is used to provide SQL verification capabilities. That is, to ensure that the SQL written by the R&D personnel is both in compliance with the specifications and free of errors, including syntax errors or data errors, it is necessary to verify before each SQL file is executed. Only when the verification passes can the SQL file continue to execute the operation. The SQL executor is used to provide SQL file execution capabilities, that is, to control whether the file meets the executable conditions, and after the file meets the executable conditions, determine the file execution strategy, and then record the file execution results and notify. The SQL archiver is used to archive and organize the files released each time for each business according to the preset archiving rules to facilitate the development of audit work and the delivery of the project.

[0064] In this embodiment, the written SQL file needs to be placed in the original SQL pool, and the SQL file placed in the original SQL pool is verified. Only those SQLs that pass the verification can be placed in the executable SQL pool. The specific process is as follows: Figure 4 As shown in the figure, when all SQL files corresponding to a requirement are successfully executed in all environments, these SQL files can be put into the SQL pool to be archived.

[0065] It is worth mentioning that although the SQL file written by the R&D personnel is usually a whole, it is often necessary to verify some objects in this SQL file, such as the table name, field name, and field value corresponding to the SQL file. To this end, the embodiment of the present application provides a SQL syntax parser, wherein the syntax parser relies on antlr4 (ANother Tool for Language Recognition, i.e., a language recognition tool) technology to disassemble an SQL file into corresponding objects. Specifically, using a preset syntax parser to disassemble the SQL file to be processed to obtain a number of objects to be verified can include: using a preset reader in a preset syntax parser to read each character in the SQL file to be processed in order from left to right, and recording the reading start position and the reading end position until the preset reader finishes reading the SQL file to be processed; wherein, the condition for triggering the end of the preset reader reading is that the content read is a line break; according to the preset combination rule, the characters between each reading start position and the corresponding reading end position are combined to obtain a number of word combinations, and the word combinations are set as objects to be verified.

[0066] In a specific implementation, the embodiment of the present application first needs to analyze each element in the SQL file and define it as a token (i.e., an identifier). In this way, the embodiment of the present application can distinguish which elements are SQL keywords and which are not SQL keywords. For example, in the SQL statement "select id from A", "select" and "from" are keywords, while "id" and "A" are non-keywords. Among them, the process of analyzing each element in the SQL file is as follows: First, define a parser to use the parser to read each character in the SQL file from left to right in sequence, and record the starting position of this reading as start. Stop when a space or line break is read, record end as the stop position, and record end - 1 as the end position. Subsequently, determine whether the word composed of the characters from start to end - 1 is in the SQL keyword thesaurus. If so, then this word is an SQL keyword; if not, it means it is a non-keyword. Finally, continue to loop and read characters from the SQL file corresponding to the end + 1 position until the last character is read. When the SQL file is scanned, a bunch of token sets will be obtained. It is worth mentioning that after obtaining the token set, the embodiment of the present application needs to use a preset syntax parser to determine whether there are syntax errors in the token set. Among them, a token set without syntax errors will generate an abstract syntax tree, so that the embodiment of the present application uses the visitor pattern to encapsulate the token set into an SQL Statement. Specifically, after disassembling the SQL file to be processed using the preset syntax parser and obtaining a number of objects to be verified, it can also include: using the preset syntax verifier in the preset syntax parser and verifying each object to be verified based on the preset syntax rules to obtain the corresponding fourth verification result; judging whether each fourth verification result meets the first preset verification pass condition, if the fourth verification result meets the first preset verification pass condition, the SQL file to be processed and each object to be verified will be sent to the preset normative verifier; if the fourth verification result does not meet the first preset verification pass condition, then based on the fourth verification result, generate and return exception information and prompt information.

[0067] In a specific implementation, according to different SQL types, the specific implementations are respectively in SelectStatement, Create Table Statement, Alter Table Add Column Statement, Alter TableRename Column Statement, and Rename Table Statement. That is, each type of SQL will have its own SQL Statement class.

[0068] like Figure 5 As shown in the figure, taking a SQL statement without syntax errors as an example, such as the SQL statement "select * from A whereid=1", after parsing, it will be divided into "select", "*", "from", "A", "where", and "id=1".

[0069] Further, such as Figure 6 As shown in the figure, if the SQL written by the developer has a syntax error, such as the SQL statement "select *Awhere id=1". In this case, the SQL syntax parser cannot successfully parse the SQL statement. According to the syntax rule of "select *", the keyword after it should be "from", but the keyword "from" cannot be found in the entire SQL statement. Therefore, the parser will have a parsing exception and give a clear prompt: Missing keyword: from.

[0070] Step S12: Use a preset normativeness checker to check each of the objects to be checked. If the first check result obtained indicates that the check is passed, use a preset object existence checker to check each of the objects to be checked. If the second check result obtained indicates that the check is passed, use a preset risk checker to check each of the objects to be checked to obtain a third check result.

[0071] In this embodiment, after obtaining the object to be verified that has passed the syntax check, the embodiment of the present application needs to further verify the object to be verified, that is, to verify whether the SQL file written by the R&D personnel complies with the specifications and whether there are any errors. Among them, according to the different responsibilities of each component, it can be subdivided into a normative verifier, an object existence verifier, and a risk verifier. After the entire SQL file has been verified by all verifiers, all abnormal situations in the SQL file will be prompted, and the R&D personnel will be notified to make modifications. If an SQL file can pass the verification of all verifiers, then this SQL file meets the conditions for execution.

[0072] In a specific implementation, the embodiment of the present application defines an interface named SQL Rules, which is used to store the validation rule attributes and provide validation behavior. In a specific implementation, the above interface has different implementations of SQL Grammar Rules, SQL Standard Rules, SQL Exesits Rules, and SQL Risk Rules, each of which corresponds to a specific responsibility verifier. In addition, depending on the SQL type, it can be further subdivided into Create Table Rules, Alter Table Add Column Rules, Alter Table Rename Column Rules, Insert Rules, Update Rules and other different implementations. These implementations cooperate with each other to provide comprehensive and detailed protection for the validation of SQL statements.

[0073] In this embodiment, after the normative checker receives the SQL checked by the SQL syntax checker and the object disassembled by the SQL syntax parser, the embodiment of the present application needs to use the normative checker to check the object to be checked. Among them, the normative checker is used to check the naming of the object, the length of the object name, whether the annotation of the object exists, and whether the length definition of common fields remains consistent. Specifically, using a preset normative checker to check each object to be checked can include: obtaining an object to be standardized from each object to be checked based on user needs; using a preset normative checker and determining a corresponding verification method based on corresponding verification rules and verification logic, so as to use the corresponding verification method to verify the object name, name length, comment information and field length corresponding to each object to be standardized, respectively, to obtain a first verification result, and send the SQL file to be processed and each object to be checked to the preset object existence checker.

[0074] Furthermore, the standardization checker is in the parent class SQL Standard Rules, where all the rules related to standardization are stored. Its subclasses are further subdivided into Create Table SQL Standard Rules, Alter Table Add Column SQL Standard Rules, Alter Table Rename Column SQLStandard Rules, Insert SQL Standard Rules, and Update SQL Standard Rules. These specific implementations are responsible for storing rules of their respective types and verification logic.

[0075] In a specific implementation, for the SQL statement "create table A...", the embodiment of the present application only needs to extract the table name A from Create Table Statement, then take out the rule set object Create Table Rules.Table Name Rules for verifying the creation of the table from Create Table Rules, and then verify the extracted objects in turn. Among them, the verification methods for object verification are rich and varied, including but not limited to contains / notcontains, start With / end With, object.length>=, object.length<=, and regular matching. That is, the specification verifier will perform accurate verification according to the verification methods corresponding to different rule configurations. For example, for a rule such as "the table name does not exceed 30 characters", the judgment method adopted is A.length<=30. Similarly, other types of SQL can also be entered into the corresponding Rules implementation class for verification in turn to ensure that all types of SQL statements can be accurately and strictly checked for normativeness. In addition, after all rule verifications are completed, the embodiment of the present application will record the verification results, and at the same time pass the original SQL file and the disassembled objects to the object existence verifier for the next step of verification operation.

[0076] It is worth mentioning that after the object existence verifier receives the SQL file verified by the specification verifier and the object disassembled by the syntax parser, it needs to perform existence verification on the object disassembled by the syntax parser. Among them, the existence verification is further divided into two parts: database object existence and data existence. The data sources relied on by these two parts are different. Database object existence verification relies on the data dictionary, while data existence verification relies on business configuration data.

[0077] Furthermore, the data information that the object existence verification part relies on is the data dictionary information corresponding to each business database. In this process, the two parties to be compared are the file written by the R&D personnel and the table and object operated by this file. Common objects here include table names, field names, index names, etc. Specifically, before using the preset object existence verifier to verify each object to be verified, it can also include: using the preset data dictionary synchronization component in the preset data support component to store the data dictionary information corresponding to the changed business database in the local memory in a preset structure, and scan the information in the local memory, and then use several threads in the preset thread pool to update the scanned data dictionary information to the preset data dictionary library; the data dictionary information includes a data table and the table name, field name and index name corresponding to the data table.

[0078] It is worth mentioning that, since the data dictionary information of the table is stored in each business library, the present invention implements a Data Dictionary Scanner. In a specific implementation, the above Scanner will synchronize the data dictionary information of the database whose real-line environment table structure has changed on the previous day at dawn every day. That is, the embodiment of the present application needs to record the changed database information in Redis using a list structure so that the Data Dictionary Scanner can obtain the database information that needs to be synchronized. In addition, if the data corresponding to the real-line table on the previous day has not changed, no synchronization operation is required.

[0079] It is worth mentioning that Data Dictionary Scanner is essentially a thread pool, which is used to start several threads, including but not limited to Table Name Thread, Table Column Thread, Table Index Thread, which are used to synchronize table names, field names, index information, etc., respectively. Subsequently, the embodiment of the present application will store the acquired information in the database. Among them, whenever a database synchronization is completed, the embodiment of the present application needs to delete the corresponding current library content in redis. Specifically, using a preset object existence verifier to verify each object to be verified can include: using the corresponding verification rules in the preset object existence verifier and verifying the SQL file to be processed with the data dictionary information corresponding to the SQL file to be processed in the preset data dictionary library to obtain the fifth verification result.

[0080] In a specific implementation, the parent class of the object existence checker is SQL Object Exesits Rules, where the parent class stores a collection of all object existence related rules. Its subclasses include but are not limited to CreateTable SQL Object Exesits Rules, Alter Table Add Column SQL Object ExesitsRules, Alter Table Rename Column SQL Object Exesits Rules, Insert SQL ObjectExesits Rules, and Update SQL Object Exesits Rules, and these specific implementations are responsible for storing rules of their respective types and verification logic.

[0081] Furthermore, data existence verification is used to verify the data that mainly depends on various business configuration classes. In this process, the two parties to be compared are the file written by the R&D personnel and the table and data operated by this file. It is worth mentioning that the embodiment of the present application implements a tool called Data Scanner. Its principle is similar to that of data dictionary synchronization, and it also extracts data from the business library and stores it in the database corresponding to the present invention. Among them, Data Scanner is also a thread pool, and each thread in the thread pool only processes the data synchronization task corresponding to one table at a time. These tables that need to be synchronized are also recorded in Redis. In addition, the value records the library name#table name. After the data recording is completed, the embodiment of the present application will delete the value information corresponding to the current table in Redis.

[0082] It is worth mentioning that the data existence check is different from the object existence check. The process of data existence check has an additional step to determine whether an existence check is needed. Therefore, in addition to the check behavior, the process of data existence check also has a before Check behavior. Among them, in the before Check, the embodiment of the present application will check whether the current table has a unique index. If there is a unique index, it will enter the check step. If not, it will be skipped. The check itself only needs to obtain the data corresponding to the unique index, and then query the corresponding database based on the above data to see whether the data exists. Specifically, determine whether the preset business database has a unique index. If the preset business database has a unique index, the preset business data synchronization component in the preset data support component is used to store the business data corresponding to the changed business database based on the unique index to the preset business database; use the preset object existence verifier to query the data corresponding to each object to be verified from the preset business database to obtain the query result; determine the second verification result based on the fifth verification result and the query result.

[0083] In a specific implementation, the parent class in the data existence check is SQL Data Exesits Rules, which stores all rule sets related to data existence. The subclasses in the parent class include but are not limited to InsertSQL Data Exesits Rules, Update SQL Data Exesits Rules, and Delete SQL Data ExesitsRules. The above specific implementations are responsible for storing rules of their respective types and verification logic.

[0084] Furthermore, after the risk verifier receives the SQL file verified by the object existence verifier and the object parsed by the SQL syntax parser, it is necessary to issue an early warning of the risks that may be brought by the SQL file, such as operations such as updating the entire table, deleting the entire table, deleting the table, and adding indexes to large tables.

[0085] It is worth mentioning that the flowchart for verifying the object to be verified is as follows Figure 7 As shown: First, a syntax check is performed on the object to be checked. If the object to be checked fails the syntax check, the user is notified to modify the SQL file; if the object to be checked passes the syntax check, a further normative check is performed on the object to be checked. If the object to be checked fails the normative check, the reason why the object to be checked fails the normative check is recorded; if the object to be checked passes the normative check, a further existence check is performed on the object to be checked. If the object to be checked fails the existence check, the reason why the object to be checked fails the existence check is further added; if the object to be checked passes the existence check, a further risk check is performed on the object to be checked. If the object to be checked fails the risk check, the reason why the object to be checked fails the risk check is added. If the object to be checked passes the risk check, it is considered that the process of checking the object to be checked is completed.

[0086] Step S13: If the third verification result indicates that the verification is passed, the SQL file to be processed is executed in a plurality of execution environments in sequence using a preset executor and in accordance with a preset execution order; the execution environments include a test environment, a pre-release environment, and an actual user use environment.

[0087] In this embodiment, after all the objects to be verified have passed the verification of the above-mentioned verifier, the embodiment of the present application can send the SQL files to be processed to the executable SQL pool, so as to use the SQL executor to process the SQL files to be processed in the executable SQL pool, that is, the SQL executor is responsible for executing those SQL files that have passed the verification. It is worth mentioning that when using the SQL executor to process the SQL files to be processed in the executable SQL pool, the embodiment of the present application needs to execute in one environment after another until the last environment, that is, the real-line environment, is executed. Specifically, using the preset executor and executing the SQL files to be processed in several execution environments in accordance with the preset execution order, it can include: using the preset executor and executing the SQL files to be processed in the test environment, the pre-release environment and the user's actual use environment in accordance with the preset execution order; the corresponding core attributes of the SQL files to be processed during the execution process include the current execution environment, the next execution environment and the execution result; judging whether the obtained execution result meets the preset archiving condition, if the execution result meets the preset archiving condition, the SQL files to be processed are archived to the preset archiving pool.

[0088] It is worth mentioning that the execution process of the SQL file to be processed is as follows Figure 8 As shown, after the SQL file to be processed passes the verification, it can be executed in the functional environment of the database in sequence. Among them, the functional environment of the database is divided into a test environment, a pre-release environment, and a real-line environment. However, some databases only have a test environment and a real-line environment, or only have a pre-release environment and a real-line environment. Therefore, the specific environment corresponding to the database can be configured based on demand, so that during the execution process, according to the real-line database, and in sequence, the corresponding information of each test environment database is read.

[0089] It is worth mentioning that when the SQL file to be processed is executed, it has three core attributes to indicate its execution status, among which the three core attributes are the current execution environment, the next execution environment and the execution result. The current execution environment is used to indicate in which environment the file needs to be executed the most recently. It clarifies the execution environment of the SQL file at the current stage, and provides an important basis for the monitoring and management of the execution process. The next execution environment is used to indicate in which environment the file will be executed next time. Through this attribute, the embodiment of the present application can plan and prepare in advance the execution arrangements of SQL files in subsequent stages to ensure the orderly execution of the execution process. The execution result is used to indicate the execution result of the SQL file in the current environment. It records the execution status of the SQL file in a specific environment. Whether it is successful or failed, it can provide timely feedback to developers and operation and maintenance personnel so that corresponding measures can be taken to adjust and optimize. In addition, the initial attribute information of the SQL file to be processed is such as Fig. 9 As shown, the corresponding attribute information of the SQL file to be processed when it is executed in the test environment is as follows Fig.10 As shown in the figure, the corresponding attribute information of the SQL file to be processed when it is executed in the pre-release environment is as follows Fig.11 As shown in the figure, the corresponding attribute information of the SQL file to be processed when it is executed in the real-line environment is as follows Fig.12 shown.

[0090] Further, when the file is executed in real time, the SQL status is: to be archived. To this end, the embodiment of the present application uses the SQL archiver to archive the executed SQL file, and the specific flow chart is as follows Fig.13As shown. In a specific implementation, the SQL archiver is a scanner, which aggregates the SQL files in the state of being archived within three days after the end of the life cycle of the requirement, and then packages the SQL files of the same requirement into the same compressed package, and stores the compressed package in the path " / project / SQL / year / requirement / ". In this way, during the delivery of the project, the embodiment of the present application only needs to package and submit the entire "SQL" directory. It is worth mentioning that after the SQL archiving is completed, the status is updated to archived.

[0091] It can be seen that the embodiment of the present application first needs to determine the SQL file to be processed based on the developer's needs, and use the preset syntax parser to disassemble the SQL file to be processed to obtain several objects to be verified, and then use the preset normative verifier to verify each object to be verified. If the first verification result obtained indicates that the verification is passed, then use the preset object existence verifier to verify each object to be verified. If the second verification result obtained indicates that the verification is passed, then use the preset risk verifier to verify each object to be verified to obtain a third verification result. Finally, if the third verification result indicates that the verification is passed, the preset executor is used and the SQL file to be processed is executed in several execution environments in sequence according to the preset execution order; the execution environment includes a test environment, a pre-release environment, and an actual user use environment. In this way, the security and speed of SQL file execution are improved, thereby improving the efficiency of the actual application process and enhancing the user experience.

[0092] For further information, see Fig.14 As shown, an embodiment of the present invention discloses a method for checking and executing an SQL file, including:

[0093] It is worth mentioning that the SQL file should go through four processes from writing to final archiving, and the flow chart is as follows Fig.14 As shown:

[0094] Step 1: Writing, that is, R&D personnel write SQL files according to developer or user needs, or modify SQL files after verification failure or execution failure.

[0095] Step 2: Verification, that is, verifying the object to be verified corresponding to the SQL file according to the rules built into the platform. Each time the object to be verified is verified, the embodiment of the present application will verify all the problems of the SQL file, and then notify the corresponding R&D personnel to make modifications. In addition, only after all the SQL files of a requirement have been verified, can the SQL file be executed by the SQL executor.

[0096] Step 3: Execution, that is, executing SQL files in the order of test environment, staging environment, and real-line environment. Only when all SQL corresponding to a requirement is executed in the test environment can it be executed in the staging environment; similarly, only when all SQL in the staging environment is executed can it be executed in the real-line environment, to ensure that the execution of SQL files in each environment is carried out after the functional verification of the previous environment has passed.

[0097] Step 4: Archiving, that is, when the SQL file passes the functional verification in the real-line environment, all SQL files corresponding to the requirements corresponding to the SQL file can be archived. It is worth mentioning that once the SQL files corresponding to the requirements are archived, these SQL files cannot be modified or deleted.

[0098] In this way, the execution time of the SQL file is shortened. In a specific implementation, assume that there are 6 SQL files to be executed, the execution time unit of each SQL is n, and the execution operations of the 6 SQL files are: create table A, insert table A data 1, insert table A data 2, add table B field b, add C table index c, and insert table D data 3. In the traditional solution, the execution time spent on executing the SQL file is 6*n=6n. If multiple clients are opened for execution at the same time, although the execution time can be reduced, it also takes research and development time to sort out which SQLs in the SQL file can be executed in parallel and which are dependent. For example, SQL1, SQL4, SQL5, and SQL6 can be executed in parallel, and SQL2 and SQL3 can only be executed after SQL1 is executed. Assuming that the time consumed is m, and 4 execution windows are opened at the same time, and assuming that the time to open each window is k, the execution time corresponding to the above execution method is: m+4k+n1+n2; where m is the time to analyze SQL, 4k is the time to open 4 clients, n1 is the execution time corresponding to SQL1, SQL4, SQL5, and SQL6, and n2 is the execution time corresponding to SQL2 and SQL3. In addition, the value of m will increase as the number of SQLs increases, and 4k will also increase as the number of unordered SQL files increases.

[0099] In this embodiment, the dependency analysis operation on the SQL file has been completed after the SQL verification is completed, and does not occupy the execution time. The unordered SQL will open 4 threads for simultaneous execution, and the execution time is n. The remaining SQL2 and 3 need to continue to be executed in parallel after the thread executing SQL1 is completed, and the execution time is also n, so the total execution time is: 2n. At the same time, as the number of SQLs increases, the system can increase the total number of threads executing SQL by expanding the number of CPU cores or the number of machines.

[0100] In a specific implementation, m is 10s, n is 1s, k is 0.5s, the execution time of the traditional solution is m+4k+n+n=14s, and the execution time of this solution is 2n= 2s, which saves 85% of the time compared with the original solution.

[0101] It can be seen that the embodiment of the present application first needs to determine the SQL file to be processed based on the developer's needs, and use the preset syntax parser to disassemble the SQL file to be processed to obtain several objects to be verified, and then use the preset normative verifier to verify each object to be verified. If the first verification result obtained indicates that the verification is passed, then use the preset object existence verifier to verify each object to be verified. If the second verification result obtained indicates that the verification is passed, then use the preset risk verifier to verify each object to be verified to obtain a third verification result. Finally, if the third verification result indicates that the verification is passed, the preset executor is used and the SQL file to be processed is executed in several execution environments in sequence according to the preset execution order; the execution environment includes a test environment, a pre-release environment, and an actual user use environment. In this way, the security and speed of SQL file execution are improved, thereby improving the efficiency of the actual application process.

[0102] Accordingly, see Fig.15 As shown, the present application also provides a SQL file verification and execution device, including:

[0103] The file disassembly module 11 is used to determine the SQL file to be processed based on the developer's needs, and disassemble the SQL file to be processed using a preset syntax parser to obtain a number of objects to be verified;

[0104] The object verification module 12 is used to verify each of the objects to be verified using a preset normative verifier. If the first verification result obtained indicates that the verification is passed, the preset object existence verifier is used to verify each of the objects to be verified. If the second verification result obtained indicates that the verification is passed, the preset risk verifier is used to verify each of the objects to be verified to obtain a third verification result;

[0105] The file execution module 13 is used to execute the SQL file to be processed in several execution environments in sequence using a preset executor and in accordance with a preset execution order if the third verification result indicates that the verification has passed; the execution environment includes a test environment, a pre-release environment, and an actual user use environment.

[0106] As can be seen from the above, before the verification and execution of the SQL file, the embodiment of the present application first needs to determine the SQL file to be processed based on the developer's needs, and use the preset syntax parser to disassemble the SQL file to be processed to obtain a number of objects to be verified, and then use the preset normative verifier to verify each object to be verified. If the first verification result obtained indicates that the verification is passed, then use the preset object existence verifier to verify each object to be verified. If the second verification result obtained indicates that the verification is passed, then use the preset risk verifier to verify each object to be verified to obtain a third verification result. Finally, if the third verification result indicates that the verification is passed, the preset executor is used and the SQL file to be processed is executed in a number of execution environments in sequence according to the preset execution order; the execution environment includes a test environment, a pre-release environment, and an actual user use environment. In this way, the security and speed of SQL file execution are improved, thereby improving the efficiency of the actual application process.

[0107] In some specific implementations, the file disassembly module 11 may specifically include:

[0108] A character reading unit, used to use a preset reader in the preset syntax parser to read each character in the SQL file to be processed in sequence from left to right, and record a reading start position and a reading end position until the preset reader finishes reading the SQL file to be processed; wherein the condition for triggering the preset reader to end reading is that the read content is a line break character;

[0109] The character combination unit is used to combine the characters between each of the reading start positions and the corresponding reading end positions according to a preset combination rule to obtain a plurality of word combinations, and set the word combinations as objects to be verified.

[0110] In some specific implementations, the SQL file verification and execution device may further include:

[0111] A first object verification unit, configured to verify each of the objects to be verified respectively using a preset grammar verifier in the preset grammar parser and based on preset grammar rules, to obtain a corresponding fourth verification result;

[0112] A result judgment unit, used for judging whether each of the fourth verification results satisfies a first preset verification pass condition, and if the fourth verification results satisfy the first preset verification pass condition, sending the SQL file to be processed and each of the objects to be verified to the preset normative verifier;

[0113] An exception information generating unit is used to generate and return exception information and prompt information based on the fourth verification result if the fourth verification result does not meet the first preset verification pass condition.

[0114] In some specific implementations, the object verification module 12 may specifically include:

[0115] An object acquisition unit, configured to acquire an object to be standardized and verified from each of the objects to be verified based on user requirements;

[0116] The second object verification unit is used to use a preset standardization verifier and determine a corresponding verification method based on corresponding verification rules and verification logic, so as to use the corresponding verification method to verify the object name, name length, comment information and field length corresponding to each object to be standardized and verified, and obtain a first verification result, and send the SQL file to be processed and each object to be verified to the preset object existence verifier.

[0117] In some specific implementations, the SQL file verification and execution device may further include:

[0118] A dictionary information updating unit is used to use a preset data dictionary synchronization component in a preset data support component to store the data dictionary information corresponding to the changed business database in a preset structure to the local memory, scan the information in the local memory, and then use several threads in a preset thread pool to update the scanned data dictionary information to the preset data dictionary library; the data dictionary information includes a data table and a table name, field name and index name corresponding to the data table.

[0119] In some specific implementations, the object verification module 12 may specifically include:

[0120] a dictionary information verification unit, configured to verify the SQL file to be processed with the data dictionary information corresponding to the SQL file to be processed in the preset data dictionary library by using the corresponding verification rule in the preset object existence verifier, to obtain a fifth verification result;

[0121] A database judgment unit, used to judge whether the preset business database has a unique index, and if the preset business database has the unique index, using the preset business data synchronization component in the preset data support component and based on the unique index, storing the business data corresponding to the changed business database into the preset business database;

[0122] A data query unit, used to query data corresponding to each of the objects to be verified from a preset business database using the preset object existence verifier to obtain a query result;

[0123] A second verification result is determined based on the fifth verification result and the query result.

[0124] In some specific implementations, the file execution module 13 may specifically include:

[0125] A file execution unit, used to execute the SQL file to be processed in the test environment, the pre-release environment and the user's actual use environment in sequence using a preset executor and in a preset execution order; several core attributes corresponding to the SQL file to be processed during the execution process include the current execution environment, the next execution environment and the execution result;

[0126] The execution result judgment unit is used to judge whether the obtained execution result meets the preset archiving condition. If the execution result meets the preset archiving condition, the SQL file to be processed is archived to a preset archiving pool.

[0127] Furthermore, the present application also discloses an electronic device. Fig.16 It is a structural diagram of an electronic device 20 shown according to an exemplary embodiment, and the content in the figure cannot be regarded as any limitation on the scope of use of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the verification and execution method of the SQL file disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0128] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0129] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0130] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the verification and execution method of the SQL file executed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0131] Furthermore, the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned SQL file verification and execution method is implemented. For the specific steps of the method, reference may be made to the corresponding contents disclosed in the aforementioned embodiment, and no further description will be given here.

[0132] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0133] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0134] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0135] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0136] The technical solution provided by the present application is introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for general technicians in this field, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for checking and executing an SQL file, characterized in that: include: Determine the SQL file to be processed based on the developer's needs, and use a preset syntax parser to disassemble the SQL file to be processed to obtain several objects to be verified; Using a preset normativeness checker to check each of the objects to be checked, if the first check result obtained indicates that the check is passed, then using a preset object existence checker to check each of the objects to be checked, if the second check result obtained indicates that the check is passed, then using a preset risk checker to check each of the objects to be checked, to obtain a third check result; If the third verification result indicates that the verification is passed, the SQL file to be processed is executed in several execution environments in sequence using a preset executor according to a preset execution order; the execution environments include a test environment, a pre-release environment, and an actual user use environment.

2. The SQL file verification and execution method according to claim 1, characterized in that: The SQL file to be processed is disassembled by using a preset syntax parser to obtain several objects to be verified, including: Using a preset reader in the preset syntax parser to read each character in the SQL file to be processed in order from left to right, and recording the reading start position and the reading end position until the preset reader finishes reading the SQL file to be processed; wherein the condition for triggering the preset reader to finish reading is that the read content is a line break character; The characters between each of the reading start positions and the corresponding reading end positions are combined according to a preset combination rule to obtain a plurality of word combinations, and the word combinations are set as objects to be verified.

3. The SQL file verification and execution method according to claim 2, characterized in that: After the SQL file to be processed is disassembled by a preset syntax parser to obtain a number of objects to be verified, the method further includes: Using a preset grammar checker in the preset grammar parser and based on preset grammar rules, each of the objects to be checked is checked respectively to obtain a corresponding fourth check result; Determine whether each of the fourth verification results satisfies the first preset verification pass condition, and if the fourth verification results satisfy the first preset verification pass condition, send the SQL file to be processed and each of the objects to be verified to the preset normative verifier; If the fourth verification result does not meet the first preset verification pass condition, abnormal information and prompt information are generated and returned based on the fourth verification result.

4. The SQL file verification and execution method according to claim 1, characterized in that: The method of using a preset normative checker to check each of the objects to be checked includes: Acquire the object to be standardized and verified from each of the objects to be verified based on user needs; A preset standardization checker is used and a corresponding verification method is determined based on corresponding verification rules and verification logic, so as to use the corresponding verification method to verify the object name, name length, comment information and field length corresponding to each object to be standardized and verified, and obtain a first verification result, and send the SQL file to be processed and each object to be verified to the preset object existence checker.

5. The SQL file verification and execution method according to claim 1, characterized in that: Before verifying each of the objects to be verified by using the preset object existence verifier, the method further includes: The preset data dictionary synchronization component in the preset data support component is used to store the data dictionary information corresponding to the changed business database in the local memory in a preset structure, and the information in the local memory is scanned. Then, several threads in the preset thread pool are used to update the scanned data dictionary information to the preset data dictionary library; the data dictionary information includes a data table and the table name, field name and index name corresponding to the data table.

6. The SQL file verification and execution method according to claim 5, characterized in that: The using a preset object existence verifier to verify each of the objects to be verified includes: Using the corresponding verification rules in the preset object existence verifier, the SQL file to be processed is verified with the data dictionary information corresponding to the SQL file to be processed in the preset data dictionary library to obtain a fifth verification result; Determine whether the preset business database has a unique index. If the preset business database has the unique index, use the preset business data synchronization component in the preset data support component to store the business data corresponding to the changed business database into the preset business database based on the unique index; Utilizing the preset object existence verifier to query the data corresponding to each of the objects to be verified from the preset business database to obtain a query result; A second verification result is determined based on the fifth verification result and the query result.

7. The SQL file verification and execution method according to any one of claims 1 to 6, characterized in that: The method of executing the SQL file to be processed in a plurality of execution environments in sequence using a preset executor and in accordance with a preset execution order includes: Execute the SQL file to be processed in the test environment, the pre-release environment and the user's actual use environment in sequence by using a preset executor and in a preset execution order; several core attributes corresponding to the SQL file to be processed during the execution process include the current execution environment, the next execution environment and the execution result; It is determined whether the obtained execution result meets the preset archiving condition. If the execution result meets the preset archiving condition, the SQL file to be processed is archived to the preset archiving pool.

8. A SQL file verification and execution device, characterized in that: include: A file disassembly module is used to determine the SQL file to be processed based on the developer's needs, and disassemble the SQL file to be processed using a preset syntax parser to obtain a number of objects to be verified; An object verification module is used to verify each of the objects to be verified using a preset normative verifier. If the first verification result obtained indicates that the verification is passed, the preset object existence verifier is used to verify each of the objects to be verified. If the second verification result obtained indicates that the verification is passed, the preset risk verifier is used to verify each of the objects to be verified to obtain a third verification result; The file execution module is used to execute the SQL file to be processed in several execution environments in sequence using a preset executor and in accordance with a preset execution order if the third verification result indicates that the verification has passed; the execution environment includes a test environment, a pre-release environment, and an actual user use environment.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is used to execute the computer program to implement the steps of the SQL file verification and execution method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the steps of the SQL file verification and execution method according to any one of claims 1 to 7 are implemented.

Images