Flexible and universal sorting adjustment method and implementation system thereof

Abstract

The invention discloses a flexible and universal sorting adjustment method and an implementation system thereof. The method comprises the following steps: receiving a dynamic parameter set at least comprising a record screening condition, an original sorting value and a target sorting value; according to a comparison result of the original sorting value and the target sorting value, a sorting value batch adjustment strategy is generated in combination with a record screening condition; constructing a dynamic structured query statement based on a sequencing value batch adjustment strategy, wherein statement limitation only performs sequencing value updating on records which meet the record screening condition and have sequencing values located in a specified value interval; and executing the dynamic structured query statement to complete batch record sorting value adjustment, and updating the currently recorded sorting value to the target sorting value. By utilizing the embodiment of the invention, the efficiency and reliability of data maintenance can be improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data processing, in particular to a flexible and universal sorting adjustment method and an implementation system thereof. BACKGROUND

[0002] In various software applications and database management systems, sorting data records is a basic and frequent operation. Traditional sorting adjustment methods, such as directly updating the sorting field of a single record, have significant limitations when facing scenarios that require batch and ordered movement of record sequences (for example, inserting a new record in the middle of a list or moving a record from the end to the top). The existing technology usually needs to use complex loop logic or execute multiple SQL statements to first release or occupy the sorting position line by line, and then update the target record. This method not only has redundant code and low execution efficiency, but also easily causes sorting value conflicts in concurrent operations, leading to data inconsistency. In addition, the hard-coded implementation method lacks flexibility and is difficult to adapt to dynamic and changing data adjustment requirements, increasing the maintenance cost and error risk of the system. SUMMARY

[0003] The purpose of the present application is to provide a flexible and universal sorting adjustment method and an implementation system thereof to solve the problems in the prior art and improve the efficiency and reliability of data maintenance.

[0004] One embodiment of the present application provides a flexible and universal sorting adjustment method, which comprises: receiving a dynamic parameter set containing at least a record filtering condition, an original sorting value and a target sorting value; generating a sorting value batch adjustment strategy according to the comparison result of the original sorting value and the target sorting value, in combination with the record filtering condition, the strategy containing a unified increment or decrement operation on the sorting value of the records in a specified value interval; constructing a dynamic structured query statement based on the sorting value batch adjustment strategy, the statement limiting the sorting value update to only the records that meet the record filtering condition and have sorting values in the specified value interval; executing the dynamic structured query statement to complete the batch record sorting value adjustment, and updating the sorting value of the current record to the target sorting value.

[0005] Optionally, the receiving of the dynamic parameter set containing at least the record filtering condition, the original sorting value and the target sorting value comprises: receiving the target data table name, the sorting field name, the record filtering condition, the original sorting value and the target sorting value provided by the user through a parameter input interface, and generating an original parameter set; The original parameter set is format checked to verify whether the target data table name and the sorting field name conform to the database identifier specification, whether the record filtering condition is a legal SQL expression, whether the original sorting value and the target sorting value are valid integer values or null values, and a parameter set that passes the verification is generated; Based on the parameter set that passes the verification, field references and value types in the record filtering condition are parsed to eliminate potential security risks and optimize the condition expression structure, and a security-optimized condition expression is generated; The security-optimized condition expression is standardized assembled with the target data table name, the sorting field name, the original sorting value, and the target sorting value to generate a standardized dynamic parameter set.

[0006] Optionally, a sorting value batch adjustment strategy is generated according to the comparison result of the original sorting value and the target sorting value in combination with the record filtering condition, and the strategy includes uniformly increasing or decreasing the sorting values of records in a specified numerical interval, including: The original sorting value and the target sorting value are extracted from the standardized dynamic parameter set for numerical comparison and null value judgment to generate a sorting value relationship analysis result; Based on the sorting value relationship analysis result, in combination with the security-optimized condition expression, the specific scenario of sorting adjustment is determined, and the scenario includes the new record scenario, the ascending adjustment scenario, or the descending adjustment scenario, and a sorting adjustment scenario definition is generated; According to the sorting adjustment scenario definition, the sorting value interval boundary that needs to be adjusted is calculated, and the interval opening and closing characteristics are clarified to generate a target numerical interval specification; According to the target numerical interval specification and the sorting adjustment scenario definition, a specific sorting value adjustment operation scheme is developed, and the scheme includes the amplitude and direction of the increment or decrement, and a sorting value batch adjustment strategy is generated.

[0007] Optionally, a dynamic structured query statement is constructed based on the sorting value batch adjustment strategy, and the statement limits the sorting value update to only records that meet the record filtering condition and have sorting values in a specified numerical interval, including: The target numerical interval specification and the adjustment operation scheme are extracted from the sorting value batch adjustment strategy, and the target data table name and the sorting field name in the standardized dynamic parameter set are combined to construct a basic update statement structure; The security-optimized condition expression is integrated into the basic update statement structure to form a condition-limited update statement framework, ensuring that only records that meet the condition are operated on; According to the adjustment operation scheme, a sorting field update expression is added to the condition-limited update statement framework to clarify the increment or decrement operation logic, and a complete update statement template is generated; The parameter binding and statement optimization processing are performed on the complete update statement template, the SQL injection vulnerability is eliminated, the query efficiency is improved, and a safe and optimized dynamic structured query statement is generated.

[0008] Optionally, the executing the dynamic structured query statement completes the batch record sorting value adjustment, and the sorting value of the current record is updated to the target sorting value, including: The database connection is established, and the safe and optimized dynamic structured query statement is precompiled, syntax checking and execution plan optimization are performed, and an executable SQL statement is generated; The executable SQL statement is executed, and the records meeting the conditions and having the sorting value in the target numerical interval are subjected to batch update operation, and a batch update execution result is generated; The current record update statement is constructed based on the standardized dynamic parameter set, the sorting value of the specific record is accurately updated to the target sorting value, and the current record update statement is generated; The current record update statement is executed, and the continuity and uniqueness of the full table sorting value are verified, the sorting sequence is ensured to be completely reconstructed, and a sorting adjustment completion report is generated.

[0009] Optionally, the original sorting value and the target sorting value are extracted from the standardized dynamic parameter set, numerical comparison and null value judgment are performed, and a sorting value relationship analysis result is generated, including: The specific numerical values of the original sorting value and the target sorting value are parsed and extracted from the standardized dynamic parameter set, and a numerical value pair of the original sorting value and the target sorting value is generated; The numerical value pair of the original sorting value and the target sorting value is subjected to null value detection, whether the original sorting value is a null value is judged, and a null value detection result is generated; Based on the null value detection result, if the original sorting value is not empty, the numerical size comparison is performed, the difference value between the target sorting value and the original sorting value is calculated, and a numerical comparison result is generated; The null value detection result and the numerical comparison result are integrated, the sorting value relationship type is defined, the types include new record, ascending adjustment, descending adjustment or no adjustment, and finally the sorting value relationship analysis result is generated.

[0010] Another embodiment of the application provides a flexible and general sorting adjustment implementation system, which comprises: The receiving module is configured to receive a dynamic parameter set containing at least a record filtering condition, an original sorting value and a target sorting value; The generating module is configured to generate a sorting value batch adjustment strategy according to the comparison result of the original sorting value and the target sorting value, and in combination with the record filtering condition, the strategy containing uniform increment or decrement operation on the sorting value of the records in a specified numerical interval; The construction module is used to construct a dynamic structured query statement based on the batch adjustment strategy of the sort value. The statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is within a specified value range. The adjustment module is used to execute the dynamic structured query statement to complete the batch record sorting value adjustment and update the sorting value of the current record to the target sorting value.

[0011] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0012] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0013] Compared with existing technologies, this invention provides a flexible and universal sorting adjustment method. It receives a dynamic parameter set including at least record filtering conditions, original sorting values, and target sorting values; generates a batch sorting value adjustment strategy based on the comparison results of the original and target sorting values, combined with the record filtering conditions; constructs a dynamic structured query statement based on the batch sorting value adjustment strategy, limiting the sorting value update to records that meet the record filtering conditions and whose sorting values ​​are within a specified numerical range; executes the dynamic structured query statement to complete the batch record sorting value adjustment, and updates the sorting value of the current record to the target sorting value, thereby improving the efficiency and reliability of data maintenance. Attached Figure Description

[0014] Figure 1 A hardware structure block diagram of a computer terminal for a flexible and universal sorting adjustment method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a flexible and universal sorting adjustment method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a flexible and universal sorting adjustment system provided in an embodiment of the present invention. Detailed Implementation

[0015] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0016] The present invention first provides a flexible and universal sorting adjustment method, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0017] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal providing a flexible and universal sorting adjustment method according to an embodiment of the present invention. (See diagram below.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0018] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any flexible and general-purpose sorting method.

[0019] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0020] Internal memory provides an environment for the execution of computer programs stored in non-volatile storage media. When these computer programs are executed by a processor, the processor can perform any flexible and general sorting and reordering method.

[0021] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0022] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0023] See Figure 2 The embodiments of the present invention provide a flexible and universal sorting adjustment method, which may include the following steps: S201, receive a dynamic parameter set that includes at least record filtering conditions, original sort values ​​and target sort values; Specifically, the parameter input interface can receive the target data table name, sorting field name, record filtering conditions, original sorting value and target sorting value provided by the user, and generate the original parameter set. This step forms the basis for sorting and adjusting the input. Core parameters are collected through a standardized interface to ensure that subsequent processing has a complete and clear data source. The specific implementation is as follows: The parameter input interface supports multiple interaction methods, including web form input, API interface calls (such as RESTful interfaces), and direct input from the database client, adapting to different business scenarios (such as sorting adjustment in the backend management system and batch data synchronization sorting). The interface design must clearly define the input format and description of each parameter: Target data table name (must match the actual table name in the database, such as "user_info" or "product_list"), used to specify the data source from which the sorting is to be adjusted; Sort field name (must be a numeric field existing in the target table, such as "sort_num" or "display_order"), this field must uniquely identify the sorting position of each record, usually of type INT (value range 1-10000, to avoid overflow); Record filtering conditions (must conform to the SQL WHERE clause format, such as "dept_id = 101 AND status = 'active'"), used to limit the sorting adjustment to records within a specific range, avoiding impact on irrelevant data; Original sort value (denoted as oldSort, can be an INT numeric value or null), null values ​​represent newly inserted records (without an original sorting position), non-null values ​​are the current sorting value of the record (e.g., 3, 5); Target sort value (denoted as newSort, must be a non-null INT numeric value), representing the target sorting position of the current record after adjustment (e.g., 2, 6).

