工具，本身就是为了解决各种重复性工作效率低下的问题而诞生的产物，报表工具也是工具，所以它的诞生，它的使命，也是为了提效！是为了提升数据信息化项目中报表的开发效率而诞生的

但不同的工具，开发方式不同，效率自然也分高下。效率高的，不仅做起来简单方便，还能给项目上节省很多成本；效率低的，开发起来费事费力，不仅工程师受不了，常年累月无形中浪费掉的人工成本，企业也受不了

那怎么才能选一个开发效率高的呢？开发效率应该怎么考察呢？

很多人在考察报表工具时，会关注工具是不是有流畅的可视化操作界面（厂家也喜欢宣传这一点，零编码、拖拖拽拽做报表等等）。确实，有这种界面的工具很容易上手，能迅速开工。但是，报表工具通常是要长期使用的，这时候的重点其实是考察工具对付复杂场景的开发效率，因为长期使用后，总会碰到很多复杂的情况，而这种情况即便少，也是更费时费力的。工具一时易上手的特性并不是重点，因为程序员很快就会变成熟手

下面我们用润乾报表，通过几个由简到繁的示例来看看报表工具的开发效率应该怎么考察

示例 1：简单分组

根据如下数据表，制作报表

按销售员、类别统计订单数量，并增加合计，结果报表：

制作过程

数据集设置

ds1: select * from orderlist

报表模板设计

A2：=ds1.group(NAME;NAME:1)，按照销售员分组，可以手动输入公式，也可以报表设计器右下角选择分组方式拖拽：

B1：=ds1.group(CATEGORY;CATEGORY:1)，操作方式同 A2，设置扩展方式为横向

B2：设计器右下角，选择汇总，汇总方式选择“计数”，拖拽任意字段到 B2 单元格

B3、C2、C3：合计单元格，表达式手动输入：=sum(B2{})

报表结果

对于这类简单报表，各工具效率上基本没有什么差异，润乾报表是直接写表达式（也可以拖拽），其他工具有写表达式的，也有拖拽做的，都比较简单。有些工具的可视化的点击操作做得更人性化，体验更好，更适合初级学习人员

示例 2：带条件的分组

基于同一个数据表，我们改一下表样，稍微增加一些难度，根据日期字段中的年来分组，看看不同产品的操作上有什么变化

按照年度统计产品的平均售价，单笔采购数量不同、采购时间不同，产品的单价可能不同，产品平均单价 = 总金额 / 总数量

结果表样：

制作过程

数据集设置

ds1：

SELECTORDERLIST.ORDER_DATE,ORDERLIST.PRODUCT,ORDERLIST.PRICE,ORDERLIST.AMOUNT FROM ORDERLIST

报表模板设计

A2：=ds1.group(year(ORDER_DATE);ORDER_DATE:1)+“年”，取字段的年并分组

B1：=ds1.group(PRODUCT;PRODUCT:1)，按产品字段分组并设置横向扩展

B2：=ds1.sum(PRICEAMOUNT)/ds1.sum(AMOUNT)，先通过 PRICEAMOUNT 算出金额，再进行汇总，然后除以总数量。

难度稍微增加以后，润乾报表还是只要在单元格里写简单的表达式就可以了，依旧简单。

但有些工具不支持格子里自由写公式和条件，只能在对话框里设置，结果就是拖拽完基础表达式以后，还得打开对话框设置一下条件才可以，比如这个按年分组

从这个报表就已经可以看出一些端倪了，ds1.group(year(ORDER_DATE);ORDER_DATE:1)+"年" 是写一个这样的表达式，还是每次都多点几步对话框去设置，哪种方法的工作效率更高呢？只考察最简单的情况是看不出这些区别的

示例 3：再复杂一些的分组

还是基于这个数据表，我们做个一个格式再复杂一些的表样

按销售人员统计优质订单的情况，优质订单指：回款日期在订单日期 30 日内且单笔订单金额 >=10000

制作过程

数据集设置

ds1：select order_date,price,amount,name,re_date from orderlist where substr(order_date,0,4)=‘2012’

报表模板设计

A3：=ds1.group(NAME;NAME:1)，可以鼠标拖拽，也可以手动输入

B3：=ds1.count()

