目前主流报表工具大多采用类 Excel 的设计方式，可以高效的完成报表布局和样式的开发，这方面差异已经不大（如果非 Excel 方式可以直接否定），简单地对比开发界面已经无法区分出各产品的开发效率。实际应用中的工作量将会更多地耗费在处理数据和运算任务上，这才是报表工具开发效率的考核重点。

下面通过几个示例来考察：

实例 1：多源分片报表

多源分片报表是常见的报表需求，数据存储在不同的数据表、数据库或者数据文件中，报表展示时要将数据在一起进行关联展示：

生产数据表：

销售数据表：

按照日期、产品类型维度汇总生产及销售数据，结果如下：

这是一个典型的多源分片报表，重点考察几个方面：

1：多数据源如何进行关联。

2：汇总数据时是否有字段间的运算能力，如数据库中存储的是单价和销售数量，做收入汇总时需要通过单价 * 数量来算出。

3：报表中公式设置的便捷度。

以润乾报表为例，报表模版如下：

多数据源的关联主要是通过 D3 单元格实现的，D3 中的公式为：=ds2.sum(单件售价 * 销售件数,year( 日期)==A3 and month(日期)==B3 and 产品类型 ==C1)，在公式中增加关联条件可以实现两个数据集间的关联，条件可以手动输入也可以通过向导来设置。报表中是支持字段间的运算的，单件售价 * 销售件数可以算出销售收入，再根据设置的条件就可以实现收入和成本情况的关联展示。

在 C4 中对成本做了年汇总，在 D4 中相似的公式只需要复制粘贴过来就行，单元格名称的引用会自动发生变化，就不需要重复设置了。

再换一个报表工具看一下，设置方式：

关联设置看下 D3 单元格的设置：

这里的关联条件是通过向导方式来生成的，多个条件时需要点击增加选择 AND 或者 OR，条理上看着比较清楚，但是再修改时要先选中条件，修改公式再次点击修改才能生效，对于熟练使用的人来说，反而不如直接在格子里手动修改来的方便，而且过滤条件是不反显的，必须要点击单元格打开过滤对话框才能看到里边的具体的条件，如果报表中有多个格子设置了条件，想找到要修改条件的单元格都不是件容易的事。

销售收入这里，工具中没有设置字段间运算再汇总的方法，只能在数据集 sql 语句取数时先计算生成一个销售收入字段，然后这里对字段进行汇总。

年汇总公式中，C4 设置好后，D4 中可以通过鼠标拖拽方式将 C4 的公式拖拽到 D4 中，单元格名称能自动变化，这里一次拖拽可以拖拽一片区域，但是如果不是连续的区域，那就不行了，只能一个个复制粘贴再手动调整单元格名称，重复操作太多了。

总结一下：报表工具设计流程上可能区分不大，这时要注意细节。比如润乾报表操作比较灵活能够快速的实现需求，但需要手写表达，对初学者有一定难度。而另一款工具使用向导方式操作上更容易，这对于初学者比较有利，但如果是熟练工种，反而会影响开发效率。像字段计算这些需求，需要在取数阶段进行设置，功能上也有限制。选择报表工具时要考虑到未来的使用人群是初学者还熟练工。

实例 2：非关系型数据库数据

数据来源不仅仅来自于能通过 JDBC 连接的关系型数据库，还可能来自 NOSQL 数据库、文件数据或者一些接口数据，有如下 JSON 数据：

要求从 JSON 中取数，统计订单金额前五名的信息：

这个示例的考察点：

1：从多层 JSON 不同节点中取数的能力。能否便捷地取出需要的数据是决定报表开发效率的一个重要因素，从需求中看到，JSON 数据是一个多层结构，而报表需要的数据在多层 JSON 的不同节点中。

2：报表中只需要展示排名前五的信息，是否有更优的解决方案

仍以润乾报表为例：

润乾报表提供了一种数据集类型——脚本数据集，通过内置的函数能解析 JSON 文件数据，并在脚本中对数据做过滤、运算、排序等设置，使得原来要到报表里的一些操作直接在取数阶段完成，如：

报表模版设置就很简单了：

再看另一款报表工具的实现，该报表工具中提供了 JSON 数据集插件，安装后可以解析 JSON 数据，如：

通过 JSON 数据集插件可以对数据进行过滤，可以取多层 JSON 中数据，但是没法跨节点取数，比如需求中的数据分别在 user_info 和 order_details 节点下，这里没法同时取出两个节点下数据，只能写 JAVA 程序去解析，这个难度就很大了，代码这里就不具体写了。

至于报表中只取销售额前五的信息展示，这个只能取出数据后在报表中按照人员对销售额进行汇总排名，然后通过动态隐藏行的方式实现。

对于 JSON 数据，常见的解决方式是通过 JAVA 程序调用相应的接口解析数据然后返回给报表，这显然非常难度太大且非常麻烦，效率极低。有的工具会提供了 JSON 数据集的插件，但因为 JSON 数据的层级以及节点不固定，插件常常也难以适应。像润乾报表这样提供脚本功能就方便多了，通过内置的函数能快速处理 JSON 格式数据。

实例 3：动态数据来源的设置

当数据库数据量大时，往往会采用分表或者分库方式来存储数据，如：

每个月的销售数据单独存放在一张数据库表中，而报表统计数据时需要对几个月的数据做汇总，如根据传入参数动态统计几个月的汇总数据：