[0024] After the user inputs parameters, the system organizes all parameters into a raw parameter set according to a "key-value" structure. Each key corresponds to a parameter type, and the value is the user's input content. For example, if a user adjusts the sorting of the record "dept_id = 101" in the "user_info" table, the raw parameter set corresponding to the input parameters would be: target table name = "user_info", sort field name = "sort_num", record filter condition = "dept_id = 101", original sort value = 3, target sort value = 5. The set must retain the original format of the user input (without modification) and record the input timestamp (accurate to milliseconds) and input source (e.g., "Web form - administrator account admin") for easy traceability and troubleshooting.

[0025] Perform format validation on the original parameter set, verify whether the target data table name and sorting field name conform to the database identifier specification, whether the record filtering conditions are valid SQL expressions, and whether the original sorting value and the target sorting value are valid integer values ​​or null values, and generate a parameter set that passes the validation. This step ensures the validity of input parameters through multi-dimensional validation, avoiding subsequent sorting adjustments from failing or data anomalies due to formatting errors. The specific implementation is as follows: The validation of the target table name and sorting field name must conform to database identifier specifications. These specifications vary slightly between different databases (such as MySQL and PostgreSQL), but the following standards apply: the identifier length cannot exceed 255 characters (to avoid exceeding the database field length limit), it can only contain letters, numbers, and underscores, and cannot begin with a number (e.g., "user_info_2025" conforms to the specifications, while "2025_user" and "user@info" do not). Simultaneously, the system tables of the database (such as "information_schema.tables" and "information_schema.columns" in MySQL) must be queried to verify that the target table name actually exists (to avoid entering non-existent table names) and that the sorting field name is a numeric field in the target table (e.g., INT, BIGINT, excluding non-numeric types such as VARCHAR and DATE, ensuring that the sorting value can be incremented / decremented). For example, when validating the "sort_num" field of the "user_info" table, querying the system tables confirms the table's existence and that "sort_num" is of type INT, thus passing the validation.

[0026] The validation of filter conditions must ensure that they are valid SQL expressions. Key validation points include: Syntactic integrity (must include the three elements: field, operator, and value; e.g., "dept_id = 101" is valid, but "dept_id = " " and " = 101 is invalid); Operator validity (only logical AND comparison operators such as "=, >, <, >=, <=, AND, OR, NOT" are allowed; DDL / DML keywords such as "DROP, ALTER, INSERT" are prohibited to prevent malicious SQL injection); Value type matching (e.g., if the field "dept_id" is of type INT, the value must be an integer, not the string "abc"; if the field "status" is of type VARCHAR, the value must be enclosed in single quotes, such as "'active'"). For example, the filter condition "dept_id = 101 AND status = active" is invalid because "active" is not enclosed in single quotes, and the user should be prompted to add the quotes.

[0027] The validation of the original sort value and the target sort value needs to be differentiated: The original sort value can be an INT type numeric value (such as 3, 5) or a null value (NULL, representing a newly inserted record). If it is a numeric value, it must be within the range of 1-10000 (to avoid exceeding the normal sort value range); the target sort value must be a non-null INT type numeric value, and also within the range of 1-10000. Cases where the original sort value is equal to the original sort value must be excluded (if oldSort=3 and newSort=3, no further adjustment is needed; it is directly judged as valid but marked "no operation required"). For example, if the original sort value = "abc" (not a numeric value) and the target sort value = 10001 (out of range), both are considered invalid and an error message must be returned.

[0028] After all validation items pass, the parameters are organized into a set of validated parameters, the validation status of each parameter is marked (e.g., "Table name: valid" "Filter condition: valid"), and invalid parameters (e.g., the corrected filter condition) are removed to provide reliable input for subsequent optimization steps.

[0029] Based on the validated parameter set, the field references and value types in the record filtering conditions are parsed to eliminate potential security risks and optimize the condition expression structure, generating a security-optimized condition expression. This step, through in-depth analysis and optimization, ensures that the filtering criteria are both safe and efficient, avoiding security threats or performance degradation to the database. The specific implementation is as follows: When resolving field references in filter conditions, it's crucial to ensure that each field belongs to the target table to avoid referencing non-existent fields that could lead to SQL execution errors. For example, in the filter condition "dept_id = 101 AND role_id = 5", the field list of the target table "user_info" must be queried to confirm that "dept_id" and "role_id" are indeed fields in that table. If "role_id" is found to belong to the "user_role" table (not the target table), it's considered a field reference error, and the user should be prompted to correct it. Simultaneously, the data type of the fields must be parsed (e.g., "dept_id" is INT, "create_time" is DATETIME) to ensure that subsequent value types match.

[0030] Value type parsing must ensure that the data type of the values ​​in the filter conditions is completely consistent with the field data type to avoid reduced query efficiency or result deviations caused by implicit type conversion. For example, if the field "dept_id" is of type INT, and the filter condition is "dept_id = '101'" (value is a string), it should be automatically converted to "dept_id = 101" (value is an integer); if the field "create_time" is of type DATETIME, and the filter condition is "create_time = 20251027" (value is a number), it should be converted to "create_time = '2025-10-27 00:00:00'" (value is a standard time string).

[0031] The core of eliminating potential security risks is preventing SQL injection attacks. This involves using parameterized queries to separate user-input variables from the SQL statement structure, avoiding direct string concatenation. For example, in a filter condition "dept_id = 101 AND username = 'admin'", if a user maliciously inputs "dept_id = 101; DROP TABLE user_info;--", the keyword "DROP" must be detected and intercepted. Simultaneously, the variables "101" and "admin" should be passed as parameters, rather than being directly embedded in the SQL statement. Furthermore, special characters (such as ";", "--", and "#") must be filtered to prevent statement truncation or comment attacks.

[0032] Conditional expression structure optimization aims to improve SQL execution efficiency, including eliminating redundant conditions (e.g., simplifying "dept_id= 101 AND dept_id = 101" to "dept_id = 101"), adjusting the order of conditions (placing conditions with a larger filtering range at the beginning, such as changing "status = 'active' AND dept_id = 101" to "dept_id = 101 AND status = 'active'", since "dept_id" filters less data), and optimizing operators (e.g., replacing "dept_id = 101 OR dept_id = 102" with "dept_id IN (101, 102)" to reduce the number of logical operations). The optimized conditional expression should maintain its semantics and only improve execution efficiency; for example, the original condition "dept_id = 101 AND status = 'active' AND dept_id = 101" should be optimized to "dept_id = 101 AND status = 'active'".

[0033] The final generated security optimization condition expression must simultaneously meet four requirements: "field exists, type matches, no security risks, and efficient structure". For example, "dept_id = 101 AND status = 'active'" (the field is wrapped in backticks to avoid conflict with database keywords), providing a safe and reliable conditional foundation for the subsequent construction of SQL statements.

[0034] The conditional expression for security optimization is standardized and assembled with the target data table name, sorting field name, original sorting value, and target sorting value to generate a standardized set of dynamic parameters.

[0035] This step ensures that subsequent sorting adjustment strategies and SQL statement construction can be directly invoked by standardizing parameter formats, avoiding errors caused by inconsistent formats. The specific implementation is as follows: The standardization of target table names should adopt the database-wide identifier wrapping method. Different databases should uniformly use backticks () to wrap table names. For example, "user_info" should be standardized to "user_info`" to avoid table name conflicts with database keywords (such as "order" and "table"). If the table name contains special characters (such as "user_info_2025"), it should also be wrapped with backticks to ensure that the database can correctly recognize it.

[0036] The standardized name of the sorting field should be consistent with the table name, enclosed in backticks, and the numeric type of the field should be clearly identified. For example, "sort_num" should be standardized to "sort_num(INT)" to facilitate the confirmation of the sorting operation rules (such as incrementing / decrementing both being integer operations). If the field is of type BIGINT (such as "display_order"), it should be marked as "display_order(BIGINT)" to ensure that the numeric range is compatible.

[0037] The conditional expressions for security optimization should retain the optimized structure and add backticks to the fields. For example, the original optimized condition "dept_id = 101 AND status = 'active'" should be standardized to "dept_id = 101 AND status = 'active'". At the same time, the filtering logic corresponding to the condition should be recorded (such as "filtering records with department ID 101 and status 'active'") to facilitate subsequent manual review.

[0038] The standardization of the original sort value and the target sort value needs to clearly define the numerical type and null value identifier. For example, when the original sort value is 3 (INT type), it should be marked as "oldSort = 3 (INT, not null)" and when it is NULL, it should be marked as "oldSort = NULL (new record)". When the target sort value is 5 (INT type), it should be marked as "newSort = 5 (INT, not null)". At the same time, the numerical range verification result should be added (such as "valid in the range of 1-10000").

[0039] During standardized assembly, parameters should be organized in a fixed order: "Target data table name → Sort field name → Security optimization condition expression → Original sort value → Target sort value". Each parameter should include a standardized identifier and validation result. For example, a standardized dynamic parameter set might look like this: Target data table name = "user_info (exists, INT field)", Sort field name = "sort_num (INT, valid)", Security optimization condition expression = "dept_id = 101 AND status = 'active' (syntactically valid, no injection risk)", Original sort value = "3 (INT, not null, valid)", Target sort value = "5 (INT, not null, valid)". This set must ensure that each parameter has a consistent format and complete information. Subsequent steps can directly extract parameters to generate sorting adjustment strategies and SQL statements without secondary formatting.