C3：=ds1.count(price*amount>=10000 and interval(ORDER_DATE,RE_DATE)<=30)

D3：=C3/B3，设置显示格式为“#0.00%”

E3：=ds1.sum(PRICE*amount)

F3：=ds1.sum(PRICE*amount,price*amount>=10000 and interval(ORDER_DATE,RE_DATE)<=30)，条件表达式和 C3 一样，可以在 =ds1.sum(PRICE*amount) 基础上，直接将条件表达式复制过来

G3：将 D3 直接复制到 G3，单元格引用名称自动变化，显示格式保留

H3：=ds1.count(price*amount>=10000 and interval(ORDER_DATE,RE_DATE)<=30 and month(ORDER_DATE)>=10 and month(ORDER_DATE)<=12)，在 C3 的基础上增加季度判断条件

I3：=H3/B3，设置显示格式为“#0.00%”

J3：=ds1.sum(PRICE*amount,price*amount>=10000 and interval(ORDER_DATE,RE_DATE)<=30 and month(ORDER_DATE)>=10 and month(ORDER_DATE)<=12)，在 E3 的基础上，直接将 H3 的条件表达式复制过来

K3：将 I3 直接复制到 K3，单元格引用名称自动变化，显示格式保留

到这个例子，是不是已经感觉这些表达式写起来也没有多困难了，即使是初学者，也能轻易看懂并写出来了，是的，有这样的感觉就对了，对于搞计算机的同学，这确实不难

再来看看其他的一些只能通过对话框来设置条件的工具处理这样的情况会怎样

每增加一个条件，一个 and，就得点一次增加，如果要修改，删除，同样得挨个去点，每次设置还都得打开、关闭一次对话框

如果每次都得这样，估计初学者也不会觉得简单而是会感到麻烦了，更别说熟练的老同学了这样无端端多出了好多没必要的操作，会浪费很多的时间，减少很多产出

懂了表达式以后，还是直接写表达式更快更好，可视化操作看上去很美，但效率并不会高

小节：

从上面三个报表我们可以看出，简单的表样，可视化的对话框设置确实使用体验更好，但格式稍微变复杂一点以后，工程师已经掌握表达式的书写以后，如果仍然还得用对话框就显得繁琐了

而且报表开发人员是技术工种，从初学者到熟手是轻而易举的事情，是否快和方便，要从一个熟手的角度去衡量，而不是初学者，所以考察的时候千万不要掉到生手容易熟手繁琐的操作陷阱中

上面三个报表都是比较初级的报表，我们更多的是从简单的普通操作上来看开发的效率如何，但实际的项目中，报表常常远没有这么简单，很多都会涉及较复杂的计算， 制作这些复杂的报表耗费的时间会更多，也更需要注重效率，所以复杂计算报表的开发效率，也是我们考察的重点

我们继续用两个示例来看下更复杂的报表的开发效率如何考察

示例 4 侧重于考察报表工具函数的功能，看一些复杂计算场景中，是否有对应的高级函数来直接解决问题，示例 5 侧重于考察工具处理一些复杂的多步、过程式计算的能力，看处理这些计算是否简单高效

示例 4：找出进步最快的 3 名同学

基于如下数据学生成绩表：

进行年度学生成绩汇总，进行班级班名以及和去年成绩对比，找出进步最快的三位同学，形成如下结果：

要点：看各工具怎么去做这个计算，看哪个更简单高效

制作过程

参数设置

报表中增加参数 nd，默认值为 2019，用于接收年份

数据集设置：

ds1：SELECT bj,studentid,yuwen+shuxue+yingyu zf,nd FROM XSCJ where nd=?，问号对应参数表达式：nd，用于对参数对应年度数据

ds2：SELECT bj,studentid,yuwen+shuxue+yingyu zf,nd FROM XSCJ where nd=?，问号对应参数表达式：nd-1，取参数对应上一年数据

报表模板设计：

A3、A4 单元格合并，按照班级分组，设置显示值表达式：chn(int(value()))+“班”

B3、B4 分别取出姓名、分数字段

D3：=count(C3[A3]{C3>$C3})+1，班级内排名

