复杂报表复杂在哪？

  报表开发者总会遇到一些较为复杂的报表，这类报表的数目通常很少，但花费的开发时间却很多，有时候还会变成疑难问题。本文将讨论这些复杂报表到底复杂在哪方面，以及该用什么方法去解决，希望对提高报表的开发效率有所帮助。

  以前的复杂报表主要复杂在前端：

n  单元格合并，斜线表头。

n  字体风格根据数据大小发生变化。

n  任意单元格之间的计算。比如针对几条特殊的明细数据，计算它们和汇总值的比例。

n  片区之间有规律的计算。比如横向表头是产品分类，纵向表头由两种分组拼成：三层机构分组、单层年度分组，交叉处要显示某类产品在不同分组中的销售额。

n  不规则分组。比如按照州、州府间隔显示各州的产品销量（总计时不能重复计算州府的销量）。

  

  报表工具经过十年的发展，上述前端难题大都已经得到了妥善的解决，比如Style Report、Runqian Report、QlikView、Tableau，它们各自用不同的方法解决了上述难题。

  现在的报表主要复杂在后端，即数据源的计算。

n  复杂的业务逻辑。比如：找出连续三个月销售额增长超过10%的销售人员，展示他们的销售额和销量。再比如：找出购买过参数列表中所有item的Customer，展示这些Customer的帐户余额。

n  跨库计算。比如：某企业要根据绩效和基本工资核算不同工种员工的实际工资，基本工资存储在财务管理软件的MSSQL数据库中，而绩效分数存储在绩效考核系统的Oracle数据库中，请将绩效分数转化为工资数额并呈现在报表中。再比如：某连锁商场各门店都有自己的数据库，总部需要用报表来呈现这些数据的汇总结果。

n  非数据库数据源的计算。比如：根据Excel中的数据，从多只股票中选出连续上涨5天的股票。再比如：根据日志中的数据，展示出指定时间段内每个用户对每种产品的关注时间。

n  多源合并为单源。比如，BIRT、Crystal Report、JapserReport等报表工具对多数据库支持不够方便，经常需要编写用户自定义数据源将多源合并为单源。

   

   常见的报表工具只负责将取到的数据呈现出来，不涉及后端数据的生成，报表开发者必须自己想办法解决上述问题，因此报表后端的复杂性一直是困扰报表开发者的最大障碍，也是复杂报表之所以显得复杂的主因。同时，现代报表讲究简洁易读，用户对复杂样式的要求在逐渐降低，而对数据本身的关注程度更高，复杂报表的重点早已从前端呈现转移到后端数据源。事实上，前端的复杂性也大多可以通过后端来解决，比如片区之间有规律的计算、不规则分组，这就使报表数据源的计算更加重要。

 

   解决报表中复杂的数据源计算，可以采用SQL\SP，中间数据库、自定义数据源等三种方式。

   

   SQL\SP理论上可以解决复杂的业务逻辑，但一方面仅限于单数据库的情况，对于其他情况无能为力，比如：非数据库数据源、跨库计算、多源合并为单源。另一方面，复杂业务逻辑并非普通的报表开发者就能轻易实现，往往需要调配更加资深的程序员。由此可见，SQL\SP能解决的问题有限，对人员的要求较高，不足之处非常明显。

   

   中间数据库可以用来实现跨库计算，即把异种数据库的数据加载到同一个数据库，再用报表工具来访问中间数据库中的统一视图。中间数据库一般需要单独配置，会增加额外的成本负担。另外，中间数据库有一个加载的过程，实时性比较差。如果想实现增量实时加载，就需要建立调度任务或在源库中添加触发器和时间戳，并书写较为复杂的数据加载脚本，显然，额外的开发工作量会显著增加。不仅如此，很多商业软件的数据库是不允许擅自修改的，无法添加触发器和时间戳，性能的提升也就无从谈起。由此可见，中间数据库的不足之处是成本高、开发工作量大、实时性和性能得不到保障。

  非数据库数据源的计算也可以采用中间数据库的办法，优缺点也大致相同，区别主要在实时性和成本上。首先，非数据库数据源难以增加触发器和时间戳，无法实现实时计算。其次，很多非数据库数据源的数据量较大，会占用宝贵的数据库存储空间，成本更高。比如前面根据日志数据计算关注时间的例子，商业网站每天的日志都有几千万条，一年的数据可能就有几个TB之多，中间数据库不得不面临频繁升级之苦。大数据量还会对性能产生较大的影响，要想提升数据库的性能，就要采用并行数据库，成本非常昂贵。

  自定义数据源是大部分报表工具都会提供的接口，解决多源合并为单源的问题比较方便，其中最常见的是用户自定义Java Bean。用户自定义Java Bean允许开发者用高级语言将异构数据库、异种数据源、半结构化数据源的数据合并为单一数据源，优点是灵活自由无所不能，但缺点也同样明显。和SQL/esProc/R这类专业的数据计算语言不同，JAVA等高级语言缺乏结构化计算函数，开发者首先要实现过滤、分组、汇总、排名、排序、唯一值、关联算法等大量的底层函数才能进行计算，开发工作量巨大。对于一般甚至是较为简单的算法来说，用高级语言实现都极为困难。

R语言也可以用作自定义数据源。它的优点是库函数丰富，可以进行混合计算，缺点是没有JDBC接口，在性能和稳定性也较差，所以实践中很少有人用它来解决报表数据源中的复杂计算。

润乾公司开发的集算报表不仅可以很好的实现报表的复杂展现问题，也可以很好的完成报表中复杂的数据源计算任务。

集算报表内置了编程语言集算器esProc，是自定义数据源编程的利器。和SQL类似，集算报表的esProc是专业的数据计算语言，具有丰富的结构化数据计算函数，所以可以轻松解决第一类难题：复杂的业务逻辑。和R语言类似，集算报表通过esProc可以直接进行数据库、文本文件、Excel、半结构化数据的混合计算，无需中间库暂存，因此能够实现高性能低成本的跨库计算和非数据库数据源计算。esProc面向应用开发者，语法简单，代码易于书写，交互性强，调试功能完善，因此对开发者的技术要求较低。集算报表可以通过jdbc方式调用esProc，也可以通过定义“集算器数据集”来直接调用。集算报表内置esProc单机并行计算引擎，可以将充分利用多CPU或者多CPU核的计算资源，性能表现优异。

下面举例说明集算报表自定义数据源编程的方法，比如前面跨库计算中的例子“根据绩效分核算实际工资”。

l  跨库的关联计算：A5

l  复杂的业务逻辑：A6-C9

l  结构化数据计算函数：A4、A10-A13

l  返回输出结果：A14

集算报表调用这个集算器程序的配置如下：

 上图中ds1接收esProc返回的结果集，test.dfx是esProc的程序文件名。