A data query method, apparatus, device, medium, and product

Abstract

This application provides a data query method, apparatus, device, medium, and product, relating to the field of big data. The method obtains a query request containing a query identifier and, based on a pre-configured first association table and / or second association table, and a core data table, retrieves analysis reports, analysis records, and / or media files corresponding to the query identifier. Because the first association table, second association table, and core data table are set up, the complex many-to-many relationships between analysis records, media files, and analysis reports can be explicitly expressed, thereby enabling many-to-many relationship tracing capabilities. This avoids the problem in existing technologies where the relationship is only implicit in filename conventions or application layer logic, requiring multiple independent searches and path concatenations to obtain all related data, thus improving data query efficiency.

Description

Technical Field

[0001] This application relates to the field of big data, and in particular to a data query method, apparatus, device, medium, and product. Background Technology

[0002] During the research and development testing of imaging equipment, each test generates a large number of raw media files (images, videos) and corresponding analysis results. A complete testing cycle may include hundreds to thousands of images, dozens of video clips, and analysis reports generated from multimodal large models. In existing technologies, a large number of raw media files, corresponding analysis results, and related analysis reports are generally stored directly in a single directory on a server.

[0003] When operators need to query analysis records and reports, especially when performing batch queries, they need to perform multiple independent queries and manually concatenate them to obtain all associated analysis records, original media files, and / or analysis reports, resulting in low query efficiency. Summary of the Invention

[0004] This application provides a data query method, apparatus, device, medium, and product to solve the technical problem of low data query efficiency in the prior art.

[0005] In a first aspect, embodiments of this application provide a data query method, including:

[0006] Obtain a query request; wherein the query request includes a query identifier;

[0007] According to the query request, query the pre-configured first association table and / or second association table, as well as the core data table, to obtain the analysis report, analysis record and / or media file corresponding to the query identifier;

[0008] The first association table is used to record the association between analysis records and media files, the second association table is used to record the association between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

[0009] In one possible implementation, the step of querying a pre-configured first association table and / or second association table, as well as a core data table, according to the query request to obtain analysis reports, analysis records, and / or media files corresponding to the query identifier includes:

[0010] Based on the object-relational mapping framework, a preloading strategy is used to query a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, so as to obtain the analysis report, analysis record and / or media file corresponding to the query identifier in a single query.

[0011] In one possible implementation, if the identifier to be queried is a batch identifier, then the step of querying a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query, includes:

[0012] Based on the query request, query the analysis record table to obtain the analysis record corresponding to the batch identifier, as well as the identifier of each analysis record;

[0013] Query the first association table to obtain the identifier of the media file corresponding to the identifier of each analysis record;

[0014] The media file table is queried to obtain the data information of the media file corresponding to the identifier of each media file, and the media file is obtained based on the data information of the media file;

[0015] Query the analysis batch table to obtain the identifier of the analysis report corresponding to the batch identifier, and query the analysis report table to obtain the analysis report corresponding to the identifier of the analysis report.

[0016] In one possible implementation, if the identifier to be queried is an analysis record identifier, then the step of querying a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query, includes:

[0017] Based on the query request, query the analysis record table to obtain the analysis record corresponding to the analysis record identifier, and the identifier of the analysis record;

[0018] Query the first association table to obtain the identifier of the media file corresponding to the identifier of the analysis record;

[0019] The media file table is queried to obtain the data information of the media file corresponding to the identifier of the media file, and the media file is obtained based on the data information of the media file.

[0020] In one possible implementation, if the identifier to be queried is the identifier of an analysis report, then the step of querying a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query, includes:

[0021] Based on the query request, query the analysis report table and the second association table respectively to obtain the identifiers of the analysis report and the analysis record corresponding to the identifier of the analysis report;

[0022] Query the analysis record table to obtain the analysis record corresponding to the identifier of the analysis record.

[0023] In one possible implementation, the first association table includes multiple first records, each first record including an identifier of the analysis record, an identifier of the media file, and an association role type;

[0024] The associated role type is used to characterize the role of the media file in the analysis record as an analysis object, a reference comparison object, or a report file.

[0025] In one possible implementation, the second association table includes multiple second records, each second record including an identifier for the analysis record, an identifier for the analysis report, and an identifier for the association order;

[0026] The identifier of the association order is used to characterize the display order of the analysis records in the analysis report.

[0027] In one possible implementation, the data query method further includes:

[0028] Retrieve the media file to be stored;

[0029] According to the hierarchical storage strategy, the target storage directory is constructed according to the hierarchical structure to store the media files to be stored hierarchically, and the data information of the media files is obtained to store the data information of the media files in the media file table;

[0030] The data information of the media file includes the media file's metadata and storage information;

[0031] The metadata includes one or more of the following combinations: media file identifier, media file type, media file size, media file role marker, media file characteristic information, and hash value;

[0032] The storage information includes the filename of the stored media and its relative storage path.

[0033] In one possible implementation, the data query method further includes:

[0034] Calculate the hash value of the media file to be stored, and compare the hash value with the hash values ​​already stored in the media file table;

[0035] The step of constructing the target storage directory according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored hierarchically includes:

[0036] When the hash value is found to be different from the hash value already stored in the media file table, the target storage directory is constructed according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored hierarchically.

[0037] In one possible implementation, the step of constructing the target storage directory according to a hierarchical structure based on a hierarchical storage strategy to store the media files to be stored hierarchically includes:

[0038] Based on the date-based bucketing storage strategy, the target storage directory is constructed according to the time hierarchy to store the media files to be stored in a hierarchical manner.

[0039] In one possible implementation, the data query method further includes:

[0040] The preset storage root directory, the target storage directory, and the media file name are concatenated to obtain the original storage path of the media file to be stored;

[0041] The original storage path is converted into a string and the leading and trailing whitespace characters of the string are removed to obtain a path object;

[0042] The path object is converted into a candidate relative path, and the candidate relative path is parsed to obtain the parsed path;

[0043] If the parsed path is within the preset storage root directory, then the candidate relative path is determined as the relative storage path of the media file, so that the media file to be stored is stored according to the relative storage path.

[0044] In one possible implementation, converting the path object into a candidate relative path includes:

[0045] Identify the type of the path object; wherein the type includes absolute type and relative type;

[0046] If the type is an absolute type, calculate the relative path of the path object relative to the preset storage root directory. If the relative path does not exceed the range of the preset storage root directory, then determine the relative path as the candidate relative path.

[0047] If the type is a relative type, the path object is filtered component by component to remove invalid paths containing illegal directory jump segments and redundant empty segments, thus obtaining the candidate relative path.

[0048] In one possible implementation, the data query method further includes:

[0049] Based on the type of the acquired media files, the hierarchical structure of the target storage directory is adjusted to obtain the updated storage directory;

[0050] or,

[0051] Based on the size of the obtained media files, the hierarchical structure of the target storage directory is adjusted to obtain the updated storage directory.

[0052] Secondly, embodiments of this application provide a data query device, comprising:

[0053] The acquisition module is used to acquire a query request; wherein the query request includes a query identifier;

[0054] The query module is used to query a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, in order to obtain analysis reports, analysis records, and / or media files corresponding to the identifier to be queried;

[0055] The first association table is used to record the association between analysis records and media files, the second association table is used to record the association between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

[0056] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0057] The memory stores computer-executed instructions;

[0058] When the processor executes the computer execution instructions stored in the memory, it is used to implement the data query method as described in any of the first aspects.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the data query method as described in any of the first aspects.

[0060] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the data query method as described in any of the first aspects.

[0061] This application provides a data query method, apparatus, device, medium, and product. By obtaining a query request containing a query identifier, and based on a pre-configured first association table and / or second association table, as well as a core data table, it retrieves analysis reports, analysis records, and / or media files corresponding to the query identifier. Because the first association table, second association table, and core data table are set, the complex many-to-many relationship between analysis records, media files, and analysis reports can be explicitly expressed, thereby achieving many-to-many relationship tracing capability. This avoids the problem in the prior art where the relationship is only implicit in the file name convention or application layer logic, requiring multiple independent searches and path concatenations to obtain all related data, thus improving data query efficiency. Attached Figure Description

[0062] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0063] Figure 1 This is a schematic diagram illustrating an application scenario of the data query method provided in the embodiments of this application;

[0064] Figure 2 Flowchart of the data query method provided in the embodiments of this application Figure 1 ;

[0065] Figure 3 Flowchart of the data query method provided in the embodiments of this application Figure 2 ;

[0066] Figure 4 Flowchart of the data query method provided in the embodiments of this application Figure 3 ;

[0067] Figure 5 A flowchart illustrating an example of a specific implementation method for batch-level data querying provided in the embodiments of this application;

