Dynamic condition construction system based on custom annotation

Abstract

The invention discloses a dynamic condition construction system based on user-defined annotations, and aims to improve the flexibility and efficiency of query condition generation and execution. The system comprises a front-end module, a rear-end module, a condition constructor component, a database query module and a result return module. The front-end module receives a query condition input by a user and transmits the query condition to the back-end module, and the back-end module analyzes query parameters and adds custom annotations. And the condition constructor component generates a dynamic query condition based on the annotation, wherein the dynamic query condition comprises query information analysis, logic rule construction, SQL statement generation and dynamic parameter optimization. The database query module supports a plurality of database types and has query optimization and safety guarantee functions. And the result return module converts the query result into a structured data format and returns the structured data format to the front end. According to the method, efficient query condition construction, dynamic adjustment and optimization are achieved through modular design, the flexibility, accuracy and performance of the system are improved, and the method is widely suitable for data query requirements of complex service scenes.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, in particular to the field of database query optimization and dynamic condition construction technology, and in particular to a dynamic condition construction system based on user-defined annotations. Background Art

[0002] In the current practice of information system development, database conditional query is a key function to achieve data screening and dynamic display. However, the existing technology has exposed many deficiencies in the construction and execution of conditional query, which significantly affects the development efficiency, flexibility and maintainability of the system, and also puts forward higher requirements on performance.

[0003] Traditional conditional queries usually use static SQL construction, which requires developers to manually construct query conditions one by one according to the query parameters passed by the front end. Due to the complexity of conditional queries, developers often need to spend a lot of time writing and maintaining SQL code. When it is necessary to dynamically adjust query conditions or quickly respond to user-defined query requirements, the static SQL construction method is clumsy and inefficient. This method not only increases the complexity of development, but also easily introduces errors due to operational errors or missing details, further exacerbating the problem.

[0004] In actual development, the parameter processing process is often cumbersome. Conditional queries may involve multiple query types, such as equal value queries, range queries, and fuzzy queries. Developers need to write a lot of code to determine the validity of parameters and splice query logic based on these parameters. The existence of this redundant code not only increases maintenance costs, but also leads to a lack of unified rules when different developers implement similar functions, which ultimately leads to inconsistencies in SQL query logic within the system. This lack of standardized implementation further increases the development workload and increases the difficulty of project development and operation and maintenance.

[0005] The existing system also has obvious deficiencies in terms of dynamics. Usually, query conditions are hard-coded in the code logic, which makes it difficult for the system to dynamically adjust according to changes in the data environment or the actual needs of users. For example, in time range queries, many systems will fix the query range to a certain static interval. The limitations of this method may cause the query results to be out of touch with actual needs, and also limit the flexibility of the system. Conditional query methods that lack dynamic adjustment capabilities are difficult to cope with complex business needs.

[0006] Performance issues are also a major challenge facing current conditional query technology. In a large data volume environment, manually constructed SQL statements are usually not fully optimized, which leads to low query efficiency. At the same time, when the query conditions are not precise enough or there are redundant parameters, the database's computing resources may be wasted, further increasing the system load. This query method not only affects the user experience, but may also have a negative impact on the overall system performance.

[0007] It is also a common problem that many development frameworks lack uniformly encapsulated conditional query construction components. In different business scenarios, developers usually need to implement functional codes separately for each query logic, which leads to a large amount of duplication of functional codes. Especially in complex query scenarios, such as those involving multi-table association queries or nested conditional queries, the difficulty of implementing SQL logic increases significantly, and the probability of errors also increases. The lack of uniform encapsulation technology means that developers have to repeat work, increasing the development and testing costs of the system.

[0008] In addition, the difficulty of debugging and maintaining complex query logic also brings additional challenges to developers. It is difficult to intuitively track the query parameter transfer path and the actual SQL results during the debugging process of static SQL statements. When complex query conditions need to be adjusted, developers usually need to sort out the entire logic from scratch, which is time-consuming and laborious. Especially when facing combined queries with multiple conditions, the debugging workload often increases exponentially.

[0009] The current query implementation methods also have significant defects in intelligence. Most systems fail to fully utilize data statistics and analysis technologies to optimize query conditions. For example, the system cannot dynamically adjust the query range based on the distribution statistics of the field, resulting in a low hit rate of query results. The lack of intelligent condition adjustment means makes it impossible for the system to effectively improve the efficiency of data screening, which in turn affects the overall performance and user experience.

[0010] In summary, existing conditional query technologies have significant deficiencies in development efficiency, flexibility, performance, and maintainability. These problems have seriously restricted the functional expansion capabilities and usage effects of information systems in practical applications. An efficient, dynamic, and intelligent conditional construction method is urgently needed to address these technical pain points, thereby providing developers with a more flexible and efficient solution. Summary of the invention

[0011] In order to solve the above problems in the prior art, the present invention proposes a dynamic condition construction system based on custom annotations, the dynamic condition construction system comprising: a front-end module, a back-end module, a condition builder component, a database query module and a result return module;