参数是动态传入的，没法直接写出一个固定的 SQL 去查询数据，往往需要存储过程来实现，此例主要考察下报表工具是否能处理这种动态数据源甚至是否能替代存储过程的能力。

还是先看润乾报表的实现方式：润乾报表可以通过脚本数据集方式代替数据库的存储过程，采用内置的函数以及语法动态控制数据的来源：

在脚本数据集中可以根据传入参数做循环，动态拼接执行的 SQL 语句，写法简单，易理解，而且有专门的工具可以进行调试、查看中间执行结果，这也是比存储过程更好的地方。报表模版制作就很简单了：

再看另一款报表工具，因为没有这种独立取数的能力，只能借助数据库的存储过程或者自己写 JAVA 程序了，如在数据库中创建存储过程：

报表数据集中调用存储过程：

报表模版：

对于这种动态数据源拼接需求，常见的解决方式是借助数据库的存储过程或者写 JAVA 程序进行拼接，这些方式开发难度大、工作量高，效率低。如果有润乾报表这种脚本能力就可以更方便快捷地实现动态数据源的拼接，开发效率远高于数据库的存储过程，而且还支持异库的取数合并，更是存储过程无法实现的功能。考察时要注意这些数据准备的能力。

实例 4：不定层级树状结构报表的优化

某企业数据采用层级方式存储，通过父节点指向来确定层级结构，如下数据：

要根据如上数据制作树状结构报表：

本例主要考察报表工具面对复杂需求时是否有简化报表设计的能力，树状结构报表在国内工具里通常指定下跟随扩展关系就可以，本例难点在于层级是不固定的，现在是三层，过段时间业务发生变化可能会增加层级，用固定层级的方式就不行了。

先看下润乾报表的实现：

润乾报表的脚本数据集中是支持根据层级递归查询的：

这里根据数据里的层级递归查询，自动拼接子节点数据，返回的就是带层级结构的数据集，报表模版里只需要一个简单的列表就可以了：

再看另一款报表工具。因为没有事先数据准备的能力，只能通过隐藏行来实现，用跟随扩展方式做一个多行的报表，每行取不同层级，然后判断数据是否为空来隐藏，但是这种做法一是制作报表时需要增加很多行从而带来不必要的工作量，二是层级如果超过预定行数的话也会带来数据展示问题。有的报表工具也增加了“树数据集”来实现这种需求，比如增加数据集时可以根据父节点的关系来指定层级结构：

这里设置对应字段后会自动分析数据，生成数据集：

数据表中数据有三级结构，这里会自动增加三个字段，然后制作报表时根据这三个字段来确定报表展示的样式。但是这个还是针对固定层级的做法，如果数据库中的数据增加了层级，那么就需要更改报表模版，在地区列增加相应的表达式，带来重复的工作。

对于这种不定层级的树状结构报表，常用的解决方式是在模版里增加多行再通过隐藏行表达式动态将不需要的层级隐藏掉，这种方式报表设计时需要较多的操作，而且实际数据有可能会超过设置的最大层级导致报表的重复修改。如果有润乾报表这种在数据集阶段根据数据的层级递归取数的解决方案，直接返回带层级结构的数据，报表制作只需要一个简单的列表方式就可以了，即使数据库中的数据发生变化，报表也不需要修改。考察时要注意未来数据的变化是否需要重复修改模版问题。

实例 5：单元格集间的运算

有如下一组考试成绩数据：

要求在报表中列出历次考试成绩、名次，并根据排名统计四次考试均排名前五名的同学、前十名的同学，报表结果如下：

本例主要考察报表工具的单元格、单元格集合间的计算能力。

润乾报表中的实现：

润乾报表支持单元格跨行组的运算，名次直接用公式：=count(B4[`0]{B4>$B4})+1 就可以了。四次考试均进入前五名的同学，需要取出四次对应的排名的同学做交集运算，在润乾报表中内置了一个 spl 函数，可以传入多组数据，实现数据间的交、并、差等操作，实现单元格集间的运算能力，如 C6 表达式：=spl("?^?^?^?",A4{C4<=5},A4{E4<=5},A4{G4<=5},A4{I4<=5})，传入四次排名前五的同学做交集，这样返回的就是每次都在前五的同学。

换其他报表工具，名次这种跨行组的运算基本都支持，写法和润乾报表中类似：

但是对于由多个单元格组成格集之间的运算能力就比较弱，如果要实现的话需要增加大量辅助单元格或者需要写 JAVA 程序用自定义函数来实现，这个工作量就很大了，具体代码有些难度这里就写了。

大多数报表工具单元格间的计算能力、包括排名这种跨行间的计算都没有问题，但是由多个单元格组成的格集之间的运算能力较弱，往往需要进行二次开发才能满足。而润乾报表中提供了个 spl 函数，它是调用了另外的一个独立计算引擎（集算器），处理这种格集间的计算需求就简单多了。

总结

从几个例子看出，考察报表工具的开发效率，不能只看工具的界面模型是否漂亮、操作是否适合初学者使用，也要考虑下操作熟练的老手怎么开发报表更加灵活方便，更要关注工具是否有解决复杂需求的能力，同时也要考察下工具是否有足够的扩展能力来解决未来可能遇到的各种复杂需求。

当然工具价格也是考察的一个侧重点，毕竟工具的使用主要是为了降低项目中高昂的人工成本。更高效、更具有性价比的工具能更进一步降低项目的总成本。