Shulou(Shulou.com)06/01 Report--

This article analyzes "how to check the support of report tools for large data reports". The content is detailed and easy to understand, and friends who are interested in "how to check the support of report tools for reports with large amounts of data" can follow the editor's train of thought to read it in depth. I hope it will be helpful to you after reading. Follow the editor to learn more about "how to check the support of report tools for reports with large amounts of data".

A large amount of data is checked out from the database, and then the report is generated and output to the web side, which generally takes a long time, the user experience is very poor, and the report is generally calculated in memory, so it is easy to burst the memory if it is fully read. Therefore, large amount of data reports are presented in a paging way, presenting the first page as quickly as possible, and users can also turn the page at will, each time the amount of data displayed on a page is relatively small, so there will be no memory overflow.

Most reporting tools usually use the database paging mechanism. Using the syntax provided by the database to return records within the specified line number range, that is, the interface side calculates the line number range according to the current page number (showing a fixed number of rows per page) as a parameter into SQL, the database will only return the records of the current page, thus achieving the effect of paging presentation.

However, there are two problems with this approach: one is that when you turn the page backwards, you need to recalculate the sql, which makes you have a strong sense of waiting; the other is that the data may be inconsistent due to the database update operation performed during the page turn. Although these two problems can be solved by cursor fetch, the cursor is an one-way operation, which can only turn the page backward, not forward, and can not fundamentally solve the problem.

Moisten the report put forward a completely different big data report processing scheme, using two asynchronous threads to complete the fetch and rendering, the fetch thread sends out the SQL and continuously takes out the data cache to the local, and the rendering thread obtains the data from the local cache for display. In this way, the data that has been fetched and cached can be rendered quickly without a sense of waiting, and there will be no inconsistency in the SQL involved in the fetch thread to keep the same transaction in the database. At the same time, the set file storage format supports jump to any page access, which greatly improves the user experience.

The database system itself does not directly support this mechanism, and a lot of work needs to be done at the reporting tool level, drying the report because its built-in unique computing engine can easily achieve this, while other reporting tools are difficult to do. It is very simple to set large report presentation in a dry report. For example, the sql dataset can directly set the big data set in the report properties:

Then use the big tag to quickly display the report data (the background is still being calculated at the same time, so the page number will change):

There will be a progress reminder when you export excel:

On how to check the support of the report tool for large amounts of data reports is shared here, I hope that the above content can improve everyone. If you want to learn more knowledge, please pay more attention to the editor's updates. Thank you for following the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.