[0012] The front-end module is used to receive the query parameters input by the user and transmit them to the back-end module;

[0013] The backend module is used to receive query parameters, encapsulate them into query objects, and add custom annotations containing query information to the query objects;

[0014] The condition builder component is used to generate dynamic query conditions based on the query object, including parsing query information, building logical rules, generating SQL statements, and dynamically adjusting query parameters;

[0015] The database query module is used to receive dynamic query conditions, execute database queries and return query results;

[0016] The result returning module is used to convert the query result returned by the database query module into a format recognizable by the front-end module, and return the converted result to the front-end module.

[0017] The front-end module comprises:

[0018] A user interaction interface, used to receive query conditions input by a user;

[0019] A formatting processing unit, used to convert the query conditions input by the user into a standardized query object;

[0020] Parameter verification unit, used to verify the validity of query conditions;

[0021] The data transmission unit is used to transmit the standardized query object to the backend module in the form of a request.

[0022] The back-end module comprises:

[0023] The parameter receiving module is used to receive the query parameters passed by the front end and parse them into a unified query object;

[0024] The annotation marking module is used to add custom annotations to the properties of the query object, and the annotations include query type, data type, operation type and sorting rules.

[0025] The condition builder component includes:

[0026] An annotation parsing unit, used to extract annotation information from the query object, wherein the annotation information includes query type, attribute data type, operation type and sorting type;

[0027] An SQL generation unit, used to generate dynamic SQL query conditions based on annotation information, including converting query conditions into SQL statement clauses and combining condition clauses to generate complete SQL query logic;

[0028] Field processing unit, used to process field identifiers, special symbols and parameter formats in SQL statements;

[0029] The logic assembly unit is used to combine multiple query condition clauses into a complete SQL query logic based on the annotation information in a logical relationship;

[0030] Dynamic parameter binding unit, used to optimize and bind query parameters, dynamically adjust query parameter ranges and filter invalid query conditions.

[0031] The dynamic parameter binding unit includes: dynamically adjusting the query parameter range, automatically optimizing the parameter range according to user input and data environment; detecting and filtering invalid query conditions, including empty parameters and logically invalid range conditions; and performing parameterized query by binding parameters with placeholders.

[0032] The formula for the dynamic parameter binding unit to adaptively adjust the query parameter range is:

[0033]

[0034] Among them, β and β are adjustable parameters, |S| is the absolute value of skewness, ∈ is the minimum constant; ∈ min is the lower limit of the actual value distribution range of the data field, α max is the upper limit of the actual value distribution range of the data field, M is the statistical median of the field, S is the skewness of the field distribution, and L ′ is the optimized lower limit, U ′ is the upper limit after optimization.

[0035] The database query module includes:

[0036] SQL parsing and adjustment unit, used to parse the received SQL statement and make adaptability adjustment according to the grammatical rules of the target database;

[0037] A database adapter unit, used to support multiple database types and select a suitable target database for query operations;

[0038] Query optimization unit, used to optimize query performance, including index utilization, paging strategy adjustment, and query structure optimization;

[0039] A query execution unit is used to execute SQL query operations and return query results;

[0040] Security unit, used to prevent SQL injection and verify user query permissions.

[0041] The result returning module comprises:

[0042] A data parsing unit, used to parse query results and verify data integrity;

[0043] A data conversion unit, used to convert query results into a structured data format and perform field mapping and data type conversion;

[0044] A paging processing unit, used to perform data segmentation and related metadata information encapsulation on paging query results;

[0045] The response generation unit is used to generate standardized response content according to the query results and pass it to the front-end module.

[0046] Beneficial effects:

[0047] The present invention realizes the standardized processing, dynamic adjustment and efficient execution of query conditions by combining custom annotations with a dynamic condition construction system. Through modular design, each functional unit has a clear division of labor, the front end supports flexible input and real-time verification, the back-end dynamic annotation and condition generation optimize the query logic, the database query module improves the compatibility and query performance of multiple database environments, and the result return module realizes the efficient transmission and display of structured data. The overall system improves the flexibility, accuracy and execution efficiency of queries, significantly reduces development and operation and maintenance costs, and enhances the scalability and user experience of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present application, but do not constitute an improper limitation of the present invention. In the drawings:

[0049] Figure 1 The schematic diagram of the structure of the dynamic conditional construction system based on custom annotations of the present invention is shown. DETAILED DESCRIPTION

[0050] The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments, wherein the illustrative embodiments and descriptions are only used to explain the present invention but are not intended to limit the present invention.

[0051] Figure 1 A structural diagram of a dynamic conditional construction system based on custom annotations is shown.

[0052] like Figure 1 As shown, this embodiment provides a dynamic condition construction system based on custom annotations. The system mainly includes the following modules: front-end module 1, back-end module 2, condition builder component 3, database query module 4 and result return module 5. These modules cooperate with each other to realize the construction and optimization functions of dynamic condition query.