[0040] S202, Based on the comparison result between the original sort value and the target sort value, and in conjunction with the record filtering conditions, a batch adjustment strategy for sort values ​​is generated. The strategy includes uniformly increasing or decreasing the sort values ​​of records within a specified numerical range. Specifically, the original sorting value and the target sorting value can be extracted from the standardized dynamic parameter set, and numerical comparison and null value judgment can be performed to generate sorting value relationship analysis results; This step is crucial for determining the direction of sorting adjustments. By parsing key parameters and analyzing their numerical relationships, it provides a basis for subsequent scenario definitions. The specific implementation is as follows: The standardized dynamic parameter set integrates all input information in a unified format. When extracting the original sort value (denoted as oldSort) and the target sort value (denoted as newSort), it is necessary to first locate the corresponding parameter items in the set: the target data table name (e.g., "user_info") and the sorting field name (e.g., "sort_num") are only used to confirm the parameter's ownership. The core extraction objects are the numerical content of the "original sort value" and the "target sort value". For example, if the original sort value in a set is labeled "oldSort = 3 (INT, not empty, valid)" and the target sort value is labeled "newSort = 5 (INT, not empty, valid)", then the extracted numerical pair is (3, 5); if the original sort value is labeled "oldSort = NULL (new record)" and the target sort value is "newSort = 2 (INT, not empty, valid)", then the numerical pair is (NULL, 2).

[0041] Null value detection focuses on the original sort value. Since the target sort value has been confirmed to be non-null in the previous validation (only valid INT values ​​are allowed), it is necessary to determine whether oldSort is NULL: If the oldSort field in the value pair is explicitly marked "NULL" or has no specific value (such as "oldSort = (null value)"), it is determined that "the original sort value is null", corresponding to the scenario of newly inserted records (no original sort position, the target sort position needs to be made up for the new record); if oldSort is a specific INT value (such as 3, 5), it is determined that "the original sort value is not null", corresponding to the scenario of sorting adjustment of existing records. For example, the null value detection result for the value pair (NULL, 2) is "the original sort value is null", and the detection result for the value pair (3, 5) is "the original sort value is not null".

[0042] Numerical comparison only applies when the original sort value is not empty. The relationship is analyzed by calculating the difference between the target sort value and the original sort value (denoted as ΔSort): If ΔSort > 0 (e.g., newSort=5, oldSort=3, ΔSort=2), it means the target sort value is greater than the original sort value, and the current record needs to be adjusted to a higher position in the sort (e.g., from the 3rd position to the 5th position; here, "the smaller the sort value, the higher the position" is the conventional logic. If the business logic is reversed, the direction of ΔSort will be adjusted accordingly); if ΔSort < 0 (e.g., newSort=3, oldSort=5, ΔSort=-2), it means the target sort value is less than the original sort value, and it needs to be adjusted to a lower position in the sort; if ΔSort = 0 (e.g., newSort=4, oldSort=4), it means the sort value has not changed, and no further adjustment is needed.

[0043] By integrating the results of null value detection and numerical comparison, four types of sorting value relationships are defined: First, "New Record" (oldSort = NULL, regardless of the value of newSort); second, "Ascending Order Adjustment" (oldSort is not null and ΔSort > 0); third, "Descending Order Adjustment" (oldSort is not null and ΔSort < 0); and fourth, "No Adjustment Required" (oldSort is not null and ΔSort = 0). For example, the numerical pair (NULL, 2) corresponds to "New Record", (3, 5) corresponds to "Ascending Order Adjustment", (5, 3) corresponds to "Descending Order Adjustment", and (4, 4) corresponds to "No Adjustment Required". This information is then compiled into the sorting value relationship analysis results, clearly labeling the relationship type, key values, and differences (when not null).

[0044] In another implementation, the original and target sorted values ​​are extracted from a standardized set of dynamic parameters, and numerical comparisons and null value checks are performed to generate sorted value relationship analysis results, which may include: The original sorting value and the target sorting value are parsed and extracted from the standardized set of dynamic parameters to generate numerical pairs of the original sorting value and the target sorting value. This step is fundamental to the analysis of ranked value relationships. By accurately locating and extracting core parameters, the structured information in the standardized set is transformed into a combination of numerical values ​​that can be directly analyzed. The specific implementation is as follows: The standardized dynamic parameter set integrates all input information in a unified format. Among them, the "original sort value" (denoted as oldSort) and the "target sort value" (denoted as newSort) are the core analysis objects, and specific values ​​need to be parsed from the corresponding parameter entries in the set. The annotations for these two parameters in the set usually include the numerical content, data type, and validity indicator. For example, in a certain set, the annotation for the "original sort value" is "oldSort = 3 (INT type, not empty, valid range 1-10000)", and the annotation for the "target sort value" is "newSort = 5 (INT type, not empty, valid range 1-10000)". During parsing, "3" and "5" need to be extracted as specific values ​​and combined into a numerical pair of (3,5).

[0045] If the original sort value is a newly added record (without an existing sort position), the collection will explicitly mark "oldSort = NULL (new record identifier, no initial sort value)". In this case, the parsed value is NULL, while the target sort value is still a non-empty integer (e.g., 2), and the value pair will be (NULL, 2). Note that the target sort value has been confirmed to be non-empty and a valid integer during the initial parameter validation (excluding negative numbers, decimals, or values ​​outside the range of 1-10000). Therefore, in all value pairs, newSort is a specific INT value, while oldSort has two possibilities: "NULL" or "specific integer".

[0046] The parsing process needs to verify the consistency of values: if `oldSort` in the set is marked as "not empty" but has no specific value (e.g., "oldSort = (not filled in)"), it is determined that the parameter is missing, and the message "Original sort value is missing, please fill in" should be returned; if `newSort` is marked as "5 (INT)" but the actual value is "abc" (an anomaly missed in the previous validation), it is determined that the value is invalid, and the parameter validation process needs to be retried. For example, if there is a type contradiction in "newSort = abc (INT)" in a set, the parsing process needs to identify this anomaly and terminate the extraction, and then re-execute after the parameter is corrected.

[0047] The final generated numerical pairs must include a source identifier, such as "numerical pair (3,5) comes from the sort adjustment parameter of the sort_num field in the user_info table", to ensure that subsequent analysis can be traced back to the specific data table and sorting field, and to avoid confusion between different parameters.

[0048] Perform null value detection on the numerical pairs of the original sort value and the target sort value, determine whether the original sort value is null, and generate null value detection results; This step identifies the null state of the original sort values, distinguishing between two core scenarios: "new record" and "adjustment of existing record," providing a preliminary judgment for subsequent numerical comparisons. The specific implementation is as follows: The only object of null value detection is the original sort value (oldSort). Since the target sort value (newSort) has already been identified as a non-null valid integer in the previous validation, there is no need to perform a duplicate check. The detection criteria are based on the annotations in the standardized parameter set: if oldSort is annotated as "NULL", "null value", or "new record identifier", it is determined that "the original sort value is null"; if it is annotated as a specific integer (such as 3, 5) and there is no "null value" annotation, it is determined that "the original sort value is not null".

[0049] For example, in the numerical pair (NULL,2), oldSort is marked as "NULL (new record)", and the null value detection result is "the original sort value is empty, corresponding to the new record scenario, and space needs to be made for the target sort value (2)"; in the numerical pair (3,5), oldSort is marked as "3 (INT not empty)", and the detection result is "the original sort value is not empty, corresponding to the existing record sorting adjustment scenario, and the adjustment direction needs to be determined based on numerical comparison".

[0050] Special attention should be paid to the difference between "empty value" and "invalid value": If oldSort is marked as "0 (INT)", although 0 may not conform to the sorting logic of some business scenarios (such as sorting values ​​starting from 1), it still belongs to the category of "not empty". The empty value detection result is "original sorting value is not empty (value 0)"; if oldSort is marked as "(undefined)" and has no specific value, it is judged as "parameter abnormal (not empty and not a value)". The user should be prompted to reconfirm the oldSort status to avoid misjudging "undefined" as "NULL".

[0051] The null value detection result should include three parts: "detection conclusion", "judgment basis" and "corresponding scenario prompt". For example, a detection result is: "Detection conclusion: the original sort value is null; judgment basis: the standardized set label 'oldSort = NULL (new record)'; scenario prompt: the target sort value (2) and above of the qualified records need to be adjusted in the future to make room for the new record", so as to ensure that the subsequent steps can clearly locate the scenario.

[0052] Based on the null value detection results, if the original sorted value is not null, a numerical comparison is performed to calculate the difference between the target sorted value and the original sorted value, and a numerical comparison result is generated. This step only applies to the "adjusting existing records" scenario. By quantifying the numerical relationship between the original sort value and the target sort value, the direction and magnitude of the sort adjustment are determined. The specific implementation is as follows: The numerical comparison is triggered only when the null value detection result is "original sort value is not null"; if the result is "original sort value is null" (in the case of adding a new record), this step is skipped, and the process proceeds directly to the subsequent relation type definition. The core of the comparison is to calculate the difference between "target sort value - original sort value" (denoted as ΔSort). The sign and magnitude of ΔSort directly reflect the direction and scope of the adjustment. If ΔSort > 0, it means that the target sort value is greater than the original sort value, and the current record needs to be adjusted in the direction of "larger sort value" (such as adjusting from 3 to 5, the sort position is usually "the smaller the value, the earlier it is", so this adjustment is actually "moving backward"). If ΔSort < 0, it means that the target sort value is less than the original sort value, and the current record needs to be adjusted in the direction of "smaller sort value" (such as adjusting from 5 to 3, which is actually "moving forward"). If ΔSort = 0, it means that the two values ​​are equal, and the sorting value does not need to be adjusted.

[0053] For example, for the numerical pair (3,5), ΔSort = 5 - 3 = 2 > 0, the numerical comparison result is "the target sort value (5) is greater than the original sort value (3), the difference ΔSort = 2, the adjustment direction is 'move backward', and it needs to cover 2 sort positions (from 3 to 5)"; for the numerical pair (5,3), ΔSort = 3 - 5 = -2 < 0, the result is "the target sort value (3) is less than the original sort value (5), the difference ΔSort = -2, the adjustment direction is 'move forward', and it needs to cover 2 sort positions (from 5 to 3)"; for the numerical pair (4,4), ΔSort = 4 - 4 = 0, the result is "the target sort value is equal to the original sort value, the difference ΔSort = 0, and there is no need to adjust the sort direction and position".

