Database operation statement conversion method, medium, product and equipment

Abstract

The invention provides a database operation statement conversion method, a medium, a product and equipment. The method comprises the steps that a database operation statement is acquired, whether target screening clauses exist in the database operation statement or not is judged, and the target screening clauses contain existence judgment keywords and logic or keywords at the same time; under the condition that a target screening clause exists in the database operation statement, extracting an equivalent condition from a sub-query of the target screening clause; under the condition that null value equality judgment operation does not exist in the equivalence condition, determining a target connection mode supported by the target screening clause; and converting the database operation statement into a connection statement for generating a connection result at one time according to the target connection mode. By means of the method, the equivalence conditions in the target screening clauses can be extracted, the connection result can be obtained at a time, meanwhile, the converted connection statement can break through limitation of logic or keywords on query optimization, and an efficient connection algorithm can be fully utilized.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, medium, product, and device for converting database operation statements. Background Technology

[0002] In the current database technology field, the EXISTS clause is a commonly used existence test syntax. Its core function is to quickly determine the matching relationship between the main query table and the subquery table. The optimizer usually converts it into a physical execution plan of semi-join or left join + null check to avoid data row amplification and reduce query overhead.

[0003] However, existing technologies face significant bottlenecks when the EXISTS clause is combined with logical OR conditions (i.e., EXISTS(...) OR P(t1)). Traditional database optimizers cannot effectively convert such combined conditions into efficient join operations, and can only execute them by row-by-row correlated subquery probing or partial rewriting, resulting in low query efficiency. Specific drawbacks include: first, the three-valued logic (TRUE / FALSE / UNKNOWN) of OR conditions undermines the feasibility of predicate pushdown and equivalent rewriting, limiting the optimizer's optimization space; second, the intertwining of join amplification and deduplication semantics makes it difficult for the optimizer to accurately estimate data cardinality and selectivity, further affecting the rationality of the execution plan.

[0004] To address this issue, Oracle databases have optimized the semi-join execution logic to support specific scenarios such as EXISTS (related equality conditions) OR (equality elements in the main query) IS NULL. However, this solution only covers some special cases and fails to fundamentally solve the optimization problem for all EXISTS OR combination conditions, still exhibiting limitations in its narrow applicability and optimization effect. Therefore, a general optimization solution that can fully adapt to EXISTS OR conditions is urgently needed to overcome the limitations of existing technologies and improve the query performance of relational databases. Summary of the Invention

[0005] In view of the above problems, the present invention proposes a method, medium, product and device for converting database operation statements to overcome the above problems or at least partially solve the above problems.

[0006] One objective of this invention is to improve the flexibility of database operation statement conversion.

[0007] A further objective of this invention is to reduce the execution complexity of database operation statements.

[0008] Specifically, the present invention provides a method for converting database operation statements, comprising: Retrieve database operation statements and determine whether a target filter clause exists in the database operation statements. The target filter clause contains both existence determination keywords and logical OR keywords. When a target filter clause exists in a database operation statement, extract the equality conditions from the subquery of the target filter clause; This function checks if there are null values ​​among the equality conditions. If there is no null value equality check operation in the equality condition, determine the target connection method supported by the target filter clause; Convert database operation statements into connection statements that generate connection results in one go, based on the target connection method.

[0009] Optionally, the target connection method includes an external connection; When the target join type is an outer join, the steps to convert the database operation statement into a join statement that generates the join result in one go, based on the target join type, include: Determine the main query table and subquery table in the target filter clause. The main query table is the main data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table. Determine the main query join key and subquery join key in the equality condition. The main query join key is the data column of the main query table that is joined, and the subquery join key is the data column of the subquery table that is joined. Create a deduplication clause for the subquery join key, and perform an outer join operation using the main query join key and the deduplication clause; Establish a non-null filter condition for the subquery join key; Combine the non-empty filter condition with the filter condition corresponding to the logical OR keyword as a predicate and add it to the conditional clause of the join statement.

[0010] Optionally, the target connection method includes a half-connection; When the target join type is a half-join, the steps to convert database operation statements into join statements that generate join results in one go include: Determine the main query table and subquery table in the target filter clause. The main query table is the main data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table. Determine the main query join key and subquery join key in the equality condition. The main query join key is the data column of the main query table that is joined, and the subquery join key is the data column of the subquery table that is joined. Perform a semi-join operation using the primary query join key and the subquery join key; Establish a non-null filter condition for the subquery join key; Combine the non-empty filter condition with the filter condition corresponding to the logical OR keyword as a predicate and add it to the conditional clause of the join statement.

[0011] Optionally, the steps of converting database operation statements into connection statements that generate connection results in one go, based on the target connection method, include: Determine the main query table and subquery table in the target filter clause. The main query table is the main data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table. Combine the filtering conditions of the subquery table to create a deduplication view for the subquery table, and use the deduplication view to replace the subquery table in the target filter clause. The deduplication view is used to filter the data columns involved in the judgment in the subquery table while adding the deduplication function. The main query table and the deduplicated view are joined according to the target join method to obtain the join statement; Establish non-empty filtering conditions for the deduplicated view; Add the non-empty filter condition and the filter condition corresponding to the logical OR keyword as predicates to the conditional clause of the join statement.