[0053] The front-end module 1 is used to initiate a conditional query request and pass the query conditions as parameters to the back-end module 2. The user enters the query conditions, such as time range, keywords or data categories, through the front-end interface, and the front-end module formats these conditions into standardized parameters and passes them to the back-end.

[0054] The backend module 2 includes a parameter receiving module 21 and an annotation marking module 22 .

[0055] The parameter receiving module 21 is used to receive the query parameters from the front end and encapsulate them into a query object. The annotation marking module 22 is used to add custom annotations to the attributes of the query object, which mark the query type, data type, operation type and sorting rules of the attribute, providing a basis for subsequent condition construction.

[0056] The condition builder component 3 is the core part of the system, which is used to generate dynamic SQL query conditions based on the annotation information of the query object. This component specifically includes:

[0057] Annotation parsing unit 31: extracts annotation information in the query object, including query type, attribute data type, operation type and sorting type;

[0058] SQL generation unit 32: automatically parses query conditions according to annotation information and generates corresponding SQL statements;

[0059] Field processing unit 33: processes field identifiers, special symbols and parameter formatting to ensure that the generated SQL statement is compatible with the database;

[0060] Logic assembly unit 34: assembles operation logic (AND / OR) and sorting rules according to query requirements;

[0061] Dynamic parameter binding unit 35: implements dynamic parameter binding and implements the following functions:

[0062] 1. The user defines the variable range of the query parameter, such as dynamically adjusting the time interval;

[0063] 2. Automatically optimize parameter values ​​based on the current data environment, such as the data range of the last 7 days or 30 days;

[0064] 3. Adjust the query range based on dynamic data analysis (such as field distribution statistics);

[0065] 4. Automatically detect and ignore invalid query conditions (such as empty parameters) to improve system efficiency.

[0066] The database query module 4 receives the SQL statement generated by the condition builder component 3, executes the database query operation and returns the query result. This module supports multiple database types and has efficient query optimization function.

[0067] The result returning module 5 converts the query result returned by the database query module 4 into a format recognizable by the front end, and sends the result to the front end module 1 for the user to view.

[0068] This system uses modular design and custom annotations to achieve standardization and dynamic query logic, significantly reducing development workload while improving query performance and system scalability. The specific implementation plans for each module are as follows.

[0069] In this embodiment, the main function of the front-end module 1 is to initiate a conditional query request and pass the query condition as a parameter to the back-end module 2 .

[0070] The front-end module provides a user interface for users to enter query conditions. The user interface includes components such as input boxes, drop-down menus, radio buttons, multiple-choice buttons, and time selectors. For example, users can enter the start time and end time through the time selector, enter keywords through the input box, and select data categories (such as "project status" or "release status") through the drop-down menu. The above components are designed according to query requirements and support flexible combinations of multiple query conditions.

[0071] When the user completes the condition input, the front-end module formats the input query conditions. The core of formatting is to convert the diverse data entered by the user into standardized query objects to ensure that the back-end can accurately identify and process these conditions. The content of formatting includes:

[0072] The front-end module converts the data entered by the user in a unified manner. For example, the time range selected by the user is formatted into a "start time" and "end time" structure, and keywords and data categories are directly mapped to standard fields.

[0073] To improve the accuracy and robustness of the system, the front-end module verifies the parameters entered by the user. For example, it checks whether the start time in the time range is earlier than the end time, ensures that the keyword input is not empty and meets the system's character length restrictions, and verifies whether the selected data category is within the allowed range. If an input error is found, the front-end module prompts the user to make changes in real time through the interface feedback mechanism.

[0074] After the parameter verification is completed, the front-end module encapsulates the query conditions in a standardized format as a request body. In order to ensure the integrity of the data and the security of the transmission, the front-end module sends a request to the back-end module through the HTTP protocol, specifically using the POST method to pass the query parameters. The request includes all the necessary information of the query conditions to ensure that the back-end can accurately parse and process user needs.

[0075] In addition, the front-end module has an error prompt mechanism to enhance the user experience. If the parameter verification fails, the system will prompt the user to input the problem through interface feedback, for example, by marking the wrong input area with a red mark, or displaying specific error prompt information (such as "the start time cannot be later than the end time"). At the same time, before the user corrects the error, the front-end module will disable the "query" button to prevent invalid requests from being sent.

[0076] The front-end module also supports dynamic adjustment of the displayed content of the interface according to the conditions entered by the user. For example, when the user selects a data category, the front-end module will dynamically load the corresponding query options according to the specific needs of the category, providing users with a more intuitive and convenient operation method. Through this dynamic adjustment, the front-end module can adapt to the diverse query needs in complex business scenarios.

[0077] Through the above technical means, the front-end module can not only efficiently receive the user's query conditions, but also ensure the integrity and accuracy of the data, providing a reliable foundation for subsequent back-end processing. At the same time, through a flexible user interaction interface and dynamic adjustment mechanism, the module significantly improves the user experience and the intelligent level of system interaction.