[0068] Figure 6 Flowchart of the data query method provided in the embodiments of this application Figure 4 ;

[0069] Figure 7 A schematic diagram of a time-based hierarchical bucketed storage architecture provided in this application embodiment;

[0070] Figure 8 A flowchart for creating and associating analysis records provided in the embodiments of this application;

[0071] Figure 9 Flowchart of the data query method provided in the embodiments of this application Figure 5 ;

[0072] Figure 10 Flowchart of the data query method provided in the embodiments of this application Figure 6 ;

[0073] Figure 11 Flowchart of the data query method provided in the embodiments of this application Figure 7 ;

[0074] Figure 12 A flowchart of path normalization and security verification provided for embodiments of this application;

[0075] Figure 13 A three-tier architecture diagram for traceable storage and media resource association provided in the embodiments of this application;

[0076] Figure 14 ER diagram of the data model provided in the embodiments of this application;

[0077] Figure 15 This is a schematic diagram of the structure of the data query device provided in the embodiments of this application;

[0078] Figure 16 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0079] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0080] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0081] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0082] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the data query method, apparatus, device, medium, and product provided in the embodiments of this application are merely examples; a data query method, apparatus, device, medium, and product may also include more or less content.

[0083] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0084] To clearly understand the technical solution of this application, the solutions of existing technologies will first be described in detail. During the research and development testing of imaging equipment, each test generates a large number of raw media files (images, videos) and corresponding analysis results. A complete testing cycle may include hundreds to thousands of images, dozens of video clips, and analysis reports generated from multimodal large models. In existing technologies, a large number of raw media files, corresponding analysis results, and related analysis reports are generally stored directly in a single directory on a server.

[0085] When operators need to query analysis records and reports, especially when performing batch queries, they need to perform multiple independent queries and manually concatenate them to obtain all associated analysis records, original media files, and / or analysis reports, resulting in low query efficiency.

[0086] Therefore, addressing the issue of low data query efficiency in existing technologies, the research found that, to solve this problem: Optionally, a first association table can be pre-configured to record the relationship between analysis records and media files. This allows the media file corresponding to the query identifier to be retrieved by querying the first association table when a query request containing the query identifier is received. Optionally, a second association table can also be pre-configured to record the relationship between analysis reports and analysis records. This allows the analysis record corresponding to the query identifier to be retrieved by querying the second association table when a query request containing the query identifier is received. Optionally, the analysis record table, analysis batch table, media file table, and analysis report table can be used as core data tables in conjunction with the first and second association tables. When a query request containing the query identifier is received, the first and / or second association tables, as well as the core data tables, are queried according to the query request to obtain the analysis report, analysis record, and / or media file corresponding to the query identifier.

[0087] This application provides a data query method, apparatus, device, medium, and product. By obtaining a query request containing a query identifier, and based on a pre-configured first association table and / or second association table, as well as a core data table, it retrieves analysis reports, analysis records, and / or media files corresponding to the query identifier. Because the first association table, second association table, and core data table are set, the complex many-to-many relationship between analysis records, media files, and analysis reports can be explicitly expressed, thereby achieving many-to-many relationship tracing capability. This avoids the problem in the prior art where the relationship is only implicit in the file name convention or application layer logic, requiring multiple independent searches and path concatenations to obtain all related data, thus improving data query efficiency.

[0088] Based on the above-mentioned inventive discovery, the technical solution of this application is proposed.

[0089] The following describes the application scenarios of the data query method provided in the embodiments of the present invention. Figure 1 This is a schematic diagram illustrating an application scenario of the data query method provided in the embodiments of this application. For example... Figure 1 As shown, the application scenario includes a mobile terminal 101 and a server 102. The mobile terminal 101 receives a query request and sends the query request to the server 102. The server 102 obtains the query request and, based on the query request, queries a pre-configured first association table and / or a second association table, as well as a core data table, to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried.

[0090] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0091] Figure 2Flowchart of the data query method provided in the embodiments of this application Figure 1 .like Figure 2 As shown, the data query method provided in this embodiment includes the following steps:

[0092] Step S201: Obtain a query request; wherein, the query request includes the identifier to be queried.

[0093] In this embodiment, the system can receive a query identifier input by the user through the query interface, or receive a query identifier transmitted by the downstream system through the application programming interface, and encapsulate the query identifier into a query request. This step is used to convert the query instruction issued by the user or the downstream system into a query request that can be recognized by the background, so as to start the subsequent query process.

[0094] Step S202: Based on the query request, query the pre-configured first association table and / or second association table, as well as the core data table, to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried.

[0095] The first association table records the relationship between analysis records and media files, the second association table records the relationship between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

[0096] In this embodiment, for example, the MediaAsset table is used to manage the metadata and storage information of all media files (images, videos, reports, and derived files). The metadata includes one or more combinations of the following: the media file's identifier (unique identifier), the media file's type (e.g., image / video / report / derived), the media file's size, the media file's role marker (e.g., original file / report file / thumbnail), the media file's characteristic information (e.g., image / video dimensions, video duration, and frame rate), and a hash value (e.g., SHA256 hash value). The storage information includes the stored media file name and its relative storage path (unique index).

[0097] Optionally, the metadata may further include: the original filename and the stored filename (including the UUID prefix).

[0098] Furthermore, the association between analysis records and media files is established upon creation, and the creation time is also recorded during association establishment. The creation time is used for querying and cleanup by time range. Cascading deletion through the object-relational mapping framework ensures automatic cleanup of associations upon deletion. This media file table supports a soft deletion mechanism, which retains audit traceability capabilities.

[0099] The AnalysisRecord table manages the results of each image analysis of media files. Each record may include, but is not limited to: an analysis record identifier (unique identifier), batch association, record type (e.g., single image / video / comparison / batch item), analysis type (e.g., AI analysis / video analysis / comparison analysis), processing status, title, analysis results (e.g., storing complete JSON data in binary JSON format), analysis summary text (supporting full-text index search), snapshot of the prompt words used during analysis (ensuring result reproducibility), and creation time. The analysis summary text supports fuzzy search, enabling global keyword search across image and video analyses. In actual testing with 10,000 analysis records, the keyword search response time is <100ms. A full-text search engine for a relational database can be used instead of fuzzy search. Full-text search engines support word segmentation, synonyms, and relevance ranking, providing a better search experience. However, for image analysis summary search scenarios (data volume <100,000 records), fuzzy search already meets the <100ms response time requirement, making the cost-effectiveness of introducing an additional search engine not high.

[0100] In addition, the first and / or second association tables, as well as the core data tables, are all stored in a relational database. The relational database stores the analysis results in binary JSON format, supporting structured queries and JSON path expressions; record type and analysis type are classified in two dimensions; prompt word snapshots ensure that even if the prompt word configuration is modified later, the analysis conditions of the historical records can still be traced.

[0101] The AnalysisBatch table is used to manage the lifecycle of batch analysis tasks, including but not limited to: batch identifier, status, total number of groups, number of processed / successful / failed times, identifier of associated analysis report, and completion time.

[0102] The AnalysisReport table is used to manage the metadata of analysis reports, including but not limited to: the identifier of the associated batch, the type of analysis report, the title, and Markdown format content.

[0103] The first association table (RecordMediaLink) is a many-to-many association table, meaning it records the relationship between analysis records and media files. For example, the first association table can be represented as follows:

[0104]

[0105] The record_id field stores the identifier of a specific analysis record in the analysis record table, and the media_asset_id field stores the identifier of a specific media file in the media file table. These two fields together form a pair, indicating that "a specific analysis record references a specific media file". The relation_type field is used to identify the role of the media file in the current analysis record, such as as the main analysis object, a reference comparison file, or a report file. The sort_order field is used to control the arrangement order of multiple media files under the same analysis record, making it convenient to display them in the order specified by the user.

[0106] The first association table includes multiple first records. Each first record includes the identifier of the analysis record, the identifier of the media file, and the association role type. The association role type is used to characterize the role of the media file in the analysis record as an analysis object, a reference comparison object, or a report file.

[0107] Based on this, a single analysis record can be associated with multiple media files; a media file can also be referenced by multiple analysis records. Furthermore, by using role and sorting fields, detailed business-dimensional information is added to the relationships, allowing queries to obtain not only the identifier of the associated entity but also the specific role and display order of that association within the analysis process.

[0108] The second association table (ReportRecordLink) is also a many-to-many association table, used to record the relationship between analysis reports and analysis records. For example, the second association table can be represented as follows:

[0109]