E3：=count(C3[`0]{C3>=$C3})+1，年级排名

F3：=ds2.select(zf,bj==A3 && studentid==B3)，从 ds2 数据集中取出去年成年，条件直接写在 select 函数内

G3：=C3-F3，成绩变化

B4：=“班内成绩提升最快的三位同学是：”+string(esproc(“?.m(?.ptop(-3))”,B3{},G3{}))，使用润乾内置函数 esproc，将 K3 单元格（名次变化幅度）传入,ptop(-3) 取最大的 3 位的位置，然后用 m() 函数根据位置取对应的姓名

结果如下：

这个例子主要是测试报表工具的一些复杂计算能力，如果报表工具的模型中函数较为丰富且计算能力强，比如润乾报表内置了很多开源 SPL 计算工具的高级函数，那处理起复杂计算来就会游刃有余

如果函数计算功能不足，那就得通过多步计算，额外在报表中设置辅助计算格才可以完成，比如有些报表工具，需要像下面这样用 H 列进一步计算需要的数据，然后再隐藏掉

这些额外辅助计算格，不仅增加了开发工作量，数据量大的时候，还会影响报表的性能

其实这款报表已经不错，提供有层次坐标之类的东西，用隐藏格还能做出来，有些报表工具连这个都没有，只能自己在外部写代码实现了，工作效率会大受影响

示例 5：找出指定时间内的大客户

从如下销售数据中：

取出指定时段的大客户。所谓大客户，定义为销售额占前一半的客户，也就是把客户销售额从大到小排序后，前面若干个客户的合计销售额构成总销售的一半，这些客户被称为大客户

报表结果：

制作过程

数据集设置

润乾报表内置了高效的开源计算工具 SPL，可以通过内置的脚本更简单高效的计算这些复杂的多步计算，把计算结果当做数据集直接供报表来使用，脚本如下：

A3：对销售额进行求和操作并处以 2，取出总金额的一半，用于判断大客户。B3 设置初始值为 0，用于做销售额累加操作

A4：对销售额进行累加，取出累加金额大于 A3 中对应的 A2 的序号

A5：根据序号取 A2 中对应的值，并做为结果集返回给报表

报表模板设计

报表结果

从这个例子可以看出，原本需要在报表中做大量计算才能做出的报表，经过脚本准备数据后，只需要在报表中直接取数就可以了

如果没有脚本，那就只能在报表中完成这样的计算，写起来麻烦，需要设置很多辅助格，同时增大了实现难度，对人员要求变高了很多（意味着成本上升），而且性能也远没有脚本的好

本示例只是举了一个很小的需要分步计算的例子，就已经可以看出不同工具的设计效率了，一个简单易懂的脚本搞定，还是一堆辅助计算格 + 复杂的表达式来完成，开发效率差异是显而易见的

实际的项目中的复杂报表，对原始数据的处理和计算，远远要比本例复杂的多，如果有脚本功能，那可以用脚本来处理这些计算，不仅写起来简单，算起来还快，如果没有脚本功能，那就只能用成百上千行的复杂 SQL，存储过程或者高级语言去写了，那样开发效率就更低了

所以我们考察报表工具对于复杂报表的开发效率时，可以看看自己的项目中有没有需要写复杂的 SQL、存储过程或者更复杂的数据来源处理的报表，拿来找各工具测试验证下，看看它们的效率都如何

价格也是个重要因素

价格和考察开发效率也有关系吗？

还真有，考察开发效率的最终目的不就是为了节省时间和人工成本吗？都是为了省成本，那价格上省出来的成本其实更直接。工具的购买价格和开发效率要放在一起综合考虑才能得到总体的成本

比如大家可能都会想到使用不要钱的开源报表，购买价格为 0，但开发效率太低（面对我国的复杂报表），结果总体成本却不低。而商用报表工具虽然要花钱，但开发效率能提高很多，有可能总体成本会更低。

当然，价格很容易对比，只要别忘了就行了

总结

怎么考察报表的开发效率，相信大家看过上面的考察要点和示例以后，应该都比较清楚了，其实并不难，那就是实际去用一用，看看一个熟练的工程师用起来繁琐不繁琐，测测项目上格式和计算复杂的报表各个工具做起来困难不困难，用过试过就找到答案了

同时，价钱也挺重要