[0078] In this embodiment, the function of the backend module 2 is to receive the query parameters transmitted by the frontend and provide support for subsequent condition construction. The backend module 2 includes a parameter receiving module 21 and an annotation marking module 22. The specific implementation is as follows:

[0079] The parameter receiving module 21 is responsible for receiving the query parameters from the front end and encapsulating them into a unified query object. The implementation of receiving the query parameters includes the following steps:

[0080] The backend module obtains the query conditions by receiving the data packet in the HTTP request. The data packet is usually in JSON format and contains the query conditions passed by the frontend, such as time range, keywords, data categories, etc. The parameter receiving module can identify and parse the data packet and extract all key fields and their corresponding values.

[0081] The parameter receiving module converts the parsed query condition data into the corresponding attributes of the query object. For example, for a time range query condition, the module maps the start time and end time to the startTime and endTime attributes of the query object respectively. This conversion process ensures that the query condition can be standardized and provides a consistent structure for subsequent steps.

[0082] The parameter receiving module has a built-in parameter integrity and data validity check mechanism. During the parsing and conversion process, if a parameter is missing, does not conform to the expected format, or has an illegal value, the module will generate an error response and feedback to the front end through a predefined error code and prompt information. For example, when the time range format is incorrect, the module will return an error prompt such as "The time range parameter format is invalid."

[0083] Through the parameter receiving module 21, the query condition data is effectively parsed and encapsulated into a unified query object, providing a basic data structure for subsequent annotation marking.

[0084] The function of the annotation marking module 22 is to add custom annotations to the properties of the query object to provide guidance for subsequent condition construction and SQL generation. Its specific technical implementation is as follows:

[0085] The annotation marking module 22 uses a custom annotation mechanism to add specific metadata to the properties of the query object. The annotation contains information such as query type (such as equality query, greater than query, less than query, etc.), data type (such as string, date, integer, etc.), operation type (such as AND operation, OR operation) and sorting rule (such as ascending, descending). Annotations are loaded into query object properties through static configuration or dynamic rules. For example, when the query condition involves fuzzy query, the module will add @QueryType (QueryTypeEnum.LI KE) annotation to the corresponding attribute.

[0086] The annotation tag module 22 supports dynamic annotation configuration. According to the query condition type and business requirements passed by the front end, the module can dynamically adjust the configuration content of the annotation at runtime. For example:

[0087] When the time field of the query object needs to be sorted in descending order, the module will automatically add a sort annotation to the field and specify the sorting rule as descending.

[0088] For range queries, the module can dynamically set the query type to "greater than" and other types based on the boundary value provided by the front end.

[0089] The annotation marking module can persist the marked query objects as intermediate data for use by subsequent condition builder components. This design enables the reuse of annotations and avoids the performance consumption caused by repeated marking.

[0090] Through the annotation marking module 22, each attribute of the query object is given a clear query rule, providing accurate guidance information for subsequent SQL generation. The flexible configuration and dynamic adaptability of the module ensure that the system can efficiently handle diverse query requirements.

[0091] Through the above technical means, the back-end module 2 effectively completes the entire process from parameter reception to annotation marking, provides basic guarantees for dynamic condition construction, and has the characteristics of high efficiency, accuracy and flexibility.

[0092] The condition builder component 3 is the core part of the system. Its function is to generate dynamic SQL query conditions according to the annotation information of the query object to meet the flexible and efficient query requirements. The component includes an annotation parsing unit 31, an SQL generation unit 32, a field processing unit 33, a logic assembly unit 34 and a dynamic parameter binding unit 35. The specific implementation is as follows:

[0093] The function of the annotation parsing unit 31 is to extract annotation information from the query object, including query type, attribute data type, operation type and sorting type, etc., to provide basic data support for subsequent SQL generation. Its implementation includes the following steps:

[0094] The annotation parsing unit scans the fields of the query object one by one through the reflection mechanism, identifies and extracts the annotation information defined on each field. Each annotation contains detailed metadata, such as the query type, attribute data type, sorting rules, and logical operation methods. For example, if the annotation definition of a field is an equal value query, the unit will extract the query type as "equal value query" and the attribute data type as "string", and mark the field as requiring equal value matching.

[0095] After annotation extraction is completed, the annotation parsing unit verifies the validity of the extracted information to ensure that all annotation information is configured reasonably. For example:

[0096] Check whether the sort type is consistent with the data type of the field. For example, a string type field cannot be defined as a numeric sort.

[0097] Verify whether the query type is within the supported range, such as equal query, greater than query, fuzzy query, etc.

[0098] Verify whether the logical operation of the field meets the context requirements to avoid subsequent SQL generation errors caused by illegal annotation configuration.

[0099] Through the verification steps, the annotation parsing unit can effectively filter out misconfigured or unreasonable annotation information to ensure that the generated SQL conditions are correct and reliable.