[0110] The report_id field stores the identifier of a specific analysis report in the analysis report table, and the record_id field stores the identifier of a specific analysis record in the analysis record table. These two fields together form a pairing relationship, expressing the reference relationship that "a specific analysis report references a specific analysis record". The sort_order field stores the identifier of the association order of each analysis record, which is used to control the arrangement order of multiple analysis records under the same analysis report, making it convenient to display them according to the analysis order or importance.

[0111] The second association table includes multiple second records. Each second record includes an identifier for the analysis record, an identifier for the analysis report, and an identifier for the association order. The identifier for the association order is used to characterize the display order of the analysis records in the analysis report.

[0112] The second association table explicitly stores the many-to-many associations between analysis reports and analysis records by pairing record identifiers. That is, one analysis report can summarize multiple analysis records, and one analysis record can be referenced by multiple analysis reports. At the same time, the association order identifier controls the display order of each analysis record within the same analysis report, so that when querying, you can not only obtain the complete reference relationship between analysis reports and analysis records, but also present the list of referenced analysis records in a specified order.

[0113] In this embodiment, by obtaining a query request containing the identifier to be queried, and based on the pre-configured first association table and / or second association table, as well as the core data table, the analysis report, analysis record, and / or media file corresponding to the identifier to be queried are obtained. Since the first association table, second association table, and core data table are set, the complex many-to-many relationship between analysis records, media files, and analysis reports can be explicitly expressed, thereby realizing the ability to trace many-to-many relationships. This avoids the problem in the prior art where the relationship is only implicit in the file name convention or application layer logic, requiring multiple independent searches and path concatenations to obtain all the related data, thus improving the data query efficiency.

[0114] Figure 3 Flowchart of the data query method provided in the embodiments of this application Figure 2 In the above Figure 2 Based on the illustrated embodiments, as Figure 3 As shown, step S202 is implemented as follows:

[0115] Step S2021: Based on the preloading strategy of the object relational mapping framework, query the pre-configured first association table and / or second association table, as well as the core data table, according to the query request, so as to obtain the analysis report, analysis record and / or media file corresponding to the query identifier in a single query.

[0116] In this embodiment, the preloading capability built into the object-relational mapping framework can be used to declare the related data tables to be retrieved when constructing the query statement. The framework will automatically generate a query statement that links multiple tables, and retrieve all business data scattered across multiple data tables through a single database interaction. This eliminates the need for business code to initiate queries layer by layer, avoiding the overhead of multiple network round trips and repeated database parsing and execution of Structured Query Language (SQL) caused by layer-by-layer queries. It also eliminates the need to manually assemble the mapping relationship between each query result at the application layer.

[0117] When performing batch-level, record-level, or report-level traceability queries based on batch identifiers, the preloading strategy of the Object-Relational Mapping (ORM) framework can be used to merge them into a single database query operation.

[0118] For example, when performing batch-level traceability queries, when constructing a query for the analysis record table, by declaring a preload path, the ORM framework will automatically add multiple LEFT JOIN clauses to the generated SQL, completing the join query between the analysis record table and the first associated table, the media file table, the analysis batch table, and the analysis report table in a single SQL statement. The database returns all analysis records under the batch and their associated media file identifiers, media file metadata, batch information, and analysis reports at once.

[0119] Without using a preloading strategy, retrieving all analysis records and their associated data starting from the batch identifier requires executing multiple independent database queries layer by layer along the data chain. First, the analysis record table needs to be queried to obtain all analysis records under that batch. Assuming the batch contains N analysis records, then these N records need to be traversed, querying the first association table for each record to obtain its associated media file identifier, then querying the media file table based on the media file identifier to obtain the file data, and simultaneously querying the analysis batch table to obtain the report identifier, and finally querying the analysis report table to obtain the report content. Each analysis record triggers multiple independent database query operations, resulting in a total of 1 (batch record query) + N (each record query to the first association table) + N (each record query to the media file table) + 1 (batch report identifier query) + 1 (report identifier query to the report table), i.e., 2N + 3 queries. When N is 100, 203 independent database queries are required.

[0120] These 200+ queries made round trips between the database server and the application server, each round trip incurring network transmission time. In modern application architectures, databases are typically deployed on dedicated servers, and each network round trip between the application server and the database server consumes at least 1 to several milliseconds. The cumulative network latency of 200 round trips reaches hundreds of milliseconds. Simultaneously, the database server needs to perform parsing, syntax checking, query optimization, permission verification, and execution plan generation for each individual SQL statement. Each query has its fixed parsing overhead, and the cumulative parsing and optimization time for 200 queries far exceeds that of a single query. Furthermore, after each query result set is returned, the application layer needs to manually concatenate and assemble the data scattered across different query results according to their relationships in memory. This process requires writing additional code logic to maintain the mapping relationships between the data, increasing code complexity and the probability of errors.

[0121] With the preloading strategy, all the data retrieval operations mentioned above are merged into a single SQL statement. The database only needs to perform query parsing and optimization once, establish a database connection only once, and return all data to the application layer only once via network round trip. Regardless of whether the batch contains 100 or 1000 analysis records, the number of queries, network round trips, and database connection overhead remains constant at 1. Even if a single query contains multiple LEFT JOINs, the database optimizer can select the optimal JOIN order and access path based on the information, resulting in an overall execution efficiency far exceeding the cumulative time consumed by more than 200 independent queries.

[0122] Another value of the preloading strategy lies in its elimination of the problem of query counts increasing linearly with data volume. In traditional step-by-step querying, query overhead is directly proportional to the number of analyzed records within a batch, and query performance continuously deteriorates as the test scale expands. However, under the preloading strategy, since all related data can be returned completely through a single database query, the number of SQL statements involved in this query remains constant at one, not increasing with the number of analyzed records within a batch. The number of database connections and network round trips also remain constant at one. Therefore, query overhead remains essentially constant as the number of records increases, and query response time does not significantly increase with the increase in the number of analyzed records in a single batch. This means that in image analysis scenarios, even if a single batch contains thousands of images and corresponding analysis records, when a user queries all related data starting from the batch identifier, they can still obtain complete results within a constant and controllable time. Data query capability will not become a bottleneck due to the increase in links in the tracing chain.

[0123] In this embodiment, by adopting the preloading strategy of the object-relational mapping framework, the database queries that originally needed to be executed multiple times independently are merged into a single query operation. This significantly reduces database connection overhead, network round-trip latency, and query parsing costs, effectively avoiding the N+1 problem in traditional step-by-step queries where the number of queries increases linearly with the amount of associated data. This allows the complete associated data link to be obtained in a constant number of times and within a controllable time, regardless of how many analysis records are contained in the batch. This greatly improves data query efficiency, especially in batch analysis and multi-level association tracing scenarios, where the overall query response time can be reduced by more than an order of magnitude.

[0124] Figure 4 Flowchart of the data query method provided in the embodiments of this application Figure 3 In the above Figure 3 Based on the illustrated embodiments, as Figure 4 As shown, if the identifier to be queried is the batch identifier, then the specific implementation method of step S2021 is as follows:

[0125] Step S20211: Based on the query request, query the analysis record table to obtain the analysis record corresponding to the batch identifier, as well as the identifier of each analysis record.

[0126] In this embodiment, the analysis record table can be queried according to the batch identifier to obtain all analysis records under that batch identifier, and the identifier can be read from each analysis record. At the same time, the first association table, media file table, and analysis batch table can be preloaded for further subsequent queries.

[0127] Step S20212: Query the first association table to obtain the identifier of the media file corresponding to the identifier of each analysis record.

[0128] In this embodiment, the identifier of each analysis record can be used as the query condition to query the preloaded first association table and obtain all media file identifiers associated with the analysis record.

[0129] Step S20213: Query the media file table, obtain the data information of the media file corresponding to the identifier of each media file, and obtain the media file based on the data information of the media file.

[0130] In this embodiment, for example, the data information of a media file includes the media file's metadata and storage information. The metadata includes one or more combinations of the following: the media file's identifier, media file type, media file size, media file role marker, media file characteristic information, and hash value. The storage information includes the stored media file name and its relative storage path. Therefore, based on the media file identifier, a query can be performed in a pre-loaded media file table to obtain data such as the relative storage path and size of each media file, and then the media file can be retrieved according to the relative storage path.

[0131] Step S20214: Query the analysis batch table to obtain the identifier of the analysis report corresponding to the batch identifier, and query the analysis report table to obtain the analysis report corresponding to the identifier of the analysis report.

[0132] In this embodiment, based on the batch identifier, a query can be performed in the preloaded analysis batch table to obtain the identifier of the analysis report corresponding to the batch identifier, and based on the identifier of the analysis report, a query can be performed in the analysis report table to obtain the analysis report corresponding to the identifier of the analysis report.

