Tabulation Efficiency Analysis of Web report tools

The core and most essential function of the so-called report tool is its tabulation capability, that is, whether it can generate various report tools that it needs without writing code. However, when examining report tools, users tend to focus on peripheral factors such as print output, rendering scheme, and management and scheduling, while ignoring the most essential tabulation capabilities of report tools. Of course, it is undeniable that these peripheral functions are also an important metric for a report tool. However, the main purpose of the report tool is to prepare reports. In fact, mainstream products in the market have obvious defects in processing complex reports, and they cannot produce the reports we need. More than half of the reports still need to be written to prepare data, leading to meaningless tools. Therefore, examining tabulation efficiency is crucial for selecting a report tool.

Discard note

The following methods are generally used to draw reports:GridAndDrag ControlThe former adopts a solution similar to excel, and uses gridlines to enclose reports. The latter uses rectangular boxes and other elements to spell out reports. Domestic reports have very complex and strict style requirements. The drawing scheme is an important indicator of the report tool. It determines the complexity and efficiency of the report style, especially for tables with many grid lines.

Most traditional reports are drawn in a stripe. They are dragged by components. Table lines need to be tiled by rectangular borders. It is very complicated to draw complicated multi-layer headers, some vertically merged cells in the data area cannot be drawn out (or can be implemented only through specific program control). The spliced cells are also related to the resolution, on-screen alignment tables may not display neatly either on the screen or on the Web.

The grid style has obvious advantages in this respect. It can draw complicated reports with a style, and the drawing efficiency is much higher than the drag style of the control. Thanks to the popularity of MS Excel software, most people are familiar with the operations of Excel software. This can also save a lot of learning costs.

Therefore, the Excel-like method is much better than the drag-and-drop method, or the report-like method should be used. If you have a little knowledge, you can use Excel to draw tables. Therefore, Excel-like is an inevitable direction.

Because Excel has become popular for a long time. Therefore, when it comes to report tools, we naturally think of Excel-like methods first. Why are there so many drag-and-drop report tools?

This is because, although Excel has powerful table painting capabilities, it has very weak data processing capabilities, unless you associate cells with formulas like A2 + B3 = D4, otherwise, cells are independent of each other and there is no relationship between them. If you want to fetch data from a database or data file, you need to define a cell in one cell by programmer. The workload is quite heavy. It is necessary for programmers to program dynamic row and column reports.

Because the report format is only part of the report tool's solution. The purpose of using the report tool is to read data from the database and generate reports automatically. Data is the core issue for the report. The report format can be well solved using Excel, but Excel does not have a good data summary solution from the database, except for non-linear programs to fill in data in the lattice, basically, data cannot be read from the database to generate reports automatically. Therefore, almost all such reports can only be static.

Although the drag-and-drop format is well solved, the data statistics capability from the database is much better than that in Excel, and the two sides have the same privilege, while the heap frame is laborious, just heap it slowly, but the statistical summary won't work.

Similar to other software, the report tool is developed in foreign countries. The reports in foreign countries have a very regular style, no grid lines, and the header is very simple, with no diagonal lines and no hierarchical grouping. The information provided by a report is limited. If you want to view all the information, you can view only a few tables. Therefore, the drag-and-drop control of foreign report tools can weaken the disadvantages of poor report style rendering capabilities. The domestic report tools are basically designed by studying foreign report tool models. The style of Chinese-style reports is quite complex, so many reporting tools are forced to process Chinese-style reports with a large amount of program code. This also enables users to buy the report tool, the workload for making reports is huge.

Multi-source sharding.