[0100] To improve system efficiency, the annotation parsing unit will cache the successfully extracted and verified annotation information into memory to avoid repeated parsing of the same query object. The caching mechanism not only reduces the consumption of system resources, but also improves the overall performance in large-volume conditional query scenarios.

[0101] The SQL generation unit 32 automatically generates the corresponding SQL query statement based on the information extracted by the annotation parsing unit, and is one of the core modules of the condition builder component. Its specific implementation is as follows:

[0102] According to the query type defined in the annotation, the SQL generation unit converts the query conditions into clauses of standard SQL statements. For example:

[0103] For fuzzy search conditions, convert them into LI KE '%keyword%';

[0104] For range query conditions, convert them into BETWEEN start value AND end value;

[0105] For equal value query conditions, convert them to = value.

[0106] During the condition translation process, the SQL generation unit combines the data type and annotation definition of the field to ensure that the generated clause is compatible with the database syntax.

[0107] For a query object containing multiple query conditions, the SQL generation unit will combine the conditional clauses into a complete SQL WHERE clause. The combination method depends on the operation logic guidance of the logic assembly unit, such as using AND or OR to connect the conditions and arranging them according to the defined priority.

[0108] The SQL generation unit can perform conditional filling based on pre-defined SQL templates to generate structured SQL query statements. This method enhances the standardization and maintainability of statements while reducing repetitive code.

[0109] The main function of the field processing unit 33 is to process the field identifiers, special symbols and parameter formats in the generated SQL statement to ensure the correct execution of the statement in the target database. Its specific implementation includes the following contents:

[0110] If the field name contains database reserved words or special characters (such as spaces, hyphens, etc.), the field processing unit will automatically add appropriate identifiers (such as backticks or double quotes) to ensure the legitimacy of the field name. For example, the field order is processed as "order" to avoid syntax errors caused by conflicts between the field and database reserved words.

[0111] For string-type query values ​​entered by users, the field processing unit will escape special symbols (such as single quotes, slashes, etc.) that may cause SQL injection to improve the security of SQL queries. For example, the user-entered 'keyword' is processed as "keyword" to prevent SQL injection attacks.

[0112] The field processing unit formats the parameters according to the data type of the field and the requirements of the target database. For example:

[0113] Date type parameters are formatted in the standard date format of 'YYYY-MM-DD';

[0114] Numeric type parameters are handled appropriately according to the accuracy requirements;

[0115] The formatting step ensures that the generated SQL statements can be seamlessly integrated with the target database.

[0116] The logic assembly unit 34 is used to combine the conditional clauses into a complete SQL query logic in a logical relationship (such as AND or OR) according to the annotation information, and is specifically implemented as follows:

[0117] According to the operation type defined in the annotation, the logic assembly unit combines the conditional clauses according to the specified logical relationship. For example:

[0118] When the annotation defines that multiple fields need to meet the conditions at the same time, the logic in the format of condition 1 AND condition 2 is generated;

[0119] When the annotation defines certain field conditions as optional relationships, the generated logic is in the format of condition 1 OR condition 2.

[0120] When multiple layers of nested logic are involved, the logic assembly unit will set clear priorities through brackets based on annotation information and logic priority rules. For example, for the logical expression condition 1 AND (condition 2 OR condition 3), the setting of brackets ensures the priority operation relationship between condition 2 and condition 3, thereby avoiding logical ambiguity.

[0121] The main function of the dynamic parameter binding unit 35 is to optimize the query parameters through intelligent adjustment and dynamic binding mechanism to meet the diverse needs in complex business scenarios. The specific implementation is as follows:

[0122] The dynamic parameter binding unit 35 supports the user to define the variable range of the query parameter and dynamically adjust the range value according to the demand. For example:

[0123] In the time range query scenario, if the user does not explicitly specify the start time and end time, the unit will automatically set a default value, such as the data range of the last 7 days or 30 days, to ensure the completeness of the query conditions and avoid missing data.

[0124] In numeric range queries, the unit can dynamically fill in the missing parts based on the default configuration or partial values ​​entered by the user. For example, if the user only provides an upper limit value, the system will automatically infer or set a reasonable lower limit value to construct the complete range.

[0125] This adjustment mechanism improves the flexibility of query parameters, allowing the system to better adapt to changes in user needs and business scenarios.

[0126] The dynamic parameter binding unit 35 dynamically optimizes the query parameter value by combining the current data environment. Its main technologies include:

[0127] Data distribution analysis: The unit performs statistical analysis on the target data field, such as obtaining the distribution range, median, average, and other information of the field value. Based on the analysis results, the unit can dynamically adjust the query condition range. For example, if the main data of a time field is concentrated in the past 30 days, the system can prioritize the query range to the last 30 days to improve the hit rate.

[0128] Dynamic adjustment rules: Based on data characteristics and historical query behavior, the unit can generate optimization rules. The specific rules are dynamically adjusted according to the following formula: The formula is as follows:

