零编码制作报表？

许多报表工具都宣称可以零编码制作报表，只需要拖拖拽拽就能完成报表的开发，事实上真是这样吗？

确实有不少简单的报表可以通过拖拽完成，比如常见的分组、交叉报表。报表工具近年来的发展又进一步扩大了这个范围，有不少多源关联的报表也能通过拖拽再加简单的公式填写即可完成，基本上算作是零编码。

但是，仍然有一些复杂的报表无法用报表工具完成，特别是数据源计算如果比较复杂的话，不写代码是无法实现的。分析其原因如下：

1、  原始数据库结构一般为交易系统设计，不适合统计报表直接展现，导致从原始数据得到报表数据的业务逻辑非常复杂，必须写代码来实现。

2、  即使是经过数据整理的数据仓库，其结构也不能适合所有的报表，特别是项目后期出现的新报表，一般都要在数据仓库的基础上做进一步复杂计算才能提交给报表工具来展现。

复杂报表虽然只是报表项目的一部分，但因为实现难度较大，最终占用的工作时间反而比常规报表更多。而且也决定了我们不能100%的实现零编码制作所有报表，在报表项目中需要将报表工具制作的模板和对应的报表模板合理地组织管理。这种情况下，我们有必要想办法提高编码效率、降低代码的管理难度。

那么，现有的数据计算程序语言有什么需要改进的么？

一、现有编程语言实现报表数据准备和计算，难度大、效率低、性能较差。

在实际项目中，报表开发人员必须编写一些很长很复杂的SQL语句（存储过程），或者采用Java、C#程序来为报表计算和准备数据。报表开发人员会发现，使用SQL（存储过程）或者程序语言来实现复杂统计运算非常困难。特别是与序和集合有关的运算，如计算每月销售额都排进前10名的产品、连续五天上涨的股票等。

我们以SQL为例发现：为报表准备数据的SQL过于复杂，可能长达数十行甚至数百行。下面Oracle的SQL语句，其中使用了窗口函数。对于其他数据库而言，对窗口函数的支持一般都不如Oracle，写出的SQL可能会更长。

例子1：计算每个月的销售额都在前10名的客户。

select Client from(

select * from(

select B.*,row_number() over(partition by month order by SumValuedesc)

rown from(

select to_char(SellDate,'mm') month,Client,sum(Quantity*Amount) SumValue

from contract

where SellDate>=to_date('2012-01-01','yyyy-mm-dd')

and SellDate<=to_date('2012-12-31','yyyy-mm-dd')

group by to_char(SellDate,'mm'),Client order by month,client

      ) B

)C

where rown<=10

)D

group by Client

having count(Client)=(

select count(distinct(to_char(SellDate,'mm')))

from contract

where SellDate>=to_date('2012-01-01','yyyy-mm-dd')

and SellDate<=to_date('2012-12-31','yyyy-mm-dd')

)

 

例子2：连续五天上涨的股票。

select max(连续日数)

from (select count(*) 连续日数

from (selectsum(涨跌标志) over(order by 交易日) 不涨日数

from (select 交易日,

case when 收盘价>lag(收盘价) over(order by 交易日)

then 0 else 1 end 涨跌标志

from 股价表) )

group by 不涨日数)

这两个例子还是相对简单的计算，对于更复杂的业务逻辑，会出现多层嵌套、众多窗口函数的SQL语句，可以达到几十甚至上百行。这些复杂SQL不符合自然思维习惯，不仅编写调试困难，也难以维护，时间长了即使编写者自己也需要花费较多时间重新理解。

而且，复杂SQL执行起来一般都比较慢，会出现最终用户长时间等待报表的情况。因为难以完整指定数据库的执行路径，报表开发人员想人工优化这些复杂SQL的时候也会发现很难入手。

二、现有编程语言代码与应用系统其他模块耦合过于紧密，代码管理困难。

SQL和存储过程的脚本、中间表和其他功能模块的存储过程会出现交叉引用，也可能被应用程序引用。Java代码或者C#代码更是这样。当报表数据计算的需求发生变更的时候，程序人员要在错综复杂的程序代码和网状结构的数据表中去修改代码和数据结构。系统结构如下图：



由于这种紧密耦合的关系存在，当报表数据计算需求变更的时候，需要程序代码重新编写、重新编译、重新测试打包，甚至会需要改动应用系统程序和表结构。
润乾公司推出的集算报表可以很好的解决上述问题。集算报表内置“集算器esProc”开发语言，可以有效地降低报表计算代码编程难度，提高编程效率。
一、集算报表的自定义esProc代码更符合自然思维习惯，解决同样问题会比SQL短数倍，易于调试和维护，可以有效提高写代码的效率；而且，在集算报表的esProc程序中，是由程序员决定执行过程，更易于优化性能。
同样是上边的两个例子，我们来看一下用集算报表中实现的代码：
例子1：计算每个月的销售额都在前10名的客户。



例子2：连续五天上涨的股票。



二、集算报表可以实现报表数据计算代码与应用系统代码的松耦合。系统结构如下图：



从上图可以看到，集算报表通过esProc连接数据库的jdbc接口读取的数据，利用自带的数据计算类库处理之后，再把计算结果提交给集算报表的展现引擎。处理过程中产生的少量数据保存在内存中，大量数据保存在本地硬盘上。因此，集算报表可以实现报表与应用系统其他模块之间完全的松耦合。报表展现发生变化的时候，修改报表模板；报表数据计算需求变更的时候，只要重新编写、更新计算脚本文件和临时数据文件即可，也无需改动应用系统程序和数据库表结构。