[0012] Optionally, the step of determining whether there is a null value equality check in the equality conditions further includes: In cases where null value equality checks exist within the equality conditions, determine the target connection methods supported by the target filtering clause; Determine the main query table and subquery table in the target filter clause. The main query table is the main data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table. Combine the filtering conditions of the subquery table to create a target view for the subquery table, and use the target view to replace the subquery table in the target filter clause. The target view is used to filter the data columns involved in the judgment in the subquery table, add a deduplication function, and add an existence flag to each filtering result. The existence flag is used to indicate that the data attribute of this row is true. The main query table and the target view are joined according to the target join method to obtain the join statement; Construct a non-nullable function based on the target view. The non-nullable function is used to return true if data that meets the conditions exists in the target view, and false if data that does not meet the conditions does not exist. Add the filtering conditions corresponding to the non-empty value function and the logical OR keyword as predicates to the conditional clause of the join statement.

[0013] Optionally, the non-empty value function includes: the COALESCE function; The COALESCE function takes two parameters: the first parameter is the presence marker in the target view, and the second parameter is false.

[0014] Optionally, the existence determination keywords include: EXISTS; Logical OR keywords include: OR; Equality criteria can include single-column equality criteria or multi-column equality criteria: When the equality condition is a multi-column equality condition, the equality join key in the equality condition is a multi-column combination join key.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the database operation statement conversion method described above are implemented.

[0016] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the database operation statement conversion method described above.

[0017] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor executes the machine-executable program to implement the steps of the database operation statement conversion method described above.

[0018] The database operation statement conversion method of this invention involves: acquiring the database operation statement and determining whether a target filter clause exists within it; the target filter clause containing both existence-based keywords and logical OR keywords; extracting equality conditions from the subqueries of the target filter clause if one exists; determining whether null value equality checks exist within the equality conditions; determining the target join mode supported by the target filter clause if no null value equality checks exist; and converting the database operation statement into a join statement that generates a join result in one step based on the target join mode. This method extracts the equality conditions from the target filter clause, enabling a one-time join result, eliminating the need to execute a related subquery for each row of data. Furthermore, the converted join statement overcomes the limitations of logical OR keywords on query optimization, fully utilizes efficient join algorithms, avoids resource consumption caused by join amplification and repeated probing, significantly improves CPU and memory locality, and substantially reduces query latency.

[0019] Furthermore, the database operation statement conversion method of the present invention, when there is a null value equality judgment operation in the equality condition, determines the target join mode supported by the target filter clause; determines the main query table and subquery table in the target filter clause, where the main query table is the main data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence judgment of the main query table; establishes a target view for the subquery table in combination with the filtering conditions of the subquery table, and replaces the subquery table in the target filter clause with the target view, the target view is used to filter the data columns participating in the judgment in the subquery table while adding deduplication function, and adds an existence mark to each filtering result, the existence mark is used to indicate that the data attribute of the row is true; connects the main query table and the target view according to the target join mode to obtain the join statement; constructs a non-null value function based on the target view, the non-null value function is used to return true when there is data that meets the conditions in the target view, and returns false when there is no data that meets the conditions; adds the non-null value function and the filtering conditions corresponding to the logical OR keyword as predicates to the condition clause of the join statement. This method can explicitly group UNKNOWN results into unmatched values ​​using a non-null value retrieval function, completely solving the problem of misjudgment of null value matching in traditional rewriting. It has low implementation cost and strong portability, and is suitable for both explicit SQL rewriting and automatic triggering as a rule or cost check in the optimizer.

[0020] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0021] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a method for converting database operation statements according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a method for converting database operation statements according to another embodiment of the present invention; Figure 3 This is a flowchart illustrating a method for converting database operation statements according to yet another embodiment of the present invention; Figure 4 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 6This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0022] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0023] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0024] In the current database technology field, SQL (Structured Query Language) is an alternative example of database operation statements. SQL statements have multiple functions such as data manipulation and data definition. This language is interactive and can provide users with great convenience. In specific query processing, the join operation of SQL statements is the core means to realize multi-table data association and complex logical queries, but some SQL statements have room for optimization.

[0025] Figure 1 This is a flowchart illustrating a method for converting database operation statements according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method for converting database operation statements includes at least the following steps S101 to S104.

[0026] Step S101: Obtain database operation statements. In this step, the database operation statements can generally be obtained through user input or automatically generated by the database program during operation due to business requirements. Those skilled in the art can decide on the method of obtaining database operation statements based on the actual situation.

[0027] Step S102: Determine whether a target filter clause exists in the database operation statement. The target filter clause is a statement that contains both an existence check keyword and a logical OR keyword. The existence check keyword is generally the EXISTS keyword. Its core function is to determine whether there are matching rows between the main query table and the subquery table. The logical OR keyword is generally the OR keyword, used to connect the EXISTS subquery with other filtering conditions on the main query side (such as t1.b<10), forming a combined structure of EXISTS(...) OR P(t1). An optional SQL example is shown in equation (1): SELECT *FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t1.id = t2.id)OR t1.b<10 Formula (1) If the judgment result of step S102 is negative (i.e., there is no filter clause containing both EXISTS and OR in the statement), then there is no need to perform subsequent conversion steps, and the statement can be executed according to the normal database logic; if the judgment result is positive, then proceed to step S103 to continue optimizing the process.

[0028] Step S103: If the determination in step S102 is yes, extract the equality condition from the subquery of the target filtering clause. This step is a key prerequisite for achieving efficient join transformation. The core purpose is to extract the equality matching relationship between the main query table and the subquery table, i.e., the equality condition, from the conditional expression of the EXISTS subquery. The essence of the equality condition is the column matching rule between the main query table and the subquery table. Its extraction logic is generally to identify the equality expression of the form t1.col=t2.col from the WHERE clause of the EXISTS subquery. Taking equation (1) as an example, in the SQL statement shown in equation (1), the WHERE clause of the EXISTS subquery is t1.id=t2.id. This expression is the extracted equality condition, where t1.id is a column of the main query table t1 and t2.id is a column of the subquery table t2.

