从2007年开始，大量的java报表工具开始涌现，比较杰出的产品，一类是以润乾报表为代表的非线性报表模型，一类是以水晶报表为代表的传统拖拽式报表工具，前段时间我自己还整理了一篇42种子java下的开源报表工具（点这里）。本文无意评论报表工具的功能高下，仅就目前报表工具的缺陷提出一点个人看法。

在我看来，无论上述哪一种报表产品，都存在以下几个缺陷：

1、计算环节导致效率太低

一个完整的报表应用包括取数、计算、展现三个环节，目前已有的报表工具大多是将计算在数据库端完成，或者在报表端完成，如下图所示：

wKioL1LLq57wqAkNAAAk_T7HsyQ888.jpg

这种方式最大弊端就是数据库或报表端的计算压力太大，以至于报表运算速度慢，等待时间长。

计算在报表端完成还有如下缺点:

  • 展现层和计算层融为一体，处理计算的同时处理展现，导致计算效率低

  • 缺乏完备的计算体系

  • 缺少并行计算机制


2、SQL/存储过程困境

报表工具大多有自己的一套书写语法，都提供完备的SQL支持，但SQL固有的计算缺陷，使得复杂计算时大量代码的书写不可避免，具体表现在四个方面：

a、计算不分步：SQL要求计算在一个语句内写出，必须采用存储过程才能实施分步计算。不分步不仅造成思维困难，而且难以利用中间结果；而存储过程则滞留了大量中间表在db中，占据了宝贵的db资源，客观上也增加了db的扩容压力；

b、集合无序：SQL不直接提供使用位置引用集合成员的机制，与次序和定位相关的计算都需要转换才能实施，比如同期比、环比、排名等等；

c、集合化不彻底：SQL的集合功能简单，只用于表示查询的结果集，而不能作为作为基本数据类型广泛应用；

d、缺乏对象引用：SQL不支持记录引用，数据表间的关联采用同值外键方案，多表联合计算时需要做连接，不仅理解困难而且效率低下。而且随着用户系统的不断完善和数据量的剧增，与跨库有关的多表关联计算需求会进一步增多。


现代高级语言虽然没有SQL的这些缺点，但对于批量结构化数据的计算支持很弱，缺乏业内标准的组件或类库，而且由于语言机制上不支持表达式参数，使得在外部开发相关组件和类库的工作也难以完成，导致应用时仍然很困难。


3、过多的中间表和存储过程导致管理困难，DB负担过重

存储过程是线性管理，过多存储过程导致管理困难，而且挤占数据库服务器的资源，增加数据库存储负担。