[0054] The difference calculation must ensure consistency of numerical types: since both `oldSort` and `newSort` are of type `INT`, `ΔSort` must be an integer, and there are no decimal cases (e.g., `ΔSort=1.5` is an anomaly, requiring backtracking to the parameter validation stage). Simultaneously, the actual meaning of the adjustment direction must be determined in conjunction with the sorting logic of the business scenario: if in a certain business scenario "the larger the sort value, the earlier it appears" (e.g., sorting by product sales), then `ΔSort>0` corresponds to "moving forward," and this needs to be explained in the result to avoid confusion. For example, for the product table's numerical pair (3,5), `ΔSort=2`, combined with the "larger value first" logic, the comparison result needs to be supplemented with "the actual sorting position has been adjusted from the 3rd position to the 5th position."

[0055] Numerical comparison results should be clearly labeled with "ΔSort value", "adjustment direction", and "number of sort positions covered" to provide a quantitative basis for subsequent interval calculations. For example, a result may be labeled as "ΔSort=-2, adjustment direction 'move forward', number of sort positions covered 2 (from 5 to 3, involving sort values ​​4 and 3)".

[0056] Integrate the null value detection results and numerical comparison results, define the sorting value relationship type, including new record, ascending order adjustment, descending order adjustment, or no adjustment, and finally generate the sorting value relationship analysis results.

[0057] This step transforms abstract numerical relationships into explicit business scenario types by integrating the results of preceding detections and comparisons, providing a core basis for generating subsequent sorting and adjustment strategies. The specific implementation is as follows: The sorting value relationship type is divided into four categories, each corresponding to a specific combination of results, which must be strictly defined according to the rules: The first category, "New Record," corresponds to the null value detection result "Original sort value is empty." Regardless of the target sort value (e.g., 2, 4), it is classified as this type. The core characteristic of this type is "no existing sort position, space needs to be made for the target sort value of the new record." The relationship description must include the target sort value and the approximate range of subsequent adjustments. For example, "Sorting value relationship type: New Record; Core parameters: oldSort=NULL, newSort=2; Relationship description: The new record needs to be inserted at the position of sort value 2. Subsequently, records that meet the filtering conditions and have a sort value ≥ 2 need to be adjusted to ensure no sorting duplicates."

[0058] The second type, "ascending order adjustment," corresponds to a null value detection result where the original sort value is not null and the numerical comparison result is "ΔSort>0" (the target sort value is greater than the original sort value), such as the numerical pair (3,5) (ΔSort=2). The core characteristic of this type is that "the current record moves backward, and intermediate records need to be adjusted forward." The relationship description must clearly specify the numerical range to be adjusted, for example, "sort value relationship type: ascending order adjustment; core parameters: oldSort=3, newSort=5, ΔSort=2; relationship description: the current record is adjusted from sort value 3 to 5. Records that meet the filtering conditions and whose sort value is > 3 and ≤ 5 need to be decremented by 1 to avoid sorting duplication. The adjustment covers sort values ​​4 and 5."

[0059] The third type, "descending order adjustment," corresponds to a null value detection result where the original sort value is not null and the numerical comparison result is "ΔSort<0" (the target sort value is less than the original sort value), such as the numerical pair (5,3) (ΔSort=-2). The core characteristic of this type is that "the current record moves forward, and intermediate records need to be adjusted backward." The relationship description needs to clearly specify the numerical range to be adjusted, for example, "sort value relationship type: descending order adjustment; core parameters: oldSort=5, newSort=3, ΔSort=-2; relationship description: the current record is adjusted from sort value 5 to 3. Records that meet the filtering conditions and whose sort value is ≥3 and <5 need to be incremented by 1 to avoid sorting duplication. The adjustment covers sort values ​​3 and 4."

[0060] The fourth category, "No Adjustment Required," corresponds to a null value detection result where the original sort value is not null and the numerical comparison result is "ΔSort=0" (the target sort value is equal to the original sort value), such as the numerical pair (4,4) (ΔSort=0). The core characteristic of this type is that "the sort value has not changed, and no adjustment operation is required." The relationship description must explicitly terminate the subsequent process, for example, "Sorting value relationship type: No adjustment required; core parameters: oldSort=4, newSort=4, ΔSort=0; relationship description: the current record's sort value has not changed, no batch adjustment or single update operation is required, and the subsequent process terminates."

[0061] The final generated sorting value relationship analysis result must include four parts: "Relationship Type," "Core Parameter Details," "Scenario Logic Description," and "Subsequent Operation Guidelines," forming a complete analysis report. For example, the complete result for a descending order adjustment scenario is: "Sorting Value Relationship Analysis Result: 1. Relationship Type: Descending Order Adjustment; 2. Core Parameter Details: Target Data Table - task_table, Sort Field - task_order, oldSort=5 (INT NOT NULL), newSort=3 (INT NOT NULL), ΔSort=-2; 3. Scenario Logic Description: The current record needs to be adjusted from sorting value 5 to 3. Records meeting the conditions at intermediate sorting values ​​3 and 4 need to be incremented by 1 to free up the position of sorting value 3; 4. Subsequent Operation Guidelines: A batch sorting value adjustment strategy needs to be generated based on this result, determining the target value range [3,5) and the adjustment operation (incrementing by 1)." This result must ensure logical coherence, complete parameters, and can be directly used as input for subsequent steps to avoid strategy generation deviations caused by missing information.

[0062] Based on the analysis results of the sorting value relationship, combined with the conditional expression for security optimization, the specific scenarios for sorting adjustment are determined. These scenarios include adding new records, ascending order adjustment, or descending order adjustment, and sorting adjustment scenario definitions are generated. This step transforms abstract numerical relationships into specific business operation scenarios by associating parameter relationships with filtering conditions, ensuring that the adjustment range is accurate and controllable. The specific implementation is as follows: The analysis of sorted values ​​has clarified the core adjustment direction. The scenario needs further refinement using safety-optimized conditional expressions (limiting the range of records to be adjusted). These safety-optimized conditional expressions typically include field filtering logic (e.g., "dept_id = 101 AND status = 'active'"), meaning that only records with "department ID = 101 and status = 'active'" will be operated on, rather than the entire table. This is the key boundary for scenario definition.

[0063] The scenario of adding a new record corresponds to the relationship type "oldSort=NULL". The scenario definition must clearly state that "to free up the target sorting position for the newly inserted record, only records that meet the filtering conditions and whose sorting value is ≥ the target sorting value are adjusted." For example, the conditional expression for security optimization is "dept_id = 101", newSort=2. The scenario definition is "For the record dept_id=101 in the user_info table, if a new record with a sorting value of 2 is inserted, all records in this department with a sorting value ≥ 2 need to be adjusted to free up sorting position for the new record." The core of this type of scenario is "shifting subsequent records to the right" to avoid the sorting value of the new record being duplicated with existing records.

[0064] Ascending order adjustment scenarios correspond to the relationship type "ΔSort>0" (newSort>oldSort). The scenario definition must explicitly state that "the current record is moved from its original sort position to a more recent target position, adjusting only records that meet the filtering criteria and whose sort value falls between the original and target sort values." For example, if oldSort=3, newSort=5, and the filtering criteria are "dept_id = 101 AND role = 'staff'", the scenario definition is: "For records in the user_info table where dept_id=101 and role='staff', move the record with a current sort value of 3 to position 5. This requires adjusting records within this range whose sort values ​​are greater than 3 and less than or equal to 5 to avoid duplicate sort values." The core of this type of scenario is "moving intermediate records forward," making room for the current record's position adjustment.

[0065] The descending adjustment scenario corresponds to the relationship type of "ΔSort < 0" (newSort < oldSort). The scenario definition needs to clarify that "the current record is adjusted from the original sorting position to a more backward target position, and only the records that meet the filtering conditions and whose sorting values are between the target sorting value and the original sorting value are adjusted". For example, oldSort = 5, newSort = 3, and the filtering condition is "dept_id = 101 AND create_time >= '2025-01-01'". The scenario definition is that for the records in the user_info table where dept_id = 101 and create_time ≥ '2025-01-01', the record with the current sorting value of 5 is adjusted to the position of 3, and the records with sorting values greater than or equal to 3 and less than 5 within this range need to be adjusted to ensure the continuity of the sorting sequence. The core of this type of scenario is "the middle records are moved backward" to avoid conflicts in sorting values between the current record and other records after insertion.

[0066] If the relationship type is "no adjustment required" (ΔSort = 0), the scenario definition is that "the sorting value of the current record remains unchanged and no records need to be adjusted", and the subsequent steps can be directly terminated without generating an adjustment strategy. The finally generated sorting adjustment scenario definition needs to completely include the table name, filtering conditions, adjustment direction, and core operation logic to provide clear guidance for subsequent interval calculations.

[0067] According to the sorting adjustment scenario definition, calculate the boundaries of the sorting value interval to be adjusted, clarify the open-closed characteristics of the interval, and generate the target numerical interval specification; This step determines the sorting value interval to be operated by quantifying the adjustment range in the scenario definition, ensuring that the adjustment only affects the necessary records. The specific implementation is as follows: The calculation of the target numerical interval boundaries needs to strictly follow the logic of the scenario definition. Combining the numerical characteristics of the sorting field (INT type, consecutive integers), determine the upper and lower limits of the interval for different scenarios: In the scenario of adding a new record, the records with "sorting value ≥ newSort" need to be adjusted (because the sorting value of the new record is newSort, and the existing records need to be moved backward to avoid duplication). The lower limit of the interval is newSort, and the upper limit is the maximum sorting value under this filtering condition (without specifying the specific value, represented by "+∞"). The interval expression is "[newSort, +∞)". For example, newSort = 2, and the interval is "[2, +∞)", indicating that all records with sorting values equal to or greater than 2 need to be adjusted; if the maximum sorting value under the filtering condition is 10, the actual adjustment range is 2 - 10.