[0029] Furthermore, the equality conditions support two types, both of which are within the scope of this method. One type is a single-column equality condition: that is, the main query table and the subquery table are matched for equality through a single column, such as t1.id=t2.id above; the other type is a multi-column equality condition: that is, the main query table and the subquery table are matched for equality through a combination of multiple columns, for example (t1.k1,t1.k2)=(t2.k1,t2.k2), in which case the equality join key is a multi-column combination join key consisting of (k1,k2).

[0030] Step S104: Determine if a null value equality check operation exists in the equality conditions. The core purpose of this step is to select the corresponding join transformation logic based on the type of the equality conditions (whether they include null value checks). One possible example of a null value equality check operation is the equality check operation of the IS NOT DISTINCT FROM operator. During the execution of this operator, a scenario may occur where the join key of both the main query table and the subquery table is NULL (i.e., NULL=NULL structure, which is called a null value equality check operation).

[0031] The traditional equality operator (=) returns UNKNOWN when dealing with NULL values, failing to accurately determine existence. In contrast, the IS NOT DISTINCT FROM operator treats NULL as an equal value, and the result of NULL IS NOT DISTINCT FROM NULL is TRUE, making it suitable for scenarios where NULL values ​​need to be considered as matches.

[0032] Therefore, if the equality condition is t1.id IS NOT DISTINCT FROM t2.id, it is determined that the statement contains a null value equality check; if the equality condition is t1.id=t2.id, it is determined that there is no null value equality check.

[0033] The result of this step directly determines the subsequent conversion logic: if the result is negative, execute the normal scenario conversion logic of steps S105 to S106; if the result is positive, then another null value scenario conversion logic needs to be executed.

[0034] Step S105: If the condition in step S104 is negative, determine the target join method supported by the target filter clause. The core of this step is to select an efficient join method based on the database optimizer's support. The rewritten rule generally prioritizes semi-joins, and uses outer joins if not supported. Therefore, the target join methods in this method include semi-joins and outer joins. Taking a left join as an example (a right join only requires adjusting the position accordingly), a semi-join is a LEFT SEMI JOIN, and an outer join is a LEFT JOIN. The logic for determining the join method generally includes: First, determine whether the database optimizer supports half-join operations: The core semantics of a half-join is to return only the records in the main query table that match the subquery table. Its inherent characteristics can guarantee the filtering meaning that the EXISTS clause is true as long as it exists, without the need for additional deduplication. If the optimizer does not support semi-joins, then an outer join is chosen: an outer join can retain all records of the main query table, and indirectly implement the existence determination logic of EXISTS through subsequent deduplication and non-null filtering.

[0035] The selection logic in this step aims to maximize query efficiency: semi-joins are the optimal physical execution plan for the EXISTS clause, while outer joins are a universal solution compatible with all databases. Both can avoid the inefficiency of traditional row-by-row subquery probing.

[0036] Step S106: Convert the database operation statement into a join statement that generates the join result in one step, based on the target join method. This step is the core execution stage of the method. Generating the join result in one step means that, compared to the traditional row-by-row correlation subquery probing and matching mode, this method completes the association between the main query table and the subquery table in a single join operation, directly generating all matching results, which greatly improves query efficiency. Depending on the target join method, the specific implementation of this step is divided into the following two optional embodiments: In some optional embodiments, the target join method includes an outer join. When the target join method is an outer join, the steps of converting the database operation statement into a join statement that generates the join result in one go, based on the target join method, generally include: determining the main query table and subquery table in the target filter clause, where the main query table is the primary data source of the query results in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table; determining the main query join key and subquery join key in the equality condition, where the main query join key is the data column of the main query table that participates in the join, and the subquery join key is the data column of the subquery table that participates in the join; creating a deduplication clause for the subquery join key, and performing an outer join operation using the main query join key and the deduplication clause; creating a non-null filter condition for the subquery join key; and combining the non-null filter condition with the filter condition corresponding to the logical OR keyword as a predicate and adding it to the condition clause of the join statement.

[0037] When the database optimizer does not support half-joins, it uses the logic of outer join + deduplication + non-null filtering. The following is a further explanation based on the SQL statement shown in equation (1). The specific steps are as follows: Step 1. Determine the main query table and subquery table: Main query table: that is, the main data source of the query results in the target filter clause (such as table t1 in formula (1)), whose data is the core output object of the query results; Subquery table: A data table used to support the existence determination of the main query table (such as table t2 in equation (1)). Its function is to provide the basis for matching.

[0038] Step 2. Determine the main query join key and the subquery join key: Main query join key: The data column in the main query table that participates in the join, corresponding to the column on the main query table side in the equality conditions extracted in step S103 (such as t1.id). Subquery join key: The data column in the subquery table that is joined, corresponding to the column on the subquery table side in the equality condition (e.g., t2.id); If the equality condition is a multi-column equality condition (such as t1.k1=t2.k1 AND t1.k2=t2.k2), then the main query join key and the subquery join key are both multi-column composite keys ((t1.k1,t1.k2) and (t2.k1,t2.k2)). When joining, the rules of matching multiple columns one by one are followed to ensure matching accuracy.