[0133] In addition, for example, Figure 5 A flowchart illustrating an example of a specific implementation method for batch-level data querying provided in the embodiments of this application is shown below. Figure 5As shown, starting with the batch identifier `batch_id` as the query input, the process first queries `AnalysisBatch` to obtain the batch information, which includes the batch identifier and the identifier of the associated report. Then, based on the batch identifier, it queries `AnalysisRecord` to filter out all analysis records and their identifiers within the batch. Based on this, the process unfolds in parallel along two related links. One link, based on the identifier of each analysis record, obtains the media file identifier associated with each analysis record through `RecordMediaLink`, and then obtains the metadata and storage information of each media file through `MediaAsset` based on the media file identifier, finally retrieving the media file based on its storage information. The other link, based on the identifier of the associated report, obtains the analysis report corresponding to the batch through `AnalysisReport`, and then obtains the storage information of the analysis report through the `MediaAsset` media file table, finally retrieving the analysis report based on its storage information. After both links complete data aggregation, the batch information, all analysis records, all media files associated with each record, and the analysis report are integrated and output, forming a complete traceability link: batch → analysis record → media file → analysis report.

[0134] Additionally, queries S20211 through S20214 can be merged into a single database query operation using the preloading strategy of the Object-Relational Mapping (ORM) framework. When constructing a query for the analysis record table, by declaring the preloading path, the ORM framework automatically adds multiple LEFT JOIN clauses to the generated structured query language, completing the join query between the analysis record table and the first associated table, media file table, analysis batch table, and analysis report table in a single SQL statement. The database returns all analysis records under the batch, along with their associated media file identifiers, media file metadata, batch information, and analysis reports, all at once.

[0135] Without using a preloading strategy, retrieving all analysis records and their associated data starting from the batch identifier requires executing multiple independent database queries layer by layer along the data chain. First, the analysis record table needs to be queried to obtain all analysis records under that batch. Assuming the batch contains N analysis records, then these N records need to be traversed, and for each record, the first association table needs to be queried to obtain its associated media file identifier. Then, based on the media file identifier, the media file table needs to be queried to obtain the file data. Simultaneously, the analysis batch table needs to be queried to obtain the report identifier, and then the analysis report table needs to be queried to obtain the report content. Each analysis record triggers multiple independent database query operations, and the number of queries increases with the number of analysis records.

[0136] Multiple queries result in multiple network round trips between the database and the application server, generating considerable network transmission time. The database server needs to perform parsing, syntax checking, query optimization, and permission verification for each independent SQL statement, incurring additional parsing overhead. Meanwhile, the application layer also needs to manually perform data concatenation and mapping of multiple query results, increasing code complexity and making it easy to introduce logical errors.

[0137] By adopting the preloading strategy, all the above data retrieval logic is consolidated into a single SQL statement. The database performs query parsing and optimization only once, requiring only one database connection and one network round trip to return all results to the application layer. The preloading strategy eliminates the drawback of the number of queries increasing linearly with the amount of data. Even if the number of records analyzed within a batch continues to increase, the number of SQL statements and the number of network round trips remain constant, the query overhead is controllable, and performance degradation will not occur due to the length of the tracing path, achieving efficient retrieval of complete and related data at the batch level.

[0138] The complex many-to-many relationship between analysis records, media files, and analysis reports is explicitly expressed using the first and second association tables. Batch-level queries can retrieve the complete relationship chain (batch → analysis record → media file → analysis report) in a single SQL operation. In actual testing with 100 batch analysis groups, the batch-level query time was <50ms, compared to >500ms for the manual concatenation method. Therefore, explicitly expressing the complex many-to-many relationship using the first and second association tables effectively improves data query efficiency.

[0139] In this embodiment, the identifier to be queried is the batch identifier. Based on the pre-configured first association table, analysis record table, media file table, and analysis batch table, a single query can obtain analysis records, media files, and analysis reports based on the batch identifier. This effectively obtains the complete association chain of batch → record → media → report through a single database operation, thereby realizing batch-level traceability query. That is, all related data can be traced with one click from the batch identifier, avoiding the N+1 query problem and effectively improving data query efficiency.

[0140] Furthermore, in the above Figure 3 Based on the illustrated embodiment, if the identifier to be queried is the analysis record identifier, then step S2021 is specifically implemented as follows:

[0141] Step S20215: Based on the query request, query the analysis record table to obtain the analysis record corresponding to the analysis record identifier, as well as the identifier of the analysis record.

[0142] In this embodiment, the analysis record can be retrieved from the preloaded analysis record table based on the analysis record identifier, and the identifier can be directly read from the analysis record for subsequent related queries.

[0143] Step S20216: Query the first association table to obtain the identifier of the media file corresponding to the identifier of the analysis record.

[0144] In this embodiment, the identifier of the analysis record can be used as a query condition to query the preloaded first association table to obtain the identifiers of all media files associated with the analysis record. The first association table stores the mapping relationship between analysis records and media files. Through this table, the identifiers of one or more media files corresponding to the identifier of the analysis record can be obtained.

[0145] Step S20217: Query the media file table to obtain the data information of the media file corresponding to the media file identifier, and obtain the media file based on the media file data information.

[0146] In this embodiment, the media file can be retrieved by querying the preloaded media file table based on the media file's identifier, obtaining the data information of the media file corresponding to the media file's identifier, and then retrieving the media file based on the storage information in the media file's data information.

[0147] In this embodiment, the identifier to be queried is the analysis record identifier. Based on the pre-configured first association table, analysis record table, and media file table, in a single query, the corresponding analysis record and media file can be obtained based on the analysis record identifier. This effectively obtains the complete association link of analysis record → media file through a single database operation, thereby realizing record-level traceability query, that is, tracing all related data from the analysis record identifier with one click, avoiding the N+1 query problem, and effectively improving data query efficiency.

[0148] Furthermore, in the above Figure 3 Based on the illustrated embodiment, if the identifier to be queried is the identifier of the analysis report, then step S2021 is specifically implemented as follows:

[0149] Step S20218: Based on the query request, query the analysis report table and the second association table respectively to obtain the identifiers of the analysis report and the analysis record corresponding to the identifier of the analysis report.

[0150] In this embodiment, queries can be performed in the preloaded analysis report table and the second association table based on the identifier of the analysis report. The analysis report table is queried to obtain the analysis report, and the second association table is queried to obtain the identifiers of all analysis records associated with the analysis report.

[0151] Step S20219: Query the analysis record table and obtain the analysis record corresponding to the identifier of the analysis record.

[0152] In this embodiment, the analysis record corresponding to the analysis record can be retrieved by querying the preloaded analysis record table based on the identifier of the analysis record obtained in step S20218.

[0153] In this embodiment, the identifier to be queried is the identifier of the analysis report. Based on the pre-configured analysis report table, second association table, and analysis record table, a single query can obtain the content of the analysis report and all details of its associated analysis records based on the analysis report identifier. This effectively obtains the complete association link from analysis report to analysis record through a single database operation, thereby realizing report-level traceability query, that is, tracing all associated analysis records from the analysis report identifier with one click, avoiding the N+1 query problem, and effectively improving data query efficiency.

[0154] Figure 6 Flowchart of the data query method provided in the embodiments of this application Figure 4 In the above Figure 2 Based on the illustrated embodiment, the method may further include:

[0155] Step S601: Obtain the media file to be stored.

[0156] In this embodiment, media file data submitted by the client via the HTTP file upload protocol can be received, and the binary content and original file name of the file can be parsed from the HTTP request. The binary content of the file can be temporarily stored in a memory buffer or temporary directory for subsequent processing. This step is used to provide the data source of the media file for subsequent hierarchical storage operations.

[0157] Step S602: According to the hierarchical storage strategy, construct the target storage directory according to the hierarchical structure to store the media files to be stored in a hierarchical manner, and obtain the data information of the media files to store the data information of the media files in the media file table.

[0158] The data information of a media file includes its metadata and storage information.

[0159] Metadata includes one or more of the following combinations: media file identifier, media file type, media file size, media file role marker, media file characteristic information, and hash value.

[0160] Storage information includes the filename of the stored media and its relative storage path.

[0161] Optionally, in S602, a specific implementation of constructing the target storage directory according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored in a hierarchical manner is as follows:

[0162] Based on the date-based bucketing storage strategy, the target storage directory is constructed according to the time hierarchy to store the media files to be stored in a hierarchical manner.

[0163] In this embodiment, after obtaining the media file to be stored, the target storage directory is constructed level by level using the current date (year, month, day) as the third-level directory name. A storage file name containing a unique identifier and the original file name is generated for the media file in this directory. The binary data of the media file is written into the file in this directory. After writing is completed, the file status query interface of the file system is called to obtain the metadata information of the file. Then, the metadata and storage information are assembled into a record and inserted into the media file table. This step is used to save the media file to the file system according to the hierarchical directory structure of time dimension. At the same time, the metadata and storage location information of the media file are recorded in the media file table of the database, so that the physical storage of the media file and the database record maintain a one-to-one correspondence, providing a data foundation for subsequent querying and locating of media files through the media file table.

