主流Java报表工具功能对比 -- Style Report、水晶报表、数巨报表、润乾报表

这几年Java报表市场很是热闹了一阵，先是水晶报表、Brio、Style等海外产品相继杀入市场，而后是国内的华表、中创、数巨、和勤、润乾、杰表等揭竿而起（这中间有的是仅支持Java的，有的是支持所有WEB环境的），一时间狼烟四起，概念战、眼球战、价格战，好一番厮杀。

到如今尘埃落定，天下三分——

水晶报表、Brio分别归入BO和Hyperion门下，倚仗BO和Hyperion在BI领域的高墙深壑，坚守最后一块底盘；

Style Report、数巨报表、和勤报表以智能分析型报表为依托，虎踞市场腹地，并昼夜厉兵秣马，加强BI产品 功能，期待有朝一日可白衣渡江，在BO和Hyperion眼皮下虎口夺食；

华表、中创、润乾、杰表等单一展现型报表，大多已是风流总被雨打风吹去，目前唯余润乾与杰表尚在厮杀，但前有Style、数巨、和勤等分析型报表打压，后有JasperReports、Eclipse BIRT等开源产品侵扰，虽不至于势若危卵，但总不是那么轻松写意。

市场三分，究其根源，在于产品。功能和性能—— 软件永恒的话题，最终决定产品、 企业未来发展的原动力。那么，本文就来分析一下各 Web报表的功能与性能。

分析对象： Style Report、水晶报表、数巨报表、润乾报表
分析方法：抽取各个产品演示样例及说明 文档中，最具有代表性的报表，将这些报表使用其他产品进行设计，以比较功能、性能优势。


报表1：


样例提供者：Style Report

各产品得分（满分10分）：
Style Report：10
水晶报表：7
数巨报表：10
润乾报表：10

评分依据：

这张报表其实在设计上，并没有什么特殊的要求，仅仅是繁杂。

目前的报表 工具有两种设计模式：一种是带状模式，以控件在带状区域的摆放为设计方法，以灵活性和扩展性为主要设计优势，缺点在于绘制复杂表格时需要消耗一定的工时，上表就是一个典型的例子。另一种为表格模型，类似Excel，以简化表格设计复杂度为主要优势，在绘制表格时比较方便，缺点在于灵活性及扩展性不及带状模型。

上表的两个特征：静态表格结构繁杂、以常规方式显示 数据，故而最适合的是采用表格式而非带状模式。

在四个报表中，Style Report采用表格模式，水晶报表采用带状模型，数巨报表可同时支持表格模型和带状模型，润乾报表采用表格模型。故而给予Style Report、数巨报表、润乾报表均为10分，而水晶报表虽然采用带状模型，但通过一定的工作量可以完成上表设计，并且提供了多种快捷方式以优化设计过程，故而给予7分。

报表2：


样例提供者：Style Report

各产品得分（满分10分）：
Style Report：10
水晶报表：8
数巨报表：10
润乾报表：10

评分依据：

这张报表是一个交叉表，左侧的“钢类”、“序号”，根据数据源返回数据自动向下扩展；上表头的“钢锭”等字样，根据据数据源返回数据自动向右扩展。从这个角度说，这张报表不算复杂。

稍微有些复杂的第二列“序号”和第三列“合计”。显然，序号是不可能作为一个字段在数据源中出现的，而合计按照标准交叉表设计模式惯例，是放置在最后一列的。这就需要对交叉表进行额外的处理。

一般采用的方式是分为多个设计片区进行处理。

在Style Report、数巨报表、润乾报表中，都有报表分片设计的概念，可以将一个平面表分解为多个具有逻辑关联的片区进行设计，各个片区间可以进行跨片区运算。这样上表设计起来就非常简单了。故而这三个产品在这个功能上都给予了10分。

但是在水晶报表中，只能采用多个子报表拼接的方式完成上述要求，在各个子报表拼接位置、逻辑关联方面设计起来比较麻烦，故而仅给予8分。


报表3：