[0039] Step 3. Create a deduplication clause and perform an outer join operation: Constructing a deduplication clause: Since outer joins retain all matching records from the subquery table, duplicate data in the subquery table can lead to an amplification of records in the main query table. Therefore, it is necessary to deduplicate the join key of the subquery. Deduplication can generally be achieved using the DISTINCT keyword or the GROUP BY clause. For example, to deduplicate the id column of table t2, a deduplication clause can be formed (select distinct id from t2). Outer join execution: Outer joins are performed using the main query join key and deduplication clauses. For example, the outer join rewrite result of the exemplary SQL is shown in equation (2): SELECT t1.* FROM t1 LEFT JOIN (select distinct id from t2) as t2 ont1.id = t2.id Formula (2) The SQL statement shown in equation (2) can generate all matching relationships between table t1 and the deduplicated table t2 in one go through a single connection. The t2 column value corresponding to the unmatched t1 record is NULL.

[0040] Step 4. Establish non-empty filtering conditions: The core function of the non-null filter condition is to determine existence: after an outer join, if the subquery join key is not NULL, it means that the record in the main query table has a match in the subquery table (i.e., EXISTS is true); if it is NULL, it means that there is no match (EXISTS is false). An optional example of the non-null filter condition is: key is not null. Taking equation (1) as an example, the final non-null filter condition generated is t2.id IS NOT NULL.

[0041] Step 5. Combine the filter conditions and generate the final join statement: Combine the non-empty filter condition with the filter condition corresponding to the original OR keyword (such as t1.b<10) as the condition clause of the join statement to ensure that the original query semantics are not lost. The final generated connection statement is shown in equation (3): SELECT t1.* FROM t1 LEFT JOIN (select distinct id from t2) as t2 ont1.id = t2.id WHERE t2.id IS NOT NULL OR t1.b < 10 Formula (3) The SQL statement shown in equation (3) first deduplicates the data on the right side to ensure the uniqueness of the result set on the right side; then, it retains the information of the left column through left join, filters it with the ON condition, and the right side of the content that does not meet the equality condition (t1.id=t2.id) is empty, and then filters it with the outer NULL value judgment condition (t2.id IS NOT NULL), and the additional OR condition is also filtered at the same time. The rewritten SQL statement, because the equality condition is extracted, can use hashjoin and mergejoin to connect, expand the SQL optimization capabilities, and thus improve performance in most scenarios; In some alternative embodiments, the target join method also includes a semi-join. When the target join method is a semi-join, the steps of converting the database operation statement into a join statement that generates the join result at once generally include: determining the main query table and subquery table in the target filter clause, where the main query table is the main data source of the query result in the target filter clause, and the subquery table is a data table used to support the existence determination of the main query table; determining the main query join key and subquery join key in the equality condition, where the main query join key is the data column of the main query table that participates in the join, and the subquery join key is the data column of the subquery table that participates in the join; performing a semi-join operation using the main query join key and the subquery join key; establishing a non-null filter condition for the subquery join key; and adding the combination of the non-null filter condition and the filter condition corresponding to the logical OR keyword as a predicate to the condition clause of the join statement. When the database optimizer supports a semi-join, a simplified logic of semi-join + non-null filter is adopted. The following is a further explanation in conjunction with the SQL statement shown in equation (1). The specific steps are as follows: Step 1. Determine the main query table and subquery table: The main query table is the main data source of the query results (e.g., t1), and the subquery table is the existence determination table (e.g., t2).

[0042] Step 2. Determine the main query join key and subquery join key: Consistent with the previous embodiment, the rules for a single join key or a combination of multiple columns join keys are exactly the same to ensure the accuracy of join matching.

[0043] Step 3. Perform a semi-join operation: The inherent semantics of a semi-join is to return only the records in the main query table that match the subquery table. During its execution, it automatically ignores duplicate data in the subquery table, so there is no need to manually create a deduplication clause like with an outer join.

[0044] Step 4. Establish and combine non-null filter conditions: The logic of the non-null filter conditions is the same as in the previous embodiment, and the existence is determined based on the non-null state of the subquery join key (e.g., t2.id IS NOT NULL); after combining the original OR conditions, the final generated join statement is shown in equation (4): SELECT t1.* FROM t1 LEFT SEMI JOIN t2 on t1.id = t2.id WHERE t2.id ISNOT NULL OR t1.b < 10 Formula (4) This statement maximizes the efficient execution characteristics of semi-joins while preserving the original query semantics.

[0045] The join statements generated by the method of this invention, through a combination of equality condition extraction, efficient joining, and precise filtering logic, achieve the following main effects: 1. Performance improvement: The complexity of traditional row-by-row subquery probing is transformed into a single join + simple filtering, improving CPU and memory locality and avoiding join amplification; 2. Semantic fidelity: Through deduplication (outer join scenario), inherent semantics of semi-joins, and non-empty filtering, the query semantics of the original EXISTS OR condition are fully restored; 3. Strong compatibility: Supports single-column / multi-column equality conditions and two join methods: semi-join / outer join, adapting to the optimizer features of various relational databases.

[0046] Figure 2 This is a flowchart illustrating a method for converting database operation statements according to another embodiment of the present invention. Figure 2 As shown, the method for converting database operation statements includes at least the following steps S201 to S207.

[0047] The database operation statement transformation method provided in this embodiment is another core optional solution for scenarios where there is no null value equality judgment operation in the equality condition. Its core design idea is: to replace the scattered processing logic of traditional subqueries by establishing a deduplication view with filtering and deduplication functions, then to complete the connection between the main query table and the deduplication view based on the target join method, and finally to generate an efficient query statement by combining filtering conditions. This method is similar to... Figure 1 The parallel approach of outer join + deduplication clause and semi-join direct conversion essentially solidifies the filtering and deduplication logic of subqueries into a view, further simplifying the conversion process and improving the stability of query execution.

[0048] The following combination Figure 2 Steps S201 to S207 are explained in detail using the SQL statement shown in formula (1) as an example.