[0164] For example, Figure 7 This is a schematic diagram of a time-based hierarchical bucketed storage architecture provided in an embodiment of this application, as shown below. Figure 7 As shown, the date-based bucketing storage strategy divides all media files into three-level directories (year / month / day) based on their upload date. YYYY represents the year directory, MM represents the month directory, and DD represents the date directory, forming a YYYY / MM / DD directory hierarchy. This allows control over the number of files in a single directory. Assuming 1000 images are uploaded daily, this three-level bucketing strategy limits the number of files in a single directory to approximately 1000, far below the 10,000 file limit that causes file system performance degradation. It also supports batch cleaning of expired data based on the date dimension and allows for flexible incremental backups based on the date dimension. Each media file is named in the format {asset_uuid}_{sanitized_original_filename}. `asset_uuid` ensures the file's global uniqueness within the system, and `sanitized_original_filename` is the processed original filename, preserving the readability of the original filename.

[0165] In this embodiment, file system performance is maintained through date-based bucketing, i.e., files are organized into three levels of directories: YYYY / MM / DD, with the number of files in a single directory controlled at a daily average level (approximately 100-1000 files / directory). With a scale of 100,000 files, file search time is reduced from >2 seconds to <10ms, and directory listing operations are reduced from >5 seconds to <50ms. Based on this, by using hierarchical storage for media files, and leveraging association tables and the aforementioned traceability query method, data retrieval efficiency is significantly improved.

[0166] Optionally, in the above Figure 6 Based on the illustrated embodiment, the method may further include:

[0167] Based on the type of the acquired media files, the hierarchical structure of the target storage directory is adjusted to obtain the updated storage directory.

[0168] In this embodiment, based on the type of media files (such as images, videos, reports, and derived files), a type dimension can be added as a top-level classification directory to the original date hierarchy. That is, the original {storage_root} / YYYY / MM / DD / hierarchy is adjusted to {storage_root} / {media_type} / YYYY / MM / DD / hierarchy, where {media_type} is mapped to the corresponding directory name (such as image, video, report, derived) based on the file type. By introducing type bucketing before date bucketing, different types of media files will be stored in their own independent directory trees, avoiding the mixing of different types of files such as images, videos, and reports in the same date directory.

[0169] Alternatively, the hierarchical structure of the target storage directory can be adjusted based on the size of the obtained media files to obtain an updated storage directory.

[0170] In this embodiment, based on the size of the media files and according to preset file size range rules (such as less than 10MB, 10MB to 100MB, greater than 100MB, etc.), a size range dimension is added as a subdirectory level to the original date-level structure. That is, the original {storage_root} / YYYY / MM / DD / level structure is adjusted to {storage_root} / YYYY / MM / DD / {size_range} / level structure, where {size_range} is mapped to the corresponding size range label (such as small, medium, large) based on the actual file size. By introducing a size range dimension under the date level, files of different sizes are distributed to different subdirectories, avoiding the storage space waste caused by large file size differences when storing large and small files together. This also facilitates subsequent storage strategy optimization based on file size (such as merging small files to improve I / O efficiency and using large-block read / write for large files to improve throughput performance), and effectively reduces the performance fluctuation of the file system when processing mixed-size files.

[0171] In this embodiment, by introducing type or size dimensions as additional bucketing levels, the distribution structure of files in the storage system can be optimized on the basis that date bucketing has effectively controlled the number of files in a single directory. This allows files of different types or sizes to be logically isolated and stored according to business attributes, thereby improving the flexibility and maintainability of storage management. It also provides basic support at the directory structure level for subsequent configuration of differentiated storage strategies based on type or size dimensions (such as storage media selection, access frequency optimization, and lifecycle management), and at the same time helps to further reduce the pressure of the upper limit of the number of files in a single directory.

[0172] in addition, Figure 8 The flowchart for creating and associating analysis records provided in the embodiments of this application is as follows: Figure 8 As shown, the process proceeds linearly from top to bottom. The process starts with an analysis request, and then sequentially executes the following steps: storing media files based on SHA256 deduplication and date binning rules; entering the corresponding metadata and storage information of the media files to complete MediaAsset registration; calling the VLM API to perform image analysis; generating analysis records carrying analysis results and summary content; and building RecordMediaLink to bind the analysis records and media files. Then, it enters the branch judgment stage, using diamond-shaped judgment nodes to distinguish whether the current task belongs to the batch task. If the judgment result is yes, the operation of updating the analysis batch summary information is executed; otherwise, it directly jumps to the end point of the process. Both branches eventually merge into the completion node, presenting a full-link operation from initiating an analysis request to establishing data association and synchronizing the batch ledger.

[0173] Additionally, steps S601 to S602 can occur based on Figure 2 After performing a data query using the data query method, it can also occur based on... Figure 2 The data query method is used during the data query process.

[0174] In this embodiment, when storing media files, a target storage directory is constructed according to a hierarchical structure based on a hierarchical storage strategy. The media files to be stored are stored hierarchically, and the metadata and storage information of the media files are stored in a media file table. This ensures that each media file is organized in an orderly manner in the hierarchical directory at the physical storage level and its file attributes and storage location are fully recorded at the data management level. When users conduct subsequent tracing and querying, they can quickly locate the storage area where the file is located based on the hierarchical directory structure, and they can also identify the file type and role through the metadata in the media file table. This solves the technical problems in the prior art where media files are stored flatly in a single directory, resulting in disordered file organization, separation of file information and management, and difficulty in identifying and classifying by type or role due to the lack of file feature information.

[0175] Figure 9 Flowchart of the data query method provided in the embodiments of this application Figure 5 In the above Figure 6 Based on the provided embodiments, the data query method further includes:

[0176] Step S901: Concatenate the preset storage root directory, the target storage directory, and the media file name to obtain the original storage path of the media file to be stored.

[0177] In this embodiment, a preset storage root directory can be read from the system configuration as the basic path for storing all media files. Then, the target storage directory constructed according to the hierarchical storage strategy in step S602 is concatenated after the root directory to form a complete directory hierarchy. Finally, the uniquely processed media file name is appended to the end of the directory path. The three are concatenated and combined in sequence to obtain the complete original storage path of the media file in the file system, which is used for subsequent path normalization verification and file writing operations.

[0178] For example, the system's default storage root directory is / data / storage, the target storage directory is images / 2026 / 08 / 25, and the media file name is a1b2c3d4_original_image.png. The original storage path obtained by concatenating these three elements is / data / storage / images / 2026 / 08 / 25 / a1b2c3d4_original_image.png. This path indicates the complete storage location of the file in the file system.

[0179] Step S902: Convert the original storage path into a string and remove the leading and trailing whitespace characters to obtain the path object.

[0180] In this embodiment, the original storage path obtained in the previous step can be uniformly converted into a string type to eliminate the type differences that may be caused by different data sources. Then, the string is subjected to the removal of leading and trailing whitespace characters to filter out spaces, tabs or newlines that may be unintentionally mixed in the path, thereby obtaining a clean and standardized path object, providing a reliable input basis for subsequent path type identification and security verification.

[0181] Step S903: Convert the path object into a candidate relative path, and perform path parsing on the candidate relative path to obtain the parsed path.

[0182] In this embodiment, the type of the path object can be identified first. If the path is of absolute type, its relative path to the preset storage root directory is calculated, and it is verified whether the relative path is still within the scope of the storage root directory. If the verification passes, the relative path is determined as a candidate relative path. If the path is of relative type, the path object is filtered component by component to remove invalid path components such as illegal directory jump segments and redundant empty segments. The remaining valid components after filtering are then reassembled into a candidate relative path. Subsequently, a path parsing operation is performed on the candidate relative path to standardize it into a canonical path form that can be directly recognized by the file system, resulting in the final parsed path, which serves as the basis for subsequent storage range verification and file writing.

[0183] Step S904: If the parsed path is within the preset storage root directory, then the candidate relative path is determined as the relative storage path of the media file, so as to store the media file to be stored according to the relative storage path.

[0184] In this embodiment, the parsed path obtained in step S903 can be compared and verified with the preset storage root directory to confirm whether the path is within the compliant storage area defined by the storage root directory. If the verification passes, it means that the path has not escaped the directory and the structure is safe and reliable. At this time, the candidate relative path is officially determined as the relative storage path of the media file, and the path is recorded in the media file table as an important part of the storage information. Subsequently, the final write operation of the media file is performed based on this relative storage path to achieve a consistent correspondence between the physical file and the storage location information in the database record.