[0068] In ascending order adjustment scenarios, records whose sort value is greater than or equal to newSort need to be adjusted (because the original sort value of the current record is oldSort, and it needs to be updated to newSort after adjustment; intermediate records need to be shifted forward to fill the gaps). The lower limit of the interval is oldSort (excluding it, because the current record corresponding to oldSort will not be adjusted for the time being), and the upper limit is newSort (including it, because the original record corresponding to newSort needs to be shifted forward). The interval expression is "(oldSort, newSort]". For example, if oldSort=3 and newSort=5, the interval is "(3,5]", which means that records with sort values ​​of 4 and 5 need to be adjusted; if oldSort=2 and newSort=4, the interval is "(2,4]", which corresponds to records with sort values ​​of 3 and 4.

[0069] In descending order adjustment scenarios, records whose sort value is ≥ newSort and < oldSort need to be adjusted (because the original sort value of the current record is oldSort, it needs to be updated to newSort after adjustment, and intermediate records need to be shifted to accommodate the current record). The lower limit of the interval is newSort (inclusive, because the original record corresponding to newSort needs to be shifted), and the upper limit is oldSort (exclusive, because the current record corresponding to oldSort is not adjusted for the time being). The interval expression is "[newSort, oldSort)". For example, if oldSort=5 and newSort=3, the interval is "[3,5)", which means that records with sort values ​​of 3 and 4 need to be adjusted; if oldSort=6 and newSort=2, the interval is "[2,6)", which corresponds to records with sort values ​​of 2, 3, 4, and 5.

[0070] The definition of the open / closed interval property requires an explanation of the logical basis: In the new addition scenario, newSort is included (because the position corresponding to newSort needs to be occupied by the new record, records with that value must be moved to the next position); in the ascending order scenario, oldSort is not included (to avoid the original sort value of the current record being mistakenly adjusted, its sort value must be updated to newSort last) and newSort is included (the record corresponding to the original newSort needs to be moved forward to make room for the current record); in the descending order scenario, newSort is included (the record corresponding to the original newSort needs to be moved to the next position to make room for the current record) and oldSort is not included (similarly, the original sort value of the current record is not adjusted for now).

[0071] The generated target value range specification must clearly indicate the scene type, range expression, boundary meaning, and opening / closing characteristics. For example, the specification for the ascending order adjustment scene is "Scenario: Ascending order adjustment; Range: (3,5]; Boundary meaning: Lower limit 3 (excluding, the original sort value of the current record), upper limit 5 (including, the target sort value); Adjustment range: Records with sort values ​​of 4 and 5", ensuring that subsequent adjustment operations only affect records within this range and minimize the impact range.

[0072] Based on the target value range specification and the definition of sorting adjustment scenarios, a specific sorting value adjustment operation plan is formulated, including the increment or decrement magnitude and direction, and a batch sorting value adjustment strategy is generated.

[0073] This step transforms the interval specification into an executable batch adjustment scheme by clarifying the specific operational logic, ensuring that the sorted values ​​are updated accurately and without duplicates. The specific implementation is as follows: The core of the sort value adjustment operation scheme is to determine the operation type and magnitude of "increment" or "decrement". The magnitude is uniformly 1 (because the sort values ​​are consecutive integers, ±1 ensures that they remain consecutive after adjustment, avoiding null values ​​or duplicates. This is a key design based on sort integrity). The operation type is determined according to the scenario definition: In the scenario of adding a new record, records within the interval need to be incremented by 1 (shifted to the next record). This is because after a new record is inserted, the sort values ​​of existing records with a value greater than or equal to `newSort` need to be increased by 1 to make room for the new record's `newSort` and maintain the continuity of the sort sequence. For example, in the interval "[2, +∞)", the sort values ​​are 2→3, 3→4, ..., 10→11. After adjustment, the new record can be inserted at the position of sort value 2, without repetition or gaps.

[0074] In the ascending order adjustment scenario, records within the interval need to be "decreased by 1" (moved forward). Since the current record is adjusted from oldSort (e.g., 3) to newSort (e.g., 5), the records in the middle 4 and 5 need to be -1 (4→3, 5→4). This avoids duplication with the current record's oldSort (3) and also makes room for the current record to be finally updated to 5. After adjustment, the sorted sequence changes from "1,2,3,4,5" to "1,2,4,5 (to be inserted into the current record)". After the current record is updated to 5, the final sequence is "1,2,4,5", which is continuous and without duplication.

[0075] In descending order adjustment scenarios, records within a range need to be incremented by 1 (shifted to the next record). Since the current record is being adjusted from `oldSort` (e.g., 5) to `newSort` (e.g., 3), records 3 and 4 in the middle need to be incremented by 1 (3→4, 4→5) to make room for the current record 3 and to avoid duplication. After adjustment, the sorted sequence changes from "1,2,3,4,5" to "1,2,4,5 (to be inserted)". After the current record is updated to 3, the final sequence is "1,2,3,4,5", restoring continuity.

[0076] The operation plan needs to combine the target value range specification and the conditional expression for safety optimization, and clearly define the scope of the operation. For example, the plan for the scenario of adding a new record is "for the record in the user_info table with dept_id=101, for the record whose sort_num field value belongs to the range [2, +∞), perform the operation sort_num = sort_num + 1"; the plan for the scenario of ascending order adjustment is "for the record in the user_info table with dept_id=101 and role='staff', for the record whose sort_num field value belongs to the range (3,5], perform the operation sort_num = sort_num - 1".

[0077] The final generated batch adjustment strategy for sorting values ​​needs to integrate scenario definitions, range specifications, operation plans, and core parameters (table name, sorting field, and filtering conditions) to form a complete execution basis. For example, a descending order adjustment strategy might be: "Target table: user_info; Sort field: sort_num; Filtering condition: dept_id=101 AND create_time≥'2025-01-01'; Scenario: Descending order adjustment (oldSort=5, newSort=3); Target range: [3,5); Operation: sort_num = sort_num + 1; Adjustment range: records that meet the conditions sort_num=3 and 4". This ensures that key information can be directly extracted when constructing subsequent SQL statements without secondary parsing.

[0078] S203, construct a dynamic structured query statement based on the batch adjustment strategy of the sort value, wherein the statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is within the specified value range; Specifically, the target value range specification and adjustment operation plan can be extracted from the batch adjustment strategy of sorting values, and the basic update statement structure can be constructed by combining the target data table name and sorting field name in the standardized dynamic parameter set. This step forms the basic framework for constructing SQL statements. By integrating the core information from the strategies and parameters, the core operation objects and scope of the statement are determined. The specific implementation is as follows: The batch adjustment strategy for sorted values ​​has clearly defined the key logic of sorting adjustment. When extracting the target value range specification, it is necessary to locate the specific description of the "target value range" in the strategy, including the range expression (such as "[2, +∞)", "(3,5]", "[3,5)"), the range opening and closing characteristics (including or excluding boundary values), and the applicable scenarios (adding records, ascending order adjustment, descending order adjustment). For example, if the target value range specification of a descending order adjustment strategy is "range: [3,5); opening and closing characteristics: including 3, excluding 5; scenario: descending order adjustment", then the core information of the extracted range is "sorted value ≥ 3 and < 5". The extraction of the adjustment operation plan needs to clarify the operation type and magnitude of "increment" or "decrement" (unified to 1, because the sorted value is a continuous integer, ±1 can ensure no repetition or gaps after adjustment). For example, the operation plan of the ascending order adjustment strategy is "decrement by 1 (move forward)", and the scenario for adding records is "increment by 1 (move backward)".

[0079] In the standardized set of dynamic parameters, the target data table name is a valid identifier enclosed in backticks (such as "user_info" or "product_list"), used to specify the data source for the statement operation; the sorting field name is also a numeric field enclosed in backticks (such as "sort_num" or "display_order"), which is the field to be updated in the statement. When constructing the basic update statement structure, the general format of the SQL UPDATE statement is followed: "UPDATE table_name SET sort_field = adjust_expression WHERE range_condition", where the "adjust_expression" is determined by the operation plan (e.g., incrementing by 1 is "sort_field = sort_field + 1", decrementing by 1 is "sort_field = sort_field - 1"), and the "range_condition" is derived from the target numeric range specification.

[0080] For example, in the scenario of adding new records: the target data table is named "product_list" (product information table), the sorting field is named "display_order" (product display sorting field), the target value range is specified as "[2, +∞)" (sorting value ≥ 2), and the adjustment operation scheme is "increment by 1". Then the basic update statement structure is "UPDATE product_listSET display_order = display_order + 1 WHERE display_order >= 2". This structure only contains the core operation logic and does not yet incorporate filtering conditions, which will need to be added in subsequent steps. However, it clearly defines "which table to operate on, which field to update, how to adjust, and which sorting values ​​to adjust," providing a stable framework for future expansion.

[0081] By incorporating security-optimized conditional expressions into the basic update statement structure, a condition-limited update statement framework is formed, ensuring that operations are performed only on records that meet the conditions. This step, by adding filtering logic, precisely limits the range of records to be sorted and adjusted, preventing irrelevant data from being mistakenly manipulated. The specific implementation is as follows: The conditional expressions for security optimization are valid SQL conditions that have undergone prior field validation, security filtering, and structural optimization (such as "dept_id = 101 AND status = 'active'" or "category_id = 5 AND stock > 0"). Their purpose is to filter specific groups of records from the target data table that require sorting adjustments (such as "active users in department 101" or "products in category 5 with inventory"), rather than adjusting the entire table. When integrated into the basic update statement structure, the conditional expression should be added to the end of the WHERE clause and connected with the range condition using "AND" to form a combined logic of "range condition AND filter condition," ensuring that only records whose "sort value is within the target range and meets the filter condition" are operated on.

[0082] For example, continuing with the new record addition scenario from step one: the safety-optimized conditional expression is "category_id = 5 AND stock > 0" (only adjusting products in category 5 that are in stock), and the basic update statement structure is "UPDATE product_list SET display_order = display_order + 1 WHERE display_order >= 2". The statement framework after incorporating the condition is "UPDATE product_list SET display_order = display_order + 1 WHERE display_order >= 2 AND category_id = 5 AND stock > 0". This framework clearly states that only products in the "product_list table that are in category 5, in stock, and have a display sort value ≥ 2" will have their sort value incremented by 1, avoiding impact on other categories or products without stock, thus adhering to the design principle of "minimizing the scope of impact".