[0049] Step S201, determine the target connection method supported by the target filtering clause. In this step, according to the function support of the database optimizer, an efficient target connection method is selected. The specific rule is to preferentially select a semi-join; when it is not supported, an outer join is used. If the optimizer supports a semi-join (LEFT SEMI JOIN), the semi-join is used as the target connection method, so as to utilize the inherent semantics of the semi-join to only return the matching records of the main query table without additional processing of the connection amplification problem; if the optimizer does not support the semi-join, the outer join (LEFT JOIN) is used as the target connection method, so as to avoid the record amplification risk caused by the outer join through the subsequent duplicate removal logic of the importance graph.

[0050] Step S202, determine the main query table and the subquery table in the target filtering clause. Specifically, the main query table is the main data source of the query result in the target filtering clause (such as the t1 table in the example), and its data is the core output content of the final query result. All connection and filtering operations are carried out around the record filtering of the main query table; the subquery table is the data source used to support the existence determination of the main query table (such as the t2 table in the example), and its core role is to provide the determination basis for "whether there is a match for the records in the main query table".

[0051] Step S203, establish a duplicate removal view for the subquery table in combination with the filtering conditions of the subquery table.

[0052] This step is the core innovation point of this optional solution. Its core purpose is to integrate the filtering logic and the duplicate removal logic of the subquery table into a single duplicate removal view, avoiding the complex problem of optimizer decision-making caused by decentralized processing. The specific implementation details are as follows: Recognition of the filtering conditions of the subquery table: The filtering conditions refer to the filtering conditions for the subquery table (such as t2) in the original EXISTS subquery. If there are no filtering conditions for the subquery table in the subquery (such as the example SQL), the duplicate removal view only retains the duplicate removal logic.

[0053] The duplicate removal view is a database view that includes both filtering and duplicate removal functions. The rules to be followed for its creation generally include: using keywords with duplicate removal properties such as the DISTINCT keyword or the GROUP BY clause to remove duplicates for the subquery connection key in the equality condition, ensuring the uniqueness of the connection key in the view, and avoiding record amplification caused by subsequent connection operations; it is also necessary to directly embed the filtering conditions of the subquery table into the query logic of the view so that the view only retains the records that meet the filtering conditions, reducing the data volume of subsequent connection operations. The result is generally: WITH cte_exist AS (SELECT DISTINCT id (or GROUP BY id) FROM t2 WHERE <filtering conditions on the t2 side>) Applied to the SQL statement shown in formula (1), its corresponding duplicate removal view is: WITH cte_exist AS (SELECT DISTINCT id (or GROUP BY id) FROM t2) Step S204: Replace the subquery table in the target filter clause with a deduplicated view.

[0054] The core of this step is to complete the logical replacement from the subquery table to the deduplicated view, specifically implemented as follows: The original target filtering clause's EXISTS subquery uses a subquery table (e.g., t2) as its data source. After replacement, the subquery's data source becomes the deduplicated view (e.g., t2_distinct_view) established in step S203, but the equality matching relationship between the subquery and the main query table remains unchanged. The significance of replacement is to solidify the scattered deduplication and filtering logic into the view, so that subsequent join operations only need to be performed based on the view, without needing to handle the extra logic of the subquery table, thus simplifying the complexity of subsequent join transformations.

[0055] Step S205: Connect the main query table and the deduplication view according to the target join method to obtain the join statement.

[0056] This step is the core execution stage of the transformation. The core logic is to complete a single join between the main query table and the deduplicated view based on the target join method, generating the join result in one go. Specifically, this is implemented in two scenarios: Scenario 1: The target connection method is a half-connection Join logic: The inherent semantics of a semi-join is to return only the records in the main query table that match the data source. Since the deduplicated view has already ensured that the join key is unique, a semi-join can be performed directly based on the equality condition without the need for additional deduplication. SELECT t1.* FROM t1 LEFT SEMI JOIN cte_exist cte ON t1.id = cte.id; Scenario 2: The target connection method is an external connection. Join logic: Outer joins retain all records from the main query table, and the deduplication feature of deduplicated views has already prevented join amplification. Therefore, outer joins can be performed directly based on equality conditions without additional processing of duplicate data. SELECT t1.* FROM t1 LEFT JOIN cte_exist cte ON t1.id = cte.id; Regardless of the join method, the join statement generated in this step achieves the goal of generating join results in one go, completely replacing the inefficient mode of traditional row-by-row correlated subquery probing.

[0057] Step S206: Establish non-empty filtering conditions for the deduplicated view.

[0058] The core of this step is to achieve the "existence check" semantics of the original EXISTS clause through a NOT NULL check. After the join operation, if the join key of the deduplicated view (e.g., cte.id) is not NULL, it means that the current record in the main query table exists in the deduplicated view (i.e., the original EXISTS check is true); if it is NULL, it means there is no match (EXISTS check is false). For the deduplicated view cte_exist in the example SQL, the NOT NULL filter condition is: cte.id IS NOT NULL. In this way, through a simple NOT NULL check, the core semantics of the original EXISTS clause can be accurately restored, avoiding semantic deviations caused by view replacement or join method selection.

[0059] Step S207: Add the non-empty filter condition and the filter condition corresponding to the logical OR keyword as predicates to the conditional clause of the join statement.

[0060] The core purpose of this step is to combine filtering conditions to ensure that the original query semantics are not lost. Specifically, this is achieved by using a combination of non-empty filtering conditions, logical OR keywords, and original OR conditions. Here, the non-empty filtering conditions correspond to the existence determination logic of the original EXISTS clause; the original OR conditions refer to other filtering conditions in the target filtering clause that are parallel to the EXISTS clause (such as t1.b<10 in the example); the predicate formed after the combination is logically equivalent to the original target filtering clause.