[0185] This embodiment sequentially performs string conversion and leading / ending whitespace cleanup on the concatenated original storage path, path type identification and candidate relative path conversion, path component filtering to remove illegal jump segments and redundant invalid paths, and finally, strict verification of whether the parsed path is within the preset storage root directory range. This ensures that the final determined relative storage path is always safe, controllable, and structurally standardized, effectively avoiding storage location errors and path traversal security issues caused by non-standard path concatenation, whitespace interference, or directory jumps. At the same time, this relative storage path is directly used for subsequent file writing operations, ensuring the precise consistency between the actual disk location of the physical file in the file system and the storage information recorded in the database, providing a reliable foundation for the correct storage and subsequent accurate positioning of media files.

[0186] Figure 10 Flowchart of the data query method provided in the embodiments of this application Figure 6 In the above Figure 9 Based on the illustrated embodiments, as Figure 10 As shown, step S903 is specifically implemented as follows:

[0187] Step S9031: Identify the type of the path object; where the type includes absolute type and relative type.

[0188] In this embodiment, the path can be distinguished as either an absolute or relative type based on its starting character and format characteristics to determine which processing branch to use. If the path object starts with a root directory character or conforms to the operating system's absolute path format specification, it is determined to be an absolute type, and subsequent relative path conversion and range verification need to be performed. If the path object does not start with a root directory character and does not contain complete root path information, it is determined to be a relative type, and subsequent component-by-component filtering and concatenation operations need to be performed to ensure that the path processing logic matches the path type.

[0189] For example, the path object ` / data / storage / images / 2026 / 08 / 25 / a1b2c3d4.png` starts with a root directory symbol, conforms to the operating system's absolute path format specification, and contains six levels of components; therefore, it is determined to be an absolute path. The path object `images / 2026 / 08 / 25 / a1b2c3d4.png` does not start with a root directory symbol and only contains a four-level relative directory structure; therefore, it is determined to be a relative path. The two types will enter different processing branches to ensure the accuracy and security of the path conversion logic.

[0190] Step S9032: If the type is absolute, calculate the relative path of the path object relative to the preset storage root directory. If the relative path does not exceed the range of the preset storage root directory, then the relative path is determined as a candidate relative path.

[0191] In this embodiment, when a path object is identified as an absolute type, the relative path of the absolute path relative to the storage root directory is calculated based on the preset storage root directory. Then, the range of the calculated relative path is determined to confirm that none of its path components attempt to jump outside the storage root directory. That is, the relative path is completely within the compliant storage area defined by the preset storage root directory. If the range verification passes, the relative path is determined as a candidate relative path as the basis for subsequent path resolution and file writing. This processing method not only preserves the complete positioning information of the absolute path, but also converts it into a relative form that is easy to store and manage.

[0192] For example, if the default storage root directory is / data / storage and the absolute path object is / data / storage / images / 2026 / 08 / 25 / a1b2c3d4.png, the calculated relative path is images / 2026 / 08 / 25 / a1b2c3d4.png. This relative path contains four components, all within the / data / storage directory. After verification, this relative path is identified as a candidate relative path. However, if the absolute path object is / data / storage / .. / etc / passwd, and the calculated relative path is .. / etc / passwd, this path attempts to jump outside the storage root directory, and the range verification fails. This path will be rejected as a candidate relative path, thus effectively preventing path traversal attacks.

[0193] Step S9033: If the type is relative, filter the path object component by component to remove invalid paths containing illegal directory jump segments and redundant empty segments, and obtain candidate relative paths.

[0194] In this embodiment, when a path object is identified as a relative type, it is split into several path components using the path separator as the boundary, and the validity and security of each component are checked in turn. Violations or invalid components, such as segments representing parent directory jumps and empty segments representing the current directory, are eliminated. Valid components representing normal subdirectories or filenames are retained. Finally, all retained valid components are reassembled in order to form a candidate relative path that has been filtered for security, thereby eliminating storage location disorder and directory traversal problems that may be caused by non-compliant path components at the source.

[0195] For example, a relative path object like images / .. / .. / etc / passwd can be split into five components by the separator: images, .., .., etc, and passwd. When filtering by component, consecutive parent directory jump characters (..) are removed, leaving only the three valid components: images, etc, and passwd. These are then reassembled to obtain the candidate relative path images / etc / passwd, effectively avoiding the problem of jumping to the parent directory. Similarly, the path object . / . / temp / . / file.pdf contains three redundant empty segments in the current directory. After filtering, only the two valid components, temp and file.pdf, are retained, resulting in temp / file.pdf. The path length is reduced from nineteen characters to thirteen characters, improving the standardization of the path.

[0196] This embodiment performs type identification on path objects. For absolute types, it calculates their relative path to the preset storage root directory and verifies whether it exceeds the storage range. For relative types, it filters components one by one to remove illegal directory jump fragments and redundant empty segments of invalid paths. This ensures that no matter what form the path is input, it can be accurately classified and safely processed during the path conversion stage. It effectively prevents conversion errors caused by misjudgment of path type, directory traversal security issues caused by parent directory jump characters, and path parsing anomalies caused by redundant empty segments. This provides a reliable guarantee for obtaining standardized, safe, and usable candidate relative paths in the future.

[0197] Figure 11 Flowchart of the data query method provided in the embodiments of this application Figure 7 In the above Figure 6 Based on the provided embodiments, before step S602, the data query method further includes:

[0198] Step S1101: Calculate the hash value of the media file to be stored, and compare the hash value with the stored hash values ​​in the media file table.

[0199] In this embodiment, after obtaining the binary data of the media file to be stored, the binary content of the file can be read in a loop at a preset block size (e.g., 1MB). Each block read is appended to the SHA256 digest calculation function until the entire file is read. The hash value of the file is obtained from the digest calculation function, and then the hash value is used as a query condition to perform an equality match query on the hash value field of the media file table. If the query result is empty, it means that the hash value does not exist in the media file table. If the query result is not empty, it means that the hash value exists. This step is used to determine whether the media file has been stored in the system before physical storage by using the content hash value, providing a basis for subsequent tiered storage operations.

[0200] For example, each media file to be stored has its SHA256 hash value calculated and saved to the MediaAsset.sha256 field during storage. The hash calculation uses a streaming chunking algorithm. First, the SHA256 digest object is initialized. Then, the file is opened in binary read-only mode, and the file content is read in a loop according to the preset chunk size CHUNK_SIZE, which typically ranges from 512KB to 4MB. For each read chunk, the digest update method is called to accumulate the hash value. After the entire file is read, a hexadecimal hash string is returned. This streaming calculation method can avoid memory overflow when processing large files. At the same time, the MediaAsset table creates an index for the SHA256 field, which can achieve duplicate detection with O(logn) complexity. The SHA256 hash is automatically calculated and persisted when the file is uploaded, supporting duplicate detection and storage optimization. In a test containing 300 images (90 of which were reused reference machine images), the deduplication detection identified 90 duplicate files, saving about 30% of storage space. The deduplication detection time for 1000 files is <5ms.

[0201] Alternatively, Content-Addressable Storage (CAS) can be used instead of SHA256 deduplication. In CAS, files are directly named and stored using hash values, naturally eliminating duplicates. However, the CAS scheme sacrifices filename readability and requires a reconstruction of the existing file access interface. This application uses a compromise solution of original filename + SHA256 index.

[0202] The specific implementation method of step S602 is as follows:

[0203] Step S1102: When the hash value is found to be different from the hash value already stored in the media file table, the target storage directory is constructed according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored hierarchically, and the data information of the media files is obtained to store the data information of the media files in the media file table.

[0204] In this embodiment, if the hash value fails to match all stored hash values ​​in the media file table, a target storage directory is constructed level by level using the year, month, and day of the current date as the third-level directory name. A storage filename containing a unique identifier and the original filename is generated for the media file in this directory. The binary data of the media file is written into this file in the directory. After writing is complete, the metadata of the file is extracted, and then the metadata and storage information are assembled into a record and inserted into the media file table. This step is used to save the media file to the hierarchical directory of the file system, ensuring that the media file to be stored is not duplicated, while simultaneously recording its metadata and storage information in the media file table of the database. This maintains a correspondence between the physical file and the database record, providing a data foundation for subsequent querying and locating of the file through the media file table.

[0205] The report is generated only after all analysis records for the entire batch are completed. The process is as follows: after uploading images in batches, the Vision Language Model (VLM) is called to perform image analysis one by one or group by group. After all analysis records are completed, the Large Language Model (LLM) is called to summarize all analysis records and generate a Markdown format report text.