Multi-source means that the data source of a report comes from multiple physical data tables or even multiple physical databases. Here, "multiple" refers to more than two physical databases.
Traditional report tools only support single-source reports. Even if the data comes from multiple physical data tables or physical databases, You need to convert multiple sources into single-source processing before the report design. Two or three sources can still write SQL statements, but when there are more than five or six sources, on the one hand, the corresponding SQL statements are too complex and difficult to maintain, on the other hand, their operation efficiency is reduced, at this time, you often need to write stored procedures or other code to prepare data. This is only the case of a single database. If multiple sources come from multiple databases, it is more complicated and complicated SQL statements or stored procedures cannot be written directly. It can be completed only after a dedicated database bridge is built.
Some traditional report tools also claim to support multiple sources. In fact, they refer to multi-database support. They only integrate the database bridge function into the report tool, however, when designing a report, it is still a single source. It is very different from what we call multiple sources.
Multi-source usually leads to sharding. It is precisely because of sharding that the report design must be directly based on multiple sources, rather than converting multiple sources into a single source. A considerable number of sharded reports cannot be converted into single-source processing in any case, and some reports that can be converted into single-source processing are also complicated.
Sharding means that the report is divided into multiple regions in either vertical, horizontal, or bidirectional mode. Each region has different repeated rules and may perform operations on each other.
Traditional tools are able to process sharded reports with consistent upper and lower formats and fixed column direction (reports can be converted from multiple sources into single-source reports), but they will force users to write complex SQL statements (Union + join) and code preparation data, resulting in a large workload and difficult maintenance; and for reports with a large number of horizontal partitions, data must be prepared using join, resulting in extremely low computing performance, the complexity is O (NK), and K is the number of shards.

Irregular Division

Almost all report tools support independent grouping report formats, that is, the traditional design of grouping reports is completed through a data binding process. Such grouping is completely rule-based, that is, the division criteria are consistent and there are rules (generally by a field or expression). All fields must appear only once, and the Group Value Order is consistent with the original data record order.
However, due to the full division, irregular division is often required in report summary, that is, the division criteria do not see the rules (often only can be exhaustive ), not all facts may appear in the grouping results, but some facts may be repeated. The order is also irrelevant to the original data records. A fixed group is a common manifestation of irregular division.
For example, the following report. Grouping of age groups is an irregular Division. The Division rules are not clear and can only be lifted out. grouping is incomplete, and those over 50 years old are integrated into a group.

 

This report is very difficult to implement using traditional tools. Although the report format is not complex, the grouping function of the report tool cannot be used directly due to irregular division, you can only program the data into a single-layer two-dimensional table data source, which increases the workload and makes it difficult to reflect the hierarchical relationship between data.

Dynamic lattice Calculation

All report tools provide some column computing functions, and calculate some other column values or statistical values based on the raw data. This is an indispensable function in report presentation.
Traditional tools generally only provide inter-grid operations in the same row and set operations for a group (or all), which is quite difficult for common cross-row group operations. Some traditional tools provide simple cross-row capabilities. For example, you can reference the previous row of data, but cross-group operations are powerless. For set operations, only some fixed functions are provided, for example, if you take the first place, calculate the cumulative value, and other general set operations that cannot be combined, you can do nothing, such as the second name and the product of accumulation. Some conditional operations are even more difficult, such as calculating the sum of mathematical scores of students whose Chinese scores are above 90.
In addition to regular cross-row group operations, the report may also have some random independent lattice operations, and its value may be any number of other cells in the report, it may even reference data outside the report (for example, re-calculation with the data in the database ). Because traditional tools do not have a good post-computation data item naming mechanism (traditional tools only use column names to name data units), it is difficult to accurately describe the data reference relationship and can only write regular expressions, however, Random Independent lattice operations will make traditional tools unable to process, and data references outside the report can only be used by scripts or peripheral applications, resulting in extremely messy code.
The following report is a typical cross-row group computing report, which includes operations compared with the previous period (cross-row) and compared with the same period last year (cross-group, in traditional tools, such reports often have to program and prepare data. The style of this report is not complex, but these lattice operations will make traditional tools very difficult. You can only rely on the program code again to calculate the data in advance and directly fill in the report.

 

 
In addition, all the above discussions run through a point, that is, row-column symmetry. The auto-copy extension capability of the vertical direction must be fully implemented in the horizontal direction. Reports can be grouped and sharded horizontally. For reports with horizontal changes, you can define cross-column group operations.
We know that the preceding complexity of a report is often mixed. The same report may contain all the problems, which requires us to provide a complete solution, but cannot be processed separately. When these difficulties are intertwined, the complexity of the entire problem is far greater than the total number of individual problems to be solved.
It can be seen that only the report tools supporting the above features can truly improve the efficiency of tabulation.