[0061] The final transformation result of the SQL statement shown in equation (1) is as follows: The final statement in the semi-join scenario is shown in equation (5): WITH cte_exist AS (SELECT DISTINCT id FROM t2) SELECT t1.* FROM t1LEFT SEMI JOIN cte_exist cte ON t1.id = cte.id WHERE cte.id IS NOT NULL ORt1.b < 10 Formula (5) Since semi-connects have built-in deduplication properties, those skilled in the art can choose whether to delete the deduplication function in the deduplication view of formula (5) according to actual needs, that is, delete the deduplication keyword DISTINCT.

[0062] The final statement in the outer join scenario is shown in equation (6): WITH cte_exist AS (SELECT DISTINCT id FROM t2) SELECT t1.* FROM t1LEFT JOIN cte_exist cte ON t1.id = cte.id WHERE cte.id IS NOT NULL OR t1.b <10 Formula (6) The combined predicate completely replicates the logic of the original EXISTS(...) OR t1.b<10, ensuring that the query results are consistent with the original SQL. Furthermore, the final statement fully utilizes efficient database join algorithms such as hashjoin and mergejoin, avoiding row-by-row probing in traditional subqueries. The integration logic of deduplicated views also reduces the optimizer's decision-making cost, further improving query efficiency.

[0063] The "duplicate view + connection" conversion method provided in this embodiment is similar to... Figure 1 The "outer join + deduplication clause" and "semi-join direct conversion" methods are parallel options, with the core difference being the "carrier of the deduplication logic." Specifically, the deduplication clause method uses a temporary subquery for deduplication logic, suitable for scenarios where deduplication logic does not need to be reused; the deduplication view method solidifies the deduplication logic into a view, suitable for scenarios where deduplication logic needs to be reused multiple times; and the semi-join direct conversion method requires no additional deduplication carrier, suitable for scenarios where the optimizer supports semi-joins. Those skilled in the art can choose the appropriate conversion method according to their actual needs.

[0064] Ultimately, this method transforms the complexity of traditional row-by-row subquery probing into a single join plus simple filtering, improving CPU and memory locality, avoiding join amplification, and enhancing database query efficiency.

[0065] Figure 3 This is a flowchart illustrating a method for converting database operation statements according to another embodiment of the present invention. Figure 3 As shown, the method for converting database operation statements includes at least the following steps S301 to S307.

[0066] The database operation statement conversion method provided in this embodiment is used to adapt to scenarios where there are null value equality judgment operations in the equality conditions (i.e., the case where NULL=NULL exists). Its core design idea is: by establishing a target view that integrates filtering, deduplication, and existence marking, the pain point of not being able to accurately determine the existence of non-null values ​​in the null value scenario is solved. Then, the connection between the main query table and the target view is completed based on the target join method. Finally, by combining the non-null value retrieval function with the original OR condition, a semantically accurate and high-performance query statement is generated.

[0067] This method precisely addresses the optimization requirements of the "NULL=NULL structure" and completely solves the problem of misjudging t2.id as true even though it is still NULL after LEFT JOIN in traditional rewriting.

[0068] The following combination Figure 3 Steps S301 to S307 are explained in detail with reference to the exemplary SQL expression (7): SELECT t1.*FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t1.id IS NOTDISTINCT FROM t2.id ) OR t1.b < 10 Formula (7) Step S301: Determine the target connection methods supported by the target filtering clause.

[0069] The core logic of this step is consistent with the aforementioned embodiments, prioritizing half-joins. If the database optimizer does not support half-joins, then an outer join is chosen. This is because the semantics of a half-join is to return matching records from the main query table, which aligns with the logic that a match is true if the EXISTS clause exists. Furthermore, the target view has already undergone deduplication, eliminating the need for additional join amplification. On the other hand, an outer join can retain all records from the main query table. Combined with the existence flag and NOT NULL function of the target view, it can accurately reproduce the existence determination logic, thus adapting to databases that do not support half-joins.

[0070] Step S302: Determine the main query table and subquery table in the target filter clause. The main query table is the main data source of the query results in the target filter clause (such as table t1 in equation (7)). Its data is the core output of the final query results. All join and filtering operations revolve around the filtering of records in the main query table. The subquery table is the data source that supports the existence determination of the main query table (such as table t2 in equation (7)). Its core function is to provide the basis for determining whether there is a null value match in the records of the main query table.

[0071] Step S303: Create a target view for the subquery table based on its filtering conditions. The target view is used to filter the data columns involved in the judgment in the subquery table, add deduplication functionality, and add an existence flag to each filtered result. The existence flag indicates that the data attribute of that row is true.

[0072] Specifically, the filtering function merges the filtering conditions (if any) of the subquery table (such as t2) into the view logic to reduce the amount of data in subsequent joins; the deduplication function uses the DISTINCT keyword or GROUP BY clause to deduplicate the subquery join key (such as t2.id) in the equality condition to avoid record amplification caused by subsequent joins; the existence marking function adds a boolean existence mark (fixed to TRUE) to each deduplicated record for subsequent existence determination, thereby solving the problem of misjudgment in null value scenarios.

[0073] Taking equation (7) as an example, its t2 table does not have any additional filtering conditions, so its target view is WITH cte AS(SELECT DISTINCT id, TRUE AS exist FROM t2).

[0074] In some alternative implementations, if table t2 has additional filtering conditions, its target view can be set to WITH cte AS (SELECT DISTINCT id, TRUE AS exist FROM t2 WHERE filter conditions).