[0129]

[0130] in:

[0131] L, U: The lower and upper limits of the original query range, representing the initial range, where L is the lower limit and U is the upper limit; ∈ min ,D max : The lower and upper limits of the actual value distribution range of the data field, indicating the boundaries of the real data.

[0132] M: The median of the data distribution, which represents the middle of the data. Compared with the mean, the median is less affected by outliers and is therefore suitable as a reference point for range adjustment.

[0133] S: The skewness of the data distribution, which measures the symmetry of the data distribution:

[0134] S>0: the distribution is right-skewed (longer tail).

[0135] S<0: the distribution is left-skewed (shorter tail).

[0136] S=0: distribution is symmetrical.

[0137] α, β: adjustable parameters that control the extent of the lower and upper limits. The larger the value, the wider the expansion range, which is suitable for scenarios that require greater query coverage.

[0138] ∈: minimum constant, usually a very small positive number (such as 10 -6 ). Its function is to prevent the denominator from being zero when S=0, and it will not significantly affect the calculation result.

[0139] |S|: The absolute value of the skewness, which is used to quantify the size of the skewness and avoid directly using negative values ​​to interfere with the calculation.

[0140] S / |S|: The direction of the skewness, with a value of +1 or -1. It is used to dynamically adjust the range to the left or right.

[0141] L ′ : The optimized lower limit, U ′ : The optimized upper limit.

[0142] The above formula combines the distribution characteristics, skewness direction, and upper and lower bounds of the data. By adjusting α and β, the range can be adaptively expanded or contracted, thereby optimizing the coverage effect of the query range and improving the query hit rate.

[0143] The dynamic parameter binding unit 35 has the ability to automatically detect and filter invalid conditions, specifically including:

[0144] Empty parameter detection: When the user does not enter certain optional parameters or enters an empty value, the unit will automatically ignore the condition. For example, if the query keyword is empty or the time range is not specified, the system will automatically exclude these conditions to avoid generating meaningless SQL clauses.

[0145] Logical invalidity judgment: For range queries, the unit will check the logical rationality of the upper and lower limits. For example, if the start time of the time interval is later than the end time or the lower limit of the value range is greater than the upper limit, the unit will automatically ignore the condition or prompt the user to modify the input.

[0146] By filtering invalid conditions, the system effectively reduces meaningless queries and improves the efficiency of database resource utilization.

[0147] The dynamic parameter binding unit 35 implements dynamic binding of conditional values ​​through parameterized query, avoiding hard-coded parameters and improving security and flexibility. Its implementation includes:

[0148] Parameter placeholder usage: The unit uses placeholders (such as? or named parameters:{param}) instead of directly embedded values ​​when generating SQL statements. Placeholders are dynamically replaced by parameter values ​​when the query is executed, thus avoiding the risk of SQL injection.

[0149] Multi-type parameter support: The unit can handle parameters of multiple data types, including strings, numbers, dates, etc. During dynamic binding, the unit automatically converts the format according to the data type. For example, string parameters are automatically quoted, and date parameters are formatted in the standard form supported by the database.

[0150] Batch binding optimization: For batch query scenarios, the unit supports a batch binding mechanism for parameter values. For example, in an IN condition query, the unit can dynamically generate a parameter list and bind it to the SQL statement, thereby improving the execution efficiency of batch queries.

[0151] Through the above implementation, the dynamic parameter binding unit 35 realizes the intelligent adjustment and dynamic binding of query parameters, which not only improves the flexibility and security of the system, but also significantly optimizes the query efficiency. Through the specific dynamic parameter adjustment formula, the adaptive ability to data distribution characteristics is further enhanced, providing a creative and efficient solution for diversified business needs.

[0152] The function of the database query module 4 is to receive the SQL statement generated by the condition builder component 3, execute the database query operation and return the query result. In order to ensure the efficiency and accuracy of the query, the module supports multiple database types and has an efficient query optimization function. The specific implementation method is as follows:

[0153] The database query module 4 receives the generated SQL statement from the condition builder component 3 and performs necessary analysis and preprocessing on it.

[0154] Statement verification: The module performs syntax checks on received SQL statements to ensure that the statements conform to the specifications of the target database. For example, it checks whether the keyword spelling, table name, and field name in the SQL statement are correct.

[0155] Statement adjustment: For the specific syntax differences of different database systems (such as MySQL, PostgreSQL, Oracle, etc.), the module will make adaptive adjustments to SQL statements. For example, the LIMIT keyword in MySQL is converted to the ROWNUM mechanism in Oracle.

[0156] The database query module 4 supports a variety of mainstream database types, can automatically select the target database according to the configuration, and optimize the SQL statement.

[0157] Multi-database driver adaptation: The module is pre-configured to support multiple database connection drivers (such as JDBC, ODBC, etc.) and can flexibly adapt to different database systems.