[0206] The report path is automatically generated by the `build_paths()` method in the storage service. The directory structure is `reports_root / YYYY / MM / DD / ` (bundled by date). YYYY represents the year when the report was generated, MM represents the month, and DD represents the day. Together, they form a three-level directory structure organized by upload date: year / month / day. For example, if the report was generated on May 14, 2026, the corresponding directory would be `reports_root / 2026 / 05 / 14 / `, and the filename would be `{asset_uuid}_{sanitized_batch_code`. The file `_report_{timestamp}.md` uses `asset_uuid` as a globally unique identifier, `sanitized_batch_code` as a security-filtered batch code, and `timestamp` as the generated timestamp. The resulting relative path is, for example, `storage / reports / 2026 / 05 / 14 / {uuid}_xxx_report_20260514_120000.md`. This report path is used to locate the report file in the file system and to construct the access URL when displaying and downloading the report on the front end. Files are organized into three levels of directories: YYYY / MM / DD, with the number of files per directory controlled at a daily average level (approximately 100-1000 files / directory). With 100,000 files, file search time has been reduced from >2 seconds to <10ms, and directory listing operations have been reduced from >5 seconds to <50ms.

[0207] The report path is the raw target path string automatically generated before the file write operation and serves as the input to the verification function. The storage path, on the other hand, is the relative path ultimately written to the file system after the report path has been normalized and processed by security verification functions. It is stored in the `storage_rel_path` field of the media file table. The difference between the two is that the report path is an intermediate form before writing, has not yet undergone security verification, and cannot be directly used for file writing. The storage path is the final form after writing, has passed security verification, and can be directly used for locating and accessing the file system. Essentially, they represent different states of the same report file before and after writing to the disk. The report path is the unverified raw form, while the storage path is the verified secure form, both pointing to the same physical file. Sometimes, the term "report path" emphasizes its role as the access point for the report file, while "storage path" emphasizes its actual storage location in the file system and its trusted state after security verification.

[0208] Because the report path may involve path strings imported from external sources or concatenated from analysis results during the generation process, there is a security risk of path traversal attacks. Therefore, the report path must undergo normalization and security verification before being written to the disk file to convert it into a trusted storage path. The specific verification process is as follows: In the input preprocessing step, the input path is converted into a string and leading and trailing whitespace characters are removed, parsing it into a path object; In the branch processing step, if the path is an absolute path, its relative path to the storage root directory is calculated. If the path exceeds the storage root directory range, it is rejected. If the path is a relative path, it is filtered component by component. Empty strings and "." components are skipped directly, and ".." components are rejected directly to prevent directory traversal attacks. Other components are retained and reconstructed into a relative path; In the final verification step, the parsed path must still be within the storage root directory; otherwise, it is rejected to prevent symbolic link attacks. This process achieves path security through three layers of protection: component-level filtering (rejecting ".." and "."), range-level restriction (absolute paths must be within the storage root directory), and final verification (preventing symbolic link attacks). After successful verification, the report path is converted into a safe storage path before `write_bytes()` is executed to write the report content to the disk file and the storage path is recorded in the `storage_rel_path` field of the media file table.

[0209] Figure 12 The path normalization and security verification flowchart provided for the embodiments of this application is as follows: Figure 12 As shown, this diagram is a flowchart of path normalization and security verification. Taking the reported path as the starting point, the process first distinguishes whether the path is an absolute path or a relative path through the diamond-shaped judgment node. The absolute path branch performs relative path conversion and verifies the belonging range, while the relative path branch filters directory jump characters segment by segment. After the two branches merge, the process enters the range verification judgment. If the path is determined to be outside the range of the top-level storage root directory, access is denied and an exception is thrown directly. If it is within the range, a second verification of path belonging is performed. After completion, it is determined whether there is a symbolic link escape in the path. If escape exists, the access denial process is also triggered. If there is no escape problem, the processed normalized path is output. This fully covers the entire chain of security verification logic, including path type differentiation, jump character filtering, storage boundary verification, and symbolic link problem investigation.

[0210] Alternatively, graph databases can be used to replace the many-to-many association tables of relational databases. Graph databases are naturally suitable for expressing complex relationships and have better query performance in deep association scenarios. However, they introduce additional database components, which increases deployment and maintenance costs. Moreover, the association depth in image analysis scenarios is limited (usually 2-3 hops), and relational databases are sufficient.

[0211] In this embodiment, before storing the media file, a hash value is calculated for the media file to be stored, and the hash value is compared with all the hash values ​​already stored in the media file table. Only when the hash value is different from all the stored hash values, the step of constructing the target storage directory according to the hierarchical storage strategy and storing the media file to be stored hierarchically is executed. This ensures that media files with the same content are physically stored only once during the first upload, regardless of how many times they are uploaded, which batch they come from, or which user they are from. Subsequent repeated uploads are only identified as existing files by hash value matching and are not stored again.

[0212] Based on the above embodiments, this application provides a specific implementation example, namely, a data query system, which includes a hierarchical storage layer, an association model layer, and a traceability query layer.

[0213] The hierarchical storage layer, after retrieving the media files to be stored, constructs a target storage directory with a three-level directory structure of year, month, and day according to a date-based bucketing strategy. The media files are then stored in this directory. Simultaneously, the SHA256 hash value of the media file is calculated and compared with a previously stored hash value. If the hash value does not exist, the storage operation is performed to avoid duplicate storage. The path normalization function performs three layers of security checks on the input path before writing it: component-level filtering, range-level restriction, and final verification, preventing directory traversal attacks. In security testing, all attack vectors containing ".. / ", absolute path escape, and symbolic links were correctly intercepted. The path normalization function can be replaced by chroot jail or container isolation. While restricting file access scope through operating system-level isolation is more secure, it increases deployment complexity and may not be suitable for development / testing environments. This application chooses to implement path verification at the application layer as a layer of defense in depth. The application layer refers to the server-side program layer running on the operating system, responsible for handling business logic, and encompasses the hierarchical storage layer, the association model layer, and the traceability query layer.

[0214] The association model layer is used to create media file tables, analysis record tables, analysis batch tables, and analysis report tables as core data tables in the relational database. It also creates a first association table to record the association between analysis records and media files and a second association table to record the association between analysis reports and analysis records, so as to explicitly express the many-to-many association relationships between the core data.

[0215] The traceability query layer is used to query the first associated table and / or the second associated table, as well as the core data table, after receiving a query request containing the identifier to be queried, in order to obtain the analysis report, analysis record and / or media file corresponding to the identifier to be queried. The multi-table association query is completed in a single database operation through a preloading strategy to avoid the N+1 query problem, and supports complete data traceability from three entry points: batch identifier, analysis record identifier and analysis report identifier.

[0216] Specifically, Figure 13 This is a three-layer architecture diagram of traceable storage and media resource association provided in the embodiments of this application. Figures 2 to 4 , Figure 6 , Figures 9 to 11 All data query methods can be used Figure 13 This three-tier architecture diagram is used to implement it, such as Figure 13 As shown, the association model layer includes analysis record tables, analysis report tables, media file tables, and analysis batch tables. These are paired with two types of many-to-many association tables: analysis report-analysis record association tables and analysis record-media file association tables, to carry out the many-to-many mapping relationships between entities. The hierarchical storage layer uses `storage_root` as the top-level root directory and divides the storage into four independent date-based bucket directories according to file type and upload date: reports, videos, images, and derived files. Physical archiving of media files is completed using hash verification and date hierarchies. The traceability query layer sets up four query paths: report association query, global search query, batch traceability query, and record detail query. Corresponding association links are established between each layer to achieve integrated linkage of media physical files, structured entity data, and full-link traceability retrieval, fully covering the entire business logic of image file storage, data association binding, and multi-dimensional traceability retrieval. Object storage services can be used to replace the local file system date-based bucket storage. Object storage inherently supports high scalability and multi-replica redundancy, but it introduces network latency and API call costs, and is unavailable in offline scenarios. The current solution chooses a local file system based on intranet deployment and security isolation considerations in the test environment. Images, videos, reports, and derived files share the same storage architecture and data model, with the media_type and role fields distinguishing their types. Adding a new media type does not require modifying the storage architecture.

