报表工具的二次革命-集算报表

产生背景

报表工具是润乾的主打产品，我们在这方面积累了丰富的经验，当然，也有教训。

现代的报表工具主要解决两个环节的问题：一方面是呈现，也就是把数据以表格或图形的方式展现出来；另一方面是数据计算，即计算出源数据中没有和不能直接呈现的数据，比如一些公式格、分组汇总排序等等。

这里说的报表，主要是指用户事先确定好格式和数据运算规则的报表，我们俗称为固定报表。自助报表，也就是业务用户可以自己简单拖拽可以完成的报表，不在此类。自助报表的话题我们会专门再讲。

十年前润乾首先提出了非线性报表模型，带来了报表工具的第一次革命。这个模型从根本上解决了报表（特别是中国式报表）的复杂格式以及表内的计算问题，以此模型的润乾报表也因此取得了一定的成功，现在这个模型已经成为报表工具的标准了。

但是，有了这样的报表工具，报表开发是否就很好做了？

“并不是！”

报表工具常常会宣称自己支持“零编码开发报表”，润乾报表当然也不例外地喊过这个口号，但要认真分析下来，这是一句空话。

为什么呢？我们发现，数据库中的原始数据有时并不能直接用作报表工具的数据源去呈现，而需要一系列运算转换过程，有的过程还非常复杂。

有报表开发经验程序员都知道，为报表编写复杂SQL是经常的事，存储过程以及事先准备的中间数据也是家常便饭，有时SQL和存储过程不好写的运算还需要采用自定义数据源即JAVA程序来处理。总之都需要大量的程序编码。

虽然大部分报表还是相对简单的，这类复杂报表总数上并不算多，但其占用的开发工作量却会占绝对的大头，开发10个用报表工具能直接完成的简单报表所用的时间可能也做不了一个需要编码才能准备好数据的报表。

那么，提升报表工具的计算能力可否解决这个问题吗？

广义地说是可以的，这就是集算器的产生背景。

但是，由于数据量和数据转换具有分步性的特征，而报表工具在呈现环节的计算一般都是状态式和全内存方式，这样，无论在容量和复杂度方面都只能是很少部分地缓解这个问题而已，即使是润乾报表这样以计算能力为核心优势的报表工具也不行，数据源开发工作量依然很大，这也是我们这些年的经验。

提升报表工具的计算能力不能放在呈现环节，需要给报表应用结构中增加一个数据准备环节，这就是集算器的作用。

换句话说，当代的报表工具已经把呈现环节的格式及相关计算问题解决得很好，但在数据准备阶段仍然差得很远，需要有另外的计算手段来弥补，而集算器就是这个计算手段。

理解集算器

集算器是一种程序设计语言，它有自己的语法体系。和普通的程序设计语言一样，集算器也是由程序员编码代码后执行获得计算结果。与报表工具中的计算目标不同，集算器并不追求零编码，而是追求简单编码。

集算器不是面向对象的程序设计语言，没有复杂的类继承和重载概念，有BASIC这类初级程序设计水平的程序员都能很快掌握。集算器是解释执行的动态语言，可以在运行过程中拼出代码执行，这样可以获得更大的灵活性，进一步降低程序设计的复杂度。

与Java等高级语言相比，集算器中提供了大量与结构化计算相关的基础对象和方法，这类运算在数据分析及报表数据准备中非常常见，因而可以使得代码比Java要短得多。

大家都知道SQL用来实现很零碎的多步运算很不方便，特别是与次序相关的运算，程序员常常要把数据从数据库中取出来用Java等完成。而集算器则正好在这方面做了强化，相当于把SQL与Java的优势统一起来，让程序员可以既可享受到类似SQL的批量集合式计算、又能获得类似Java的灵活性。

集算器虽然在大多数情况下的语法要比SQL更简单易写，但并不能取代SQL。数据从数据库读出的IO成本相当高，有些涉及数据量太大的简单运算，数据读出的耗时远远超过运算本身，这种情况还是放在数据库中运算更合适。

集算器本身是用Java开发的，与Java有天然的兼容性，而且集算器的设计定位就是被集成，所以与Java的集成性非常好，特别地，对于Java报表工具，用集算器为之提供数据源非常方便。集算器提供标准的JDBC接口，报表工具可以象访问普通数据库一样访问集算器，集算器的jar包也可以和报表工具一起部署发布，完全无缝集成。

这一点与其它如perl,python,R等其它脚本语言不同，这些语言在某种程度上也方便用于实现许多结构化计算（细纠起来还是不如集算器专业），但很难被报表工具调用。

接下来的文章，我们会继续为大家讲解计算引擎-集算器。想要了解更多，请持续关注我们哦。