[0075] This step transforms the existence of null value matches into an explicit Boolean signal through an existence flag, avoiding the misjudgment of existence based on the join key being non-null in traditional schemes. In null value scenarios, even if the join key is NULL, as long as the existence flag is TRUE, a match can be determined to exist.

[0076] Step S304: Replace the subquery table in the target filter clause with the target view.

[0077] This step completes the logical replacement from the subquery table to the target view, ensuring that subsequent join operations are based on the target view. The specific implementation logic is as follows: keep the equality matching relationship of the original EXISTS subquery unchanged, and only replace the data source of the subquery from the subquery table (such as t2) to the target view (such as cte) established in step S303.

[0078] One possible example is as follows: Replace the EXISTS clause with: EXISTS (SELECT 1 FROM t2 WHERE t1.id IS NOT DISTINCT FROM t2.id); The intermediate logic after replacement is: EXISTS (SELECT 1 FROM cte WHERE t1.id IS NOT DISTINCTFROM cte.id).

[0079] This step solidifies the filtering, deduplication, and existence marking logic of the subquery table into the target view, so that subsequent joins and existence determinations only need to be based on the explicit fields of the view (join key + existence mark), simplifying the transformation process and avoiding semantic deviations caused by multi-step scattered processing.

[0080] Step S305: Connect the main query table and the target view according to the target join method to obtain the join statement.

[0081] The core logic of this step is to complete a single join between the main query table and the target view based on the target join method, generating the join result in one go, thereby avoiding row-by-row related subquery probing. This can be implemented in two scenarios: Scenario 1: The target connection method is a half-connection Since the inherent semantics of a semi-join are consistent with the EXISTS clause, and the target view has already been deduplicated and marked as existent, a semi-join can be performed directly based on null value equality conditions (such as IS NOT DISTINCT FROM) without additional processing. The transformed result is SELECT t1.* FROM t1 LEFT SEMI JOIN cte ON t1.id IS NOT DISTINCT FROM cte.

[0082] Scenario 2: The target connection method is an external connection. Because outer joins retain all records from the main query table, the deduplication property of the target view prevents join amplification, and null value equality conditions ensure that NULL values ​​are considered matches. After the join, the `exist` field of the target view is TRUE only when a match is found, and NULL when no match is found. The transformed result is `SELECT t1.* FROM t1 LEFT JOIN cte ON t1.id IS NOTDISTINCT FROM cte.id`.

[0083] Regardless of the join method, the join statement generated in step S305 achieves one-time generation of join results, completely replacing the traditional row-by-row subquery probing and significantly improving CPU and memory locality.

[0084] Step S306: Construct a non-nullable function based on the target view. The non-nullable function returns true if data matching the conditions exists in the target view, and false if no data matching the conditions exists.

[0085] This step is crucial for resolving misjudgments in null value scenarios. The core is to convert nullable existence markers (TRUE / NULL) in the target view into definite boolean values ​​(TRUE / FALSE) using a non-nullable value retrieval function. The non-nullable value retrieval function constructed in this step is typically the COALESCE function, which contains two parameters: the first is the existence marker in the target view (the exist field, with a value of TRUE or NULL), and the second is the fixed boolean value FALSE.

[0086] The execution logic of the COALESCE function is as follows: it reads parameters from left to right and returns the first non-NULL parameter value. Combined with the above settings of the COALESCE function, UNKNOWN (corresponding to the existence flag NULL) in the SQL three-value logic can be explicitly merged into FALSE, avoiding ambiguity in existence determination caused by NULL. Specifically: if there is a match, exist=TRUE, and the function returns TRUE; if there is no match, exist=NULL, and the function returns FALSE.

[0087] Taking equation (7) as an example, the non-empty value function it constructs is: COALESCE(cte.exist,FALSE). If it is a multi-column equality condition, the existence marker is still a single TRUE, the function form remains unchanged, and the multi-column combination key only affects the connection matching, without affecting the Boolean value characteristics of the existence marker.

[0088] This step completely solves the pain point of not being able to determine the existence of a non-null join key in null value scenarios. It transforms the existence determination into a strict Boolean value judgment through explicit function logic, ensuring compatibility with SQL three-value logic.

[0089] Step S307: Add the filtering conditions corresponding to the non-empty value function and the logical OR keyword as predicates to the conditional clause of the join statement.

[0090] This step is the final combination stage, and its purpose is to combine the filtering conditions to ensure that the original query semantics are not lost. Specifically, it is implemented by using a combination of a non-empty value function, a logical OR keyword (OR), and the original OR condition. The non-empty value function corresponds to the existence determination logic of the original EXISTS clause; the original OR condition refers to other filtering conditions in the target filtering clause that are parallel to the EXISTS clause (such as t1.b<10 in equation (7)). The combined predicate is logically equivalent to the original target filtering clause, ensuring that the query results are consistent.

[0091] Taking equation (7) as an example, the final generated connection statement is as follows: The transformation result when the target join method is semi-join is: WITH cte AS (SELECT DISTINCT id, TRUE AS exist FROM t2) SELECT t1.*FROM t1 LEFT SEMI JOIN cte ON t1.id IS NOT DISTINCT FROM cte.id WHERECOALESCE(cte.exist, FALSE) OR t1.b < 10 Formula (8) Since semi-connects have built-in deduplication properties, those skilled in the art can choose whether to delete the deduplication function in the target view according to actual needs, that is, delete the deduplication keyword DISTINCT.