[0217] Figure 14 The data model ER relationship diagram provided in the embodiments of this application, as described above Figures 2 to 4 , Figure 6 , Figures 9 to 11 All data query methods can be used Figure 14 This is achieved through a structured entity-related data model, such as... Figure 14 As shown, Figure 14 The data model showcases the field structure, primary key and foreign key constraints, and entity relationship logic of six data tables under the image analysis business. Figure 13 The structured entity association system is composed of six data tables: AnalysisBatch (storing batch basic information and task quantity), AnalysisRecord (carrying single analysis content), AnalysisReport (storing summary documents), MediaAsset (recording metadata and storage information of media files), ReportRecordLink (implementing many-to-many binding between analysis reports and analysis records), and RecordMediaLink (implementing many-to-many binding between analysis records and media files). Each table lists different types of fields such as identifier, business attributes, and storage content, and labels them with primary keys, unique keys, and foreign key constraints. The lines in the diagram indicate entity association relationships such as inclusion, generation, inclusion in reports, association with records, reference to report files, association with media files, and reference by records. It clearly shows the complete many-to-many mapping link built by two intermediate association tables for the four core entities of batch, analysis record, analysis report, and media file, and presents the storage fields and mutual binding logic of the data entities in the whole process in a standardized way.

[0218] Figure 15 This is a schematic diagram of the structure of the data query device provided in an embodiment of this application. Figure 15 As shown, the data query device includes an acquisition module 1501 and a query module 1502. The acquisition module 1501 is used to acquire a query request, wherein the query request includes a query identifier. The query module 1502 is used to query a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, to obtain analysis reports, analysis records, and / or media files corresponding to the query identifier.

[0219] The first association table records the relationship between analysis records and media files, the second association table records the relationship between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

[0220] The data query device provided in this embodiment can execute... Figures 2 to 4 , Figure 6 , Figures 9 to 11 The technical solution of the data query method embodiment shown herein, its implementation principle and technical effect are similar to Figures 2 to 4 , Figure 6 , Figures 9 to 11 The data query method shown in the example is similar and will not be described in detail here.

[0221] Figure 16 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 16As shown, the electronic device 160 includes at least one processor 1601 and a memory 1602. The electronic device 160 also includes a communication component 1603. The processor 1601, memory 1602, and communication component 1603 are connected via a bus 1604.

[0222] In a specific implementation, at least one processor 1601 executes computer execution instructions stored in memory 1602, causing at least one processor 1601 to implement a data query method of the above embodiment.

[0223] The specific implementation process of processor 1601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0224] In the above embodiments, it should be understood that the processor 1601 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0225] The memory 1602 may include high-speed RAM memory, and may also include non-volatile memory NVM, such as at least one disk storage.

[0226] Bus 1604 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1604 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 1604 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0227] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0228] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement a data query method as described in the above embodiments. In a specific implementation of the aforementioned data query method, each module can be implemented as a processor.

[0229] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0230] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0231] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a data query method as described in the above embodiments.

[0232] The computer program is stored in a readable storage medium, and at least one processor can read the computer program from the readable storage medium and execute the computer program to perform the scheme provided in any of the above embodiments.

[0233] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0234] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data query method, characterized in that, include: Obtain a query request; wherein the query request includes a query identifier; According to the query request, query the pre-configured first association table and / or second association table, as well as the core data table, to obtain the analysis report, analysis record and / or media file corresponding to the query identifier; The first association table is used to record the association between analysis records and media files, the second association table is used to record the association between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

2. The method according to claim 1, characterized in that, The step of querying a pre-configured first association table and / or second association table, as well as a core data table, according to the query request to obtain analysis reports, analysis records, and / or media files corresponding to the query identifier includes: Based on the object-relational mapping framework, a preloading strategy is used to query a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, so as to obtain the analysis report, analysis record and / or media file corresponding to the query identifier in a single query.

3. The method according to claim 2, characterized in that, If the identifier to be queried is a batch identifier, then the step of querying the pre-configured first association table and / or second association table, as well as the core data table, according to the query request to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query includes: Based on the query request, query the analysis record table to obtain the analysis record corresponding to the batch identifier, as well as the identifier of each analysis record; Query the first association table to obtain the identifier of the media file corresponding to the identifier of each analysis record; The media file table is queried to obtain the data information of the media file corresponding to the identifier of each media file, and the media file is obtained based on the data information of the media file; Query the analysis batch table to obtain the identifier of the analysis report corresponding to the batch identifier, and query the analysis report table to obtain the analysis report corresponding to the identifier of the analysis report.

4. The method according to claim 2, characterized in that, If the identifier to be queried is an analysis record identifier, then the step of querying the pre-configured first association table and / or second association table, as well as the core data table, according to the query request to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query includes: Based on the query request, query the analysis record table to obtain the analysis record corresponding to the analysis record identifier, and the identifier of the analysis record; Query the first association table to obtain the identifier of the media file corresponding to the identifier of the analysis record; The media file table is queried to obtain the data information of the media file corresponding to the identifier of the media file, and the media file is obtained based on the data information of the media file.

5. The method according to claim 2, characterized in that, If the identifier to be queried is the identifier of the analysis report, then the step of querying the pre-configured first and / or second association tables, as well as the core data table, according to the query request to obtain the analysis report, analysis record, and / or media file corresponding to the identifier to be queried in a single query includes: Based on the query request, query the analysis report table and the second association table respectively to obtain the identifiers of the analysis report and the analysis record corresponding to the identifier of the analysis report; Query the analysis record table to obtain the analysis record corresponding to the identifier of the analysis record.

6. The method according to claim 5, characterized in that, The first association table includes multiple first records, each of which includes the identifier of the analysis record, the identifier of the media file, and the associated role type; The associated role type is used to characterize the role of the media file in the analysis record as an analysis object, a reference comparison object, or a report file.

7. The method according to claim 5, characterized in that, The second association table includes multiple second records, each of which includes an identifier for the analysis record, an identifier for the analysis report, and an identifier for the association order; The identifier of the association order is used to characterize the display order of the analysis records in the analysis report.

8. The method according to claim 5, characterized in that, Also includes: Retrieve the media file to be stored; According to the hierarchical storage strategy, the target storage directory is constructed according to the hierarchical structure to store the media files to be stored hierarchically, and the data information of the media files is obtained to store the data information of the media files in the media file table; The data information of the media file includes the media file's metadata and storage information; The metadata includes one or more of the following combinations: media file identifier, media file type, media file size, media file role marker, media file characteristic information, and hash value; The storage information includes the filename of the stored media and its relative storage path.

9. The method according to claim 8, characterized in that, Also includes: Calculate the hash value of the media file to be stored, and compare the hash value with the hash values ​​already stored in the media file table; The step of constructing the target storage directory according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored hierarchically includes: When the hash value is found to be different from the hash value already stored in the media file table, the target storage directory is constructed according to the hierarchical structure based on the hierarchical storage strategy to store the media files to be stored hierarchically.

10. The method according to claim 8, characterized in that, The step of constructing a target storage directory according to a hierarchical structure based on a hierarchical storage strategy to store the media files to be stored hierarchically includes: Based on the date-based bucketing storage strategy, the target storage directory is constructed according to the time hierarchy to store the media files to be stored in a hierarchical manner.

11. The method according to claim 10, characterized in that, Also includes: The preset storage root directory, the target storage directory, and the media file name are concatenated to obtain the original storage path of the media file to be stored; The original storage path is converted into a string and the leading and trailing whitespace characters of the string are removed to obtain a path object; The path object is converted into a candidate relative path, and the candidate relative path is parsed to obtain the parsed path; If the parsed path is within the preset storage root directory, then the candidate relative path is determined as the relative storage path of the media file, so that the media file to be stored is stored according to the relative storage path.

12. The method according to claim 11, characterized in that, The step of converting the path object into a candidate relative path includes: Identify the type of the path object; wherein the type includes absolute type and relative type; If the type is an absolute type, calculate the relative path of the path object relative to the preset storage root directory. If the relative path does not exceed the range of the preset storage root directory, then determine the relative path as the candidate relative path. If the type is a relative type, the path object is filtered component by component to remove invalid paths containing illegal directory jump segments and redundant empty segments, thus obtaining the candidate relative path.

13. The method according to claim 8, characterized in that, Also includes: Based on the type of the acquired media files, the hierarchical structure of the target storage directory is adjusted to obtain the updated storage directory; or, Based on the size of the obtained media files, the hierarchical structure of the target storage directory is adjusted to obtain the updated storage directory.

14. A data query device, characterized in that, include: The acquisition module is used to acquire a query request; wherein the query request includes a query identifier; The query module is used to query a pre-configured first association table and / or second association table, as well as a core data table, according to the query request, in order to obtain analysis reports, analysis records, and / or media files corresponding to the identifier to be queried; The first association table is used to record the association between analysis records and media files, the second association table is used to record the association between analysis reports and analysis records, and the core data tables include one or more of the following: analysis record table, analysis batch table, media file table, and analysis report table.

15. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; When the processor executes the computer execution instructions stored in the memory, it is used to implement the data query method as described in any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the data query method as described in any one of claims 1 to 13.

17. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, is used to implement the data query method as described in any one of claims 1 to 13.

Images