[0083] During the integration process, it is necessary to verify the compatibility of conditional expressions and range conditions: if the filter conditions include additional restrictions on the sorting field (such as "display_order <10"), they need to be merged with the target numerical range specification (such as merging the range "[2, +∞)" and "display_order <10" into "display_order >= 2 AND display_order <10") to avoid logical conflicts. For example, if the range of a certain strategy is "(3,5]" and the filter condition includes "sort_num <= 4", then the merged range condition is "sort_num > 3 AND sort_num <= 4", ensuring consistent statement logic. The final condition-bound update statement framework must fully cover the five elements of "table name, update field, adjustment logic, range, and filter condition" to prepare for adding specific operation expressions.

[0084] Based on the adjusted operation plan, add a sorting field update expression to the condition-defined update statement framework, clarify the increment or decrement operation logic, and generate a complete update statement template. This step refines the update logic, transforming the abstract "increment / decrement" into concrete SQL expressions to ensure accurate execution of sort value adjustments. The specific implementation is as follows: The "increment by 1" or "decrement by 1" in the adjustment operation plan is the core basis of the sorting field update expression. The expression must directly act on the sorting field, and the operation increment must be fixed at 1 (because the sorting value is a continuous integer sequence, ±1 ensures that the sequence remains continuous after adjustment, without repetition or gaps, which is crucial for maintaining sorting integrity). Expressions corresponding to different scenarios must strictly match the strategy logic: Adding a new record (original sort value is empty): To free up a target sorting position for the new record, records within the range need to be "shifted" to the right. The expression is "sort field = sort field + 1". For example, the target data table is "user_info", the sorting field is "sort_num", and the condition frame is "WHERE sort_num >= 2 AND dept_id = 101". After adding the expression, the template is: "UPDATE user_info SET sort_num = sort_num + 1 WHERE sort_num >= 2 AND dept_id = 101". The logic is: "For users in department 101 whose sort value is ≥2, all sort values ​​are increased by 1 to free up a position for the new user's sort value of 2."

[0085] Ascending order adjustment scenario (target sort value > original sort value): The current record needs to be adjusted in the direction of a larger sort value (e.g., from 3 to 5). Intermediate records need to be "shifted forward" to avoid duplication. The expression is "sort field = sort field - 1". For example, the original sort value is 3, the target sort value is 5, the table name is "order_list", the sort field is "order_seq", and the condition frame is "WHERE order_seq > 3 AND order_seq <= 5 AND user_level = 'VIP'". After adding the expression, the template is: "UPDATE order_list SET order_seq = order_seq - 1 WHERE order_seq >3 AND order_seq <= 5 AND user_level = 'VIP'". The logic is: "For VIP users, the sort values ​​of orders with sort values ​​of 4 and 5 are all reduced by 1 (4→3, 5→4). The current order can be updated from 3 to 5 to avoid duplication."

[0086] Descending order adjustment scenario (target sort value < original sort value): The current record needs to be adjusted to a smaller sort value (e.g., from 5 to 3). Intermediate records need to be "shifted" to accommodate the current record. The expression is "sort field = sort field + 1". For example, with an original sort value of 5, a target sort value of 3, a table name "task_table", a sort field "task_order", and a conditional frame of "WHERE task_order >= 3 AND task_order < 5 AND task_status = 'pending'", the template after adding the expression is: "UPDATE task_table SET task_order = task_order + 1WHERE task_order >= 3 AND task_order < 5 AND task_status = 'pending'". The logic is: "Records with sort values ​​of 3 and 4 in the pending tasks will have their sort values ​​increased by 1 (3→4, 4→5). The current task can subsequently be updated from 5 to 3, ensuring a continuous sequence."

[0087] A complete update statement template must ensure that the expression strictly corresponds to the scenario logic and has no syntax errors (such as enclosing field names in backticks to avoid conflicts with keywords). At the same time, all limiting conditions must be retained. For example, in the ascending order adjustment template, the range condition "order_seq > 3 AND order_seq <= 5" and the filter condition "user_level = 'VIP'" are both indispensable. The former ensures that the adjustment range is accurate, and the latter prevents irrelevant records from being modified.

[0088] The system performs parameter binding and statement optimization on the complete update statement template, eliminating SQL injection vulnerabilities and improving query efficiency, generating secure and optimized dynamic structured query statements.

[0089] This step, through security hardening and performance optimization, ensures that the statement can both resist malicious attacks and execute efficiently. The specific implementation is as follows: Parameter binding is a core technique for eliminating SQL injection vulnerabilities. Its principle is to separate variables in the statement (such as field values ​​in filter conditions and range boundary values) from the SQL statement structure, avoiding injection risks caused by directly concatenating strings. In implementation, fixed numerical values ​​in the template are replaced with parameter placeholders (such as "?" or ":param"), and then the parameter values ​​are securely passed to the statement through the database driver. For example, the complete template for a descending order adjustment scenario is "UPDATE task_table SET task_order = task_order + 1 WHERE task_order >= 3 AND task_order < 5 AND task_status = 'pending'", which, after parameter binding, becomes "UPDATE task_table SET task_order = task_order + 1 WHERE task_order >= ? AND task_order < ? AND task_status = ?", where "?" corresponds to the parameter values ​​3, 5, and 'pending', respectively. During execution, parameter values ​​are transmitted through an independent channel. The database automatically filters special characters (such as ";" and "--"). Even if the parameter value contains malicious code (such as "' OR '1'='1"), it is only treated as a normal string and cannot tamper with the statement structure, thus completely eliminating the risk of injection.

[0090] Statement optimization focuses on improving execution efficiency, mainly including index optimization and condition optimization: Index optimization requires creating composite indexes for the fields (sorting fields and filtering fields) involved in the WHERE clause of the statement. For example, for the condition "task_order >= ? AND task_status = ?", create a composite index "task_status + task_order", so that the database can quickly locate records that meet the conditions without a full table scan, which can improve query efficiency by 5-10 times; Condition optimization requires eliminating redundant conditions (such as simplifying "task_order >= 3 AND task_order >= 3" to "task_order >= 3") and adjusting the order of conditions (placing conditions with smaller filtering ranges first, such as "task_status = 'pending'" before "task_order >= 3", because the amount of data after status filtering is smaller), to further reduce the amount of computation in the database.

[0091] For example, consider the optimized statement for an ascending order adjustment scenario: Table name "order_list", sorting field "order_seq", parameter bound statement is "UPDATE order_list SET order_seq = order_seq - 1 WHERE user_level = ? AND order_seq > ? AND order_seq <= ?", bound parameters 'VIP', 3, 5, and a composite index has been created on the "user_level + order_seq" field. When this statement is executed, the database first quickly finds records where "user_level is VIP" using the index, then filters out records where "order_seq is in (3,5]", and finally performs a -1 update. This eliminates the risk of injection and efficiently completes batch adjustments.

[0092] The final generated security-optimized dynamic structured query statement must simultaneously meet the three requirements of "grammatically correct, secure and injection-free, and efficient execution," and retain the correspondence with the original strategy (such as parameter values ​​being traceable to the target numerical range specification and filtering conditions), providing reliable statement support for subsequent execution steps.

[0093] S204, execute the dynamic structured query statement to complete the batch record sorting value adjustment, and update the sorting value of the current record to the target sorting value.

[0094] Specifically, it can establish database connections and pre-compile security-optimized dynamic structured query statements, perform syntax checks and execution plan optimizations, and generate executable SQL statements; This step is a prerequisite for the sorting and adjustment statements to be executed. Through a stable database connection and statement optimization, it ensures that subsequent batch updates are efficient and free of syntax errors. The specific implementation is as follows: Establishing a database connection requires a standardized database connection protocol (such as JDBC for Java environments and ODBC for cross-platform environments). Connection parameters must include the database address (e.g., "localhost" represents the local database, "192.168.1.100" represents the remote server address), port number (MySQL default 3306, PostgreSQL default 5432), database name (e.g., "hospital_db" or "product_manage_db", which must be consistent with the database to which the target table belongs), authentication information (username such as "admin", password must be transmitted in encrypted form to avoid plaintext leakage), and connection attributes (e.g., "useSSL=false" disables unnecessary SSL encryption to improve connection speed, "connectTimeout=5000" sets the connection timeout to 5 seconds, and will retry 3 times if the timeout occurs). For example, the connection parameters for a MySQL database are configured as follows: address = "192.168.1.100", port = 3306, database name = "user_manage_db", username = "db_user", password = encrypted "Xy123$%^", connection attribute = "useSSL=false&connectTimeout=5000&rewriteBatchedStatements=true" (the latter enables batch execution optimization). After the connection is established, connectivity needs to be verified by sending a simple "SELECT 1" statement. If the returned result is 1, the connection is considered valid; otherwise, a connection retry mechanism is triggered (each retry is 2 seconds apart, up to 3 times) to ensure that subsequent operations are not at risk of connection interruption.

[0095] Pre-compiled security-optimized dynamic structured query statements are generated in advance and compiled into binary format by the database driver. This avoids repeatedly parsing the statement structure during each execution, thus improving execution efficiency. For example, for the statement "UPDATE task_table SET task_order = task_order + 1 WHERE task_order >= ? AND task_order < ? AND task_status = ?", during pre-compilation, the database separates the SQL keywords (such as UPDATE, SET, WHERE) from the parameter placeholders (?), compiling only the fixed structure. Subsequent execution only requires passing the parameter values. The pre-compilation process also performs preliminary syntax checks, such as checking whether keywords are spelled correctly (avoiding errors like "UPDATA"), whether parentheses are paired (e.g., "WHERE (a=1 AND b=2" will report an error if the right parenthesis is missing), and whether field names and table names conform to database identifier specifications (e.g., whether they contain illegal characters "@" or "#"). If syntax errors are found, specific error messages are returned (e.g., "field name task_order1 does not exist"), and the process needs to be corrected before re-pre-compilation.