[0158] Automatic switching: When the system is deployed in a multi-database environment, the module can automatically select the most suitable database for querying based on the query content, data distribution or load conditions. For example, when the query mainly involves time series data, databases that support time series optimization are preferred.

[0159] The database query module 4 has a query optimization function to improve query performance and reduce resource consumption. Specific optimization measures include:

[0160] Index Utilization: Before executing a query, the module uses query analysis to detect whether the target table has a suitable index. If there is no index or the index is not suitable for the query conditions, the module can generate suggestions for administrators to optimize the database structure.

[0161] Paging optimization: For queries that contain paging logic, the module will automatically adjust the paging strategy. For example, in large data volume queries, the database's native paging support (such as MySQL's LIMIT keyword) is used first to reduce the amount of data transferred.

[0162] Query plan analysis: The module analyzes the execution path of the query statement through the query plan function of the database (such as EXPLAIN or EXPLAIN ANALYZE command). If a performance bottleneck is found in the query, the module will automatically adjust the query structure, such as optimizing nested queries or decomposing complex logic.

[0163] The database query module 4 supports high-concurrency queries and has a load balancing function to ensure stable query performance in multi-user scenarios.

[0164] Connection pool management: The module manages database connections through a database connection pool (such as Hikar iCP or DBCP), supporting efficient connection reuse to reduce the overhead of frequent connection establishment.

[0165] Query queue optimization: The module has a built-in query queue management mechanism, which sorts and executes query tasks according to priority to ensure that key queries return results first.

[0166] Load distribution: In a multi-database instance deployment environment, the module supports distributing query tasks to idle database instances through a load balancer to balance system pressure.

[0167] After the query is completed, the database query module 4 processes the result and returns it to the caller.

[0168] Result formatting: The module formats the original query results into a unified structured data format (such as JSON or XML) to facilitate parsing and display by the front-end module 1.

[0169] Exception handling: When a query fails or the result is empty, the module generates detailed error information (such as SQL error code and description) and returns it to the caller through the interface for subsequent processing.

[0170] Incremental update support: For scenarios that require continuous query, the module supports incremental query function, returning only new or changed data to reduce network transmission.

[0171] The database query module 4 strictly follows security specifications when executing queries to prevent security threats such as SQL injection.

[0172] Parameterized query support: The module only accepts parameterized SQL statements, and all query parameters are bound through placeholders to avoid SQL injection risks.

[0173] Permission verification: The module verifies query permissions based on user identity and role to ensure that query operations comply with permission control policies. For example, ordinary users cannot access sensitive data tables.

[0174] Through the above implementation, the database query module 4 can efficiently and safely perform a variety of database query operations, and return query results in a highly adaptable and high-performance manner, providing solid support for the overall function of the system. The multi-database compatibility and optimization functions of the module ensure that it can meet the needs of diverse application scenarios.

[0175] The function of the result return module 5 is to process the query results returned by the database query module 4 into a standard format recognizable by the front-end module 1, and send the processed results to the front-end module 1 for the user to view. The specific technical implementation of this module includes the following:

[0176] The result returning module 5 receives the query result from the database query module 4, and parses and pre-processes the result to ensure the integrity and validity of the data.

[0177] The module performs integrity checks on query results to ensure that the returned data contains necessary fields and that there is no missing data.

[0178] For multi-line query results, the module parses each line one by one to ensure that each record can be correctly included in the subsequent data processing flow.

[0179] To ensure that the front-end module 1 can correctly parse and display the data, the result returning module 5 converts the original query results into a unified structured data format.

[0180] The module converts the raw data into a standardized structure format, such as JSON or XML, according to system requirements to adapt to the parsing capabilities of the front-end module.

[0181] The module supports field mapping, which converts the field names returned by the database into front-end friendly names. For example, the field name user_id in the database is mapped to the user ID displayed on the front-end.

[0182] Data type conversion is processed as needed, for example, converting timestamp type data into ISO 8601 standard format time, or formatting numeric type data into a display format with a currency symbol.

[0183] For query results with paging, the result returning module 5 processes and encapsulates the paging data.

[0184] When the module returns paginated data, it is accompanied by relevant metadata information, such as the total number of records, the current page number, the number of records per page, etc., so that the front-end module 1 can fully display the pagination information.

[0185] The module only returns the data content of the current page, ensuring efficient transmission of paging results and complete data structure.

[0186] The result returning module 5 can generate corresponding status information according to the query result or abnormal situation in the query process and encapsulate and return it.

[0187] When the query result is empty, the module returns status information indicating that the query result is empty, with accompanying prompt information for reference by the front-end module 1.

[0188] If an error occurs during a query, such as a database query failure or a syntax error, the module encapsulates the error information into a standardized response content, including an error code, error description, and detailed information.

[0189] In order to improve data transmission efficiency, the result returning module 5 compresses and optimizes the query results.

[0190] The module supports compression of large data volumes, for example, using a compression algorithm to compress the results before transmission to reduce bandwidth usage.