[0092] The transformation result when the target join method is an outer join is: WITH cte AS (SELECT DISTINCT id, TRUE AS exist FROM t2) SELECT t1.* FROM t1 LEFT JOIN cte ON t1.id IS NOTDISTINCT FROM cte.id WHERE COALESCE(cte.exist, FALSE) OR t1.b < 10 Equation (9) This method fully restores the logic of the original EXISTS(...) OR t1.b<10 by combining predicates, and solves the problem of false positives in null value scenarios through the COALESCE function. Even if the join key of the target view after joining is NULL, as long as it is marked as TRUE (or the function returns TRUE), it is still considered to have a match. Furthermore, the transformed statement can make full use of efficient join algorithms such as hashjoin and mergejoin, avoiding the row-by-row probing of traditional subqueries, while the integration logic of the target view reduces the decision cost of the optimizer.

[0093] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0094] It should be understood that in some embodiments, the components may be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0095] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 4 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 5 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the database operation statement conversion method described above. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the database operation statement conversion method described above. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored in the memory 31 and running on the processor 32.

[0096] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0097] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0098] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0099] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0100] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0101] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for converting database operation statements, comprising: Obtain the database operation statement and determine whether there is a target filter clause in the database operation statement. The target filter clause contains both existence determination keywords and logical OR keywords. If the target filter clause exists in the database operation statement, extract the equality condition from the subquery of the target filter clause; Determine whether there is a null value equality judgment operation in the above equality conditions; If the null value equality judgment operation does not exist in the equality conditions, determine the target connection method supported by the target filtering clause; The database operation statement is converted into a connection statement that generates a connection result in one go, based on the target connection method.

2. The method for converting database operation statements according to claim 1, wherein, The target connection method includes external connections; When the target connection method is an outer join, the step of converting the database operation statement into a connection statement that generates a connection result in one go according to the target connection method includes: The main query table and subquery table in the target filtering clause are determined. The main query table is the main data source of the query results in the target filtering clause, and the subquery table is a data table used to support the main query table in making existence determinations. Determine the main query join key and subquery join key in the equality conditions, wherein the main query join key is the data column of the main query table that participates in the join, and the subquery join key is the data column of the subquery table that participates in the join; Create a deduplication clause for the subquery join key, and perform an outer join operation using the main query join key and the deduplication clause; Establish a non-empty filter condition for the subquery join key; The non-empty filtering condition and the filtering condition corresponding to the logical OR keyword are combined as a predicate and added to the conditional clause of the join statement.

3. The method for converting database operation statements according to claim 1, wherein, The target connection method includes a half-connection; When the target connection method is a half-connection, the step of converting the database operation statement into a connection statement that generates the connection result in one go includes: The main query table and subquery table in the target filtering clause are determined. The main query table is the main data source of the query results in the target filtering clause, and the subquery table is a data table used to support the main query table in making existence determinations. Determine the main query join key and subquery join key in the equality conditions, wherein the main query join key is the data column of the main query table that participates in the join, and the subquery join key is the data column of the subquery table that participates in the join; Perform a semi-join operation using the main query join key and the subquery join key; Establish a non-empty filter condition for the subquery join key; The non-empty filtering condition and the filtering condition corresponding to the logical OR keyword are combined as a predicate and added to the conditional clause of the join statement.

4. The method for converting database operation statements according to claim 1, wherein, The step of converting the database operation statement into a connection statement that generates a connection result in one go according to the target connection method includes: The main query table and subquery table in the target filtering clause are determined. The main query table is the main data source of the query results in the target filtering clause, and the subquery table is a data table used to support the main query table in making existence determinations. A deduplication view is created for the subquery table based on the filtering conditions of the subquery table, and the deduplication view is used to replace the subquery table in the target filtering clause. The deduplication view is used to filter the data columns involved in the judgment in the subquery table while adding the deduplication function. The main query table and the deduplicated view are connected according to the target connection method to obtain the connection statement; Establish non-empty filtering conditions for the deduplicated view; The non-empty filtering condition and the filtering condition corresponding to the logical OR keyword are added as predicates to the conditional clause of the join statement.

5. The method for converting database operation statements according to claim 1, wherein, Following the step of determining whether there is a null value equality judgment operation in the equality conditions, the method further includes: If the null value equality judgment operation exists in the equality conditions, determine the target connection method supported by the target filtering clause; The main query table and subquery table in the target filtering clause are determined. The main query table is the main data source of the query results in the target filtering clause, and the subquery table is a data table used to support the main query table in making existence determinations. A target view is created for the subquery table based on the filtering conditions of the subquery table, and the subquery table in the target filter clause is replaced with the target view. The target view is used to filter the data columns involved in the judgment in the subquery table and add a deduplication function, and add an existence flag to each filtering result. The existence flag is used to indicate that the data attribute of this row is true. The main query table and the target view are connected according to the target connection method to obtain the connection statement; A non-empty value retrieval function is constructed based on the target view. The non-empty value retrieval function is used to return true when there is data that meets the conditions in the target view, and to return false when there is no data that meets the conditions. Add the non-empty value function and the filtering conditions corresponding to the logical OR keyword as predicates to the conditional clause of the join statement.

6. The method for converting database operation statements according to claim 5, wherein, The non-empty value function includes: the COALESCE function; The COALESCE function contains two parameters: the first parameter is the presence marker in the target view, and the second parameter is false.

7. The method for converting database operation statements according to claim 1, wherein, The existence determination keywords include: EXISTS; The logical or keyword includes: OR; The equality conditions include single-column equality conditions or multi-column equality conditions: When the equality condition is a multi-column equality condition, the equality connection key in the equality condition is a multi-column combination connection key.

8. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the database operation statement conversion method according to any one of claims 1 to 7.

9. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method for converting database operation statements according to any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements the steps of the database operation statement conversion method according to any one of claims 1 to 7.

Images