[0096] Execution plan optimization involves the database optimizer analyzing and selecting the execution path for pre-compiled statements. The core goal is to avoid full table scans and prioritize the use of indexes to improve query speed. The optimizer analyzes the WHERE clause of the statement (e.g., "task_status = ? AND task_order >= ?"), checking for the existence of suitable indexes (e.g., a composite index "task_status + task_order"). If a suitable index exists, it selects to locate records that meet the conditions using the index (index lookup time is typically <10ms). If no suitable index exists, it assesses whether a temporary index needs to be generated (only for this execution and destroyed afterward), or whether the condition order needs to be adjusted (placing conditions with smaller filtering ranges first, such as "task_status = 'pending'" before "task_order >= 3", as status filtering can reduce the data volume by 80%). For example, if the initial execution plan for a certain statement is a full table scan (estimated to take 500ms), the optimizer, after discovering the composite index "task_status+task_order", adjusts it to an index scan (estimated to take 8ms), improving execution efficiency by more than 60 times. The optimized execution plan needs to be verified using the database's "EXPLAIN" command to ensure that the "type" field is "range" (range index scan) or "ref" (non-unique index scan), and not "ALL" (full table scan).

[0097] The final executable SQL statement is a pre-compiled binary statement bound to an optimized execution plan. It contains the compiled structure, the optimized execution path, and the position information of parameter placeholders, such as "pre-compiled statement ID: 1001, execution plan: index scan (index task_status_task_order), number of parameter placeholders: 3". Afterwards, you only need to pass in the specific parameter values ​​(such as 3, 5, 'pending') to execute it directly without further parsing and optimization.

[0098] Execute executable SQL statements to perform batch update operations on records that meet the conditions and whose sort values ​​are within the target value range, and generate batch update execution results; This step involves executing optimized statements to adjust batch sort values ​​and recording the execution results to track the operation's effectiveness. The specific implementation is as follows: Before executing executable SQL statements, a database transaction must be started (using the "BEGIN TRANSACTION" command). The purpose of a transaction is to ensure the atomicity of batch updates—if all records are updated successfully, the transaction is committed ("COMMIT"); if any record update fails (e.g., due to a sudden power outage or record locking), the transaction is rolled back ("ROLLBACK"), avoiding inconsistent states where some records are updated while others are not. For example, if 10 records that meet certain conditions (sort values ​​3 and 4) need to be updated, and the first 8 records are updated successfully, but the 9th record fails due to a record locking issue, a rollback is triggered, restoring the sort values ​​of the first 8 records to their original values, ensuring data consistency. The transaction isolation level should be set to "READ COMMITTED" to prevent other transactions from modifying or reading uncommitted updated data during execution, which could lead to data corruption.

[0099] During execution, parameter placeholders need to be replaced with specific values ​​(extracted from the standardized dynamic parameter set). The replacement must strictly match the placeholder order. For example, if the three placeholders in the statement correspond to "target sort value newSort=3", "original sort value oldSort=5", and "filter condition value='pending'", then the passed parameter list would be [3, 5, 'pending']. The database driver combines the parameter values ​​with the prepared statement to generate the final binary instruction to be executed and sent to the database server. Execution progress needs to be monitored. For updates of a large number of records (e.g., more than 1000), a batch execution strategy (500 records per batch) is adopted to avoid excessive database resource consumption and timeouts in a single execution. For example, 1200 records can be executed in three batches (500 + 500 + 200), with a 100ms pause after each batch to balance execution efficiency and resource consumption.

[0100] Batch update execution results must include core statistical information and status indicators: execution status ("success" or "failure"), number of affected records (the number of records that met the conditions and were actually updated; for example, if 2 records were expected to be updated, then 2 records were actually updated), reason for failure (if execution fails, specific error information must be recorded, such as "record locked (ID: 10086)" or "parameter type mismatch"), and execution time (the total time from sending the command to receiving the result, such as 50ms). For example, the execution result of a batch update is: execution status = "success", number of affected records = 2 (1 record each for sort values ​​3 and 4), reason for failure = "none", and execution time = 45ms. If execution fails (e.g., number of affected records = 0), a cause investigation should be automatically triggered (checking whether the filter conditions match records and whether records exist in the sort value range), and an investigation report should be generated (e.g., "no matching records for filter condition task_status='pending'; it is recommended to check the validity of the condition") to provide a basis for subsequent manual intervention.

[0101] The execution results need to be persistently stored in the operation log table (e.g., "sort_adjust_log"). The log table contains the operation timestamp (accurate to milliseconds, e.g., "2025-10-28 15:30:45.123"), the operator (e.g., "admin"), the target table name ("task_table"), the execution statement (the anonymized statement, with parameter placeholders replaced by "?"), and the execution result (the above statistical information). This facilitates subsequent auditing and problem tracing. For example, if the reason for a certain sorting adjustment needs to be checked 3 months later, the operation details can be quickly located through the log table.

[0102] The current record update statement is constructed based on a standardized set of dynamic parameters, and the sort value of a specific record is accurately updated to the target sort value to generate the current record update statement. This step completes the final core operation of sorting adjustment by accurately locating the current record and updating its sort value, avoiding the omission of key records in batch updates. The specific implementation is as follows: The standardized set of dynamic parameters contains all the information needed to construct the update statement for the current record: the target table name (e.g., "user_info"), the sort field name (e.g., "sort_num"), the record filter condition (e.g., "dept_id=101 AND username='zhangsan'", used to uniquely identify the current record), the original sort value oldSort (e.g., 3, used to further limit the current record and avoid accidentally updating other records), and the target sort value newSort (e.g., 5, the final sort value to be updated). The statement must follow the format "UPDATE table_name SET sort_field=newSort WHERE filter_condition AND sort_field=oldSort", where "sort_field=oldSort" is the key constraint—even if the filter condition matches multiple records for some reason (e.g., "dept_id=101" matches 10 records), this condition ensures that only the current record with the original sort value oldSort is updated, avoiding accidental operations.

[0103] For example, if the standardized dynamic parameter set is: target table name = "user_info", sort field = "sort_num", filter condition = "dept_id=101 AND username='zhangsan'", oldSort=3, newSort=5, then the constructed current record update statement is "UPDATE user_info SET sort_num = 5 WHERE dept_id = 101 AND username = 'zhangsan' AND sort_num = 3". If oldSort is NULL (in the case of adding a new record), the statement is simplified to "UPDATE user_info SET sort_num = 2 WHERE dept_id = 101 AND username='lisi'" (without the "sort_num=NULL" condition, because the new record has not yet been assigned a sort value, and the filter condition must ensure unique identification of the new record, such as through a unique identifier field like "user_id=1001").

[0104] During the construction process, statement validity validation is required: Check if table names and field names contain backticks (to avoid conflicts with database keywords; for example, the table name "order" must contain backticks), whether `newSort` is a valid integer (e.g., 5, 10, excluding negative or decimal numbers), and whether the filter conditions include unique identifier fields (e.g., "user_id" for user tables, "product_id" for product tables). If the filter conditions lack unique identifiers (e.g., only "dept_id=101"), then a timestamp condition like "create_time='2025-10-28 10:00:00'" is automatically added to ensure unique matching records. For example, if the filter condition is only "dept_id=101", it is added as "dept_id=101 AND create_time='2025-10-28 10:00:00'", where the timestamp is extracted from the "record creation time" field of the standardized parameter set, ensuring that only the currently updated record is matched.