[0191] In continuous query scenarios, the module supports incremental transmission and only returns new or changed data, thereby reducing the redundancy of network transmission.

[0192] After completing the data processing, the result returning module 5 returns the response data to the front-end module 1 through a predefined interface.

[0193] The module supports synchronous or asynchronous response mode and selects the appropriate transmission mode according to the request characteristics of the front-end module 1.

[0194] All response data follows a unified structural standard to ensure that the front-end module 1 can quickly parse and present, such as a complete response structure with status code, metadata information, and data content.

[0195] Through the above implementation, the result return module 5 realizes the efficient conversion and transmission of the database query results into a front-end friendly format, ensures the integrity and accuracy of the data, and improves the efficiency of data transmission and the user experience of the system.

[0196] The above description is only a preferred embodiment of the present invention, so all equivalent changes or modifications made according to the structure, characteristics and principles described in the scope of the patent application of the present invention are included in the scope of the patent application of the present invention.

Claims

1. A dynamic conditional construction system based on custom annotations, characterized by: The dynamic condition construction system includes: a front-end module, a back-end module, a condition builder component, a database query module and a result return module; The front-end module is used to receive the query parameters input by the user and transmit them to the back-end module; The backend module is used to receive query parameters, encapsulate them into query objects, and add custom annotations containing query information to the query objects; The condition builder component is used to generate dynamic query conditions based on the query object, including parsing query information, building logical rules, generating SQL statements, and dynamically adjusting query parameters; The database query module is used to receive dynamic query conditions, execute database queries and return query results; The result returning module is used to convert the query result returned by the database query module into a format recognizable by the front-end module, and return the converted result to the front-end module.

2. A dynamic conditional construction system based on custom annotations as described in claim 1, characterized in that: The front-end module comprises: A user interaction interface, used to receive query conditions input by a user; A formatting processing unit, used to convert the query conditions input by the user into a standardized query object; Parameter verification unit, used to verify the validity of query conditions; The data transmission unit is used to transmit the standardized query object to the backend module in the form of a request.

3. A dynamic conditional construction system based on custom annotations as described in claim 1, characterized in that: The back-end module comprises: The parameter receiving module is used to receive the query parameters passed by the front end and parse them into a unified query object; The annotation marking module is used to add custom annotations to the properties of the query object, and the annotations include query type, data type, operation type and sorting rules.

4. A dynamic conditional construction system based on custom annotations as claimed in claim 1, characterized in that: The condition builder component includes: An annotation parsing unit, used to extract annotation information from the query object, wherein the annotation information includes query type, attribute data type, operation type and sorting type; An SQL generation unit, used to generate dynamic SQL query conditions based on annotation information, including converting query conditions into SQL statement clauses and combining condition clauses to generate complete SQL query logic; Field processing unit, used to process field identifiers, special symbols and parameter formats in SQL statements; The logic assembly unit is used to combine multiple query condition clauses into a complete SQL query logic based on the annotation information in a logical relationship; Dynamic parameter binding unit, used to optimize and bind query parameters, dynamically adjust query parameter ranges and filter invalid query conditions.

5. A dynamic conditional construction system based on custom annotations as claimed in claim 1, characterized in that: The dynamic parameter binding unit includes: dynamically adjusting the query parameter range, automatically optimizing the parameter range according to user input and data environment; detecting and filtering invalid query conditions, including empty parameters and logically invalid range conditions; and performing parameterized query by binding parameters with placeholders.

6. A dynamic conditional construction system based on custom annotations as claimed in claim 4 or 5, characterized in that: The formula for the dynamic parameter binding unit to adaptively adjust the query parameter range is: Among them, α and β are adjustable parameters, |S| is the absolute value of skewness, ∈ is the minimum constant; D min is the lower limit of the actual value distribution range of the data field, D max is the upper limit of the actual value distribution range of the data field, M is the statistical median of the field, S is the skewness of the field distribution, and L ′ is the optimized lower limit, U ′ is the upper limit after optimization.

7. A dynamic conditional construction system based on custom annotations as claimed in claim 1, characterized in that: The database query module includes: SQL parsing and adjustment unit, used to parse the received SQL statement and make adaptability adjustment according to the grammatical rules of the target database; A database adapter unit, used to support multiple database types and select a suitable target database for query operations; Query optimization unit, used to optimize query performance, including index utilization, paging strategy adjustment, and query structure optimization; A query execution unit is used to execute SQL query operations and return query results; Security unit, used to prevent SQL injection and verify user query permissions.

8. A dynamic conditional construction system based on custom annotations as claimed in claim 1, characterized in that: The result returning module comprises: A data parsing unit, used to parse query results and verify data integrity; A data conversion unit, used to convert query results into a structured data format and perform field mapping and data type conversion; A paging processing unit, used to perform data segmentation and related metadata information encapsulation on paging query results; The response generation unit is used to generate standardized response content according to the query results and pass it to the front-end module.

Images