[0105] The generated current record update statement needs to be verified by a syntax checking tool (such as the database's built-in "CHECK SQLSYNTAX" function). For example, it checks whether the "SET" keyword is missing, whether the WHERE clause is complete, and whether the quotation marks are paired. If there is a syntax error (such as "zhangsan" not being enclosed in single quotes in "SET sort_num = 5 WHERE dept_id = 101 AND username=zhangsan"), it will be automatically corrected (single quotes added) and re-verified until the statement syntax is completely correct, to avoid failure due to syntax errors during execution.

[0106] Execute the update statement for the current record and verify the continuity and uniqueness of the sort values ​​across the entire table to ensure the complete reconstruction of the sort sequence, and generate a sort adjustment completion report.

[0107] This step ensures the completeness and correctness of the sorting adjustment by performing a final update and full table validation, and generates a report for future reference. The specific implementation is as follows: Executing the current record update statement requires using the database connection and transaction mechanism established in step two. If the batch update in step two has been committed, a new transaction is started to execute the current statement; if the transaction in step two has not been committed (e.g., in a batch execution scenario), it is included in the same transaction and committed uniformly. During execution, exceptions thrown by the database (such as "record does not exist" or "insufficient permissions") must be caught. For example, when executing the statement "UPDATE user_info SET sort_num=5 WHERE dept_id=101 AND username='zhangsan' AND sort_num=3", if the record does not exist because it has been deleted, the database returns a "1062 - Duplicate entry" error, triggering retry logic (re-querying whether the record exists; if it exists, reconstructing the statement; if it does not exist, prompting the user "target record has been deleted, cannot be updated"). After successful execution, use the "SELECT ROW_COUNT ()" command to get the number of affected records. If the number of affected records = 1, the update is considered successful (the current record sort value has become newSort). If the number of affected records = 0, the update is considered to have failed, and the statement and record status need to be checked again.

[0108] Verifying the continuity and uniqueness of the sorted values ​​across the entire table is crucial to ensuring that the sorted sequence is free of duplicates and gaps. The verification scope is "all records in the target data table that meet the record filtering conditions" (not the entire table, to avoid interference from irrelevant records). Uniqueness verification is achieved through the query "SELECT COUNT (sort_num) AS total, COUNT(DISTINCT sort_num) AS distinct_total FROM target_table WHERE filter_condition". If "total = distinct_total", then there are no duplicate sorted values ​​(e.g., if there are 5 records that meet the conditions, distinct_total=5, no duplicates); if "total > distinct_total", then there are duplicates (e.g., if total=5, distinct_total=4, there is 1 duplicate value). Duplicate records need to be located (through the query "SELECT sort_num, GROUP_CONCAT(user_id) FROM target_table WHERE filter_condition GROUP BY sort_num HAVING COUNT (*) > 1") and corrected (e.g., by incrementing the duplicate sorted value by 1).

[0109] Continuity verification is for scenarios where the sorted values ​​are consecutive integers (default design). It is implemented through the query "SELECT MIN(sort_num) AS min_sort, MAX(sort_num) AS max_sort, COUNT(sort_num) AS total FROM target_table WHERE filter_condition". If "max_sort - min_sort + 1 = total", then it is considered continuous (e.g., min_sort=2, max_sort=5, total=4, 5-2+1=4, continuous). If "max_sort - min_sort + 1 > total", then there is a gap (e.g., min_sort=2, max_sort=5, total=3, there is 1 gap). The gap position needs to be located (manually or automatically checked using "SELECT sort_num FROM target_table WHERE filter_condition ORDER BY sort_num, e.g., missing 3) and corrected (the sorted value greater than the gap value is reduced by 1). For example, if a verification result is min_sort=2, max_sort=5, total=3, and it is found that the value 3 is missing, then the sorting values ​​4 and 5 will be updated to 3 and 4 respectively to restore the sequence to continuity.

[0110] The sorting adjustment completion report needs to integrate all operation information, including basic information (operation time, operator, target table name, sorting field name), adjustment details (number of records affected by batch update, sorting values ​​of the current record before and after update, filter conditions), verification results (whether uniqueness passed, whether continuity passed, whether correction exists), and abnormal records (if there are duplicates or gaps, list the specific record ID and sorting value). For example, a report might read: "Operation time: 2025-10-28 15:35:20; Operator: admin; Target table: user_info; Sort field: sort_num; Filter conditions: dept_id=101; Batch update: affected 2 records (sorting values ​​3→4, 4→5); Current record update: username='zhangsan', oldSort=3→newSort=5; Verification results: uniqueness passed (total=5, distinct_total=5), continuity passed (min=2, max=5, total=4, 5-2+1=4); abnormal records: none." The report is stored in a structured format (such as JSON or XML) in a report table ("sort_adjust_report"), and a PDF file is also generated for download, supporting subsequent review and auditing by medical staff or administrators.

[0111] As can be seen, the system receives a dynamic parameter set that includes at least record filtering conditions, original sort values, and target sort values; it generates a batch sort value adjustment strategy based on the comparison results of the original sort values ​​and the target sort values, combined with the record filtering conditions; it constructs a dynamic structured query statement based on the batch sort value adjustment strategy, and the statement limits the sort value update to records that meet the record filtering conditions and whose sort values ​​are within a specified numerical range; it executes the dynamic structured query statement to complete the batch record sort value adjustment and updates the sort value of the current record to the target sort value, thereby improving the efficiency and reliability of data maintenance.

[0112] Another embodiment of the present invention provides a flexible and universal sorting adjustment implementation system, see [link to relevant documentation]. Figure 3 The system may include: The receiving module 301 is used to receive a dynamic parameter set that includes at least record filtering conditions, original sorting values ​​and target sorting values; The generation module 302 is used to generate a batch adjustment strategy for sorting values ​​based on the comparison result between the original sorting value and the target sorting value, combined with the record filtering conditions. The strategy includes uniformly increasing or decreasing the sorting values ​​of records within a specified numerical range. The construction module 303 is used to construct a dynamic structured query statement based on the batch adjustment strategy of the sort value. The statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is located in the specified value range. The adjustment module 304 is used to execute the dynamic structured query statement to complete the batch record sorting value adjustment and update the sorting value of the current record to the target sorting value.

[0113] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0114] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0115] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0116] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A flexible and universal sorting adjustment method, characterized in that, The method includes: Receive a dynamic parameter set that includes at least the record filtering criteria, the original sort value, and the target sort value; Based on the comparison results between the original sort value and the target sort value, and in conjunction with the record filtering conditions, a batch adjustment strategy for sort values ​​is generated. The strategy includes uniformly increasing or decreasing the sort values ​​of records within a specified numerical range. A dynamic structured query statement is constructed based on the batch adjustment strategy of the sort value. The statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is within the specified value range. The dynamic structured query statement is executed to adjust the sort values ​​of a batch of records and update the sort value of the current record to the target sort value.

2. The method according to claim 1, characterized in that, The receiving process includes at least a dynamic parameter set comprising record filtering conditions, original sort values, and target sort values, including: The system receives the target data table name, sorting field name, record filtering conditions, original sorting value and target sorting value provided by the user through the parameter input interface, and generates the original parameter set. Perform format validation on the original parameter set, verify whether the target data table name and sorting field name conform to the database identifier specification, whether the record filtering conditions are valid SQL expressions, and whether the original sorting value and the target sorting value are valid integer values ​​or null values, and generate a parameter set that passes the validation. Based on the validated parameter set, the field references and value types in the record filtering conditions are parsed to eliminate potential security risks and optimize the condition expression structure, generating a security-optimized condition expression. The conditional expression for security optimization is standardized and assembled with the target data table name, sorting field name, original sorting value, and target sorting value to generate a standardized set of dynamic parameters.

3. The method according to claim 2, characterized in that, The step of generating a batch adjustment strategy for sorting values ​​based on the comparison result between the original sorting value and the target sorting value, combined with the record filtering conditions, includes performing a uniform increment or decrement operation on the sorting values ​​of records within a specified numerical range, including: The original and target sorting values ​​are extracted from a standardized set of dynamic parameters, and numerical comparisons and null value checks are performed to generate sorting value relationship analysis results. Based on the analysis results of the sorting value relationship, combined with the conditional expression for security optimization, the specific scenarios for sorting adjustment are determined. These scenarios include adding new records, ascending order adjustment, or descending order adjustment, and sorting adjustment scenario definitions are generated. Based on the definition of the sorting adjustment scenario, calculate the boundary of the sorting value interval that needs to be adjusted, clarify the opening and closing characteristics of the interval, and generate the target value interval specification. Based on the target value range specification and the definition of sorting adjustment scenarios, a specific sorting value adjustment operation plan is formulated, including the increment or decrement magnitude and direction, and a batch sorting value adjustment strategy is generated.

4. The method according to claim 3, characterized in that, The dynamic structured query statement constructed based on the batch adjustment strategy of the sort value, wherein the statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is within a specified numerical range, includes: Extract the target value range specification and adjustment operation scheme from the batch adjustment strategy of sorting values, and construct the basic update statement structure by combining the target data table name and sorting field name in the standardized dynamic parameter set; By incorporating security-optimized conditional expressions into the basic update statement structure, a condition-limited update statement framework is formed, ensuring that operations are performed only on records that meet the conditions. Based on the adjustment operation plan, add a sorting field update expression to the condition-defined update statement framework, clarify the increment or decrement operation logic, and generate a complete update statement template. The system performs parameter binding and statement optimization on the complete update statement template, eliminating SQL injection vulnerabilities and improving query efficiency, generating secure and optimized dynamic structured query statements.

5. The method according to claim 4, characterized in that, The step of executing the dynamic structured query statement to adjust the sort values ​​of batch records and updating the sort value of the current records to the target sort value includes: Establish database connections and pre-compile security-optimized dynamic structured query statements, perform syntax checks and execution plan optimizations, and generate executable SQL statements; Execute executable SQL statements to perform batch update operations on records that meet the conditions and whose sort values ​​are within the target value range, and generate batch update execution results; The current record update statement is constructed based on a standardized set of dynamic parameters, and the sort value of a specific record is accurately updated to the target sort value to generate the current record update statement. Execute the update statement for the current record and verify the continuity and uniqueness of the sort values ​​across the entire table to ensure the complete reconstruction of the sort sequence, and generate a sort adjustment completion report.

6. The method according to claim 3, characterized in that, The process of extracting original and target sorting values ​​from a standardized set of dynamic parameters, performing numerical comparisons and null value checks, and generating sorting value relationship analysis results includes: The original sorting value and the target sorting value are parsed and extracted from the standardized set of dynamic parameters to generate numerical pairs of the original sorting value and the target sorting value. Perform null value detection on the numerical pairs of the original sort value and the target sort value, determine whether the original sort value is null, and generate null value detection results; Based on the null value detection results, if the original sorted value is not null, a numerical comparison is performed to calculate the difference between the target sorted value and the original sorted value, and a numerical comparison result is generated. Integrate the null value detection results and numerical comparison results, define the sorting value relationship type, including new record, ascending order adjustment, descending order adjustment, or no adjustment, and finally generate the sorting value relationship analysis results.

7. A flexible and universal sorting adjustment implementation system, characterized in that, The system includes: The receiving module is used to receive a dynamic parameter set that includes at least record filtering conditions, original sort values, and target sort values; The generation module is used to generate a batch adjustment strategy for sorting values ​​based on the comparison result between the original sorting value and the target sorting value, combined with the record filtering conditions. The strategy includes uniformly increasing or decreasing the sorting values ​​of records within a specified numerical range. The construction module is used to construct a dynamic structured query statement based on the batch adjustment strategy of the sort value. The statement is limited to updating the sort value only for records that meet the record filtering conditions and whose sort value is within a specified value range. The adjustment module is used to execute the dynamic structured query statement to complete the batch record sorting value adjustment and update the sorting value of the current record to the target sorting value.

8. The system according to claim 7, characterized in that, The receiving module is specifically used for: The system receives the target data table name, sorting field name, record filtering conditions, original sorting value and target sorting value provided by the user through the parameter input interface, and generates the original parameter set. Perform format validation on the original parameter set, verify whether the target data table name and sorting field name conform to the database identifier specification, whether the record filtering conditions are valid SQL expressions, and whether the original sorting value and the target sorting value are valid integer values ​​or null values, and generate a parameter set that passes the validation. Based on the validated parameter set, the field references and value types in the record filtering conditions are parsed to eliminate potential security risks and optimize the condition expression structure, generating a security-optimized condition expression. The conditional expression for security optimization is standardized and assembled with the target data table name, sorting field name, original sorting value, and target sorting value to generate a standardized set of dynamic parameters.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images