报表软件比较参考
转载:报表软件比较参考
http://www.cnblogs.com/freeze44/
报表工具的考查指标与比较
国内市场上的报表工具大约有二三十种，比较活跃的也有十多种。面对这些绘乱杂陈的产品，很难仅从某一个方面就将它们都分类阐述清楚，更无法简单地分别打分评出优劣，必须分别从多个角度把各产品放在一起加以比较讨论才能对其在市场中所处地位有较深入清晰的认识。考虑到目前应用现状，我们主要讨论支持 B/S 应用的产品，具体范围主要集中在如下 16 种产品（这里是按字母次序、排名不分先后）：
actuate 、 bo 、 brio 、 cognos 、 crystalreport 、 jasperreport 、 mstr 、 stylereport 、博易智软、和勤、杰表、如意报表、润乾报表、数巨报表、用友华表、中创 inforreport 。
这些是市场上比较活跃的产品。其它产品或应用量太少或未采用商品化的运作模式，在程序员群体中上缺乏影响力，在讨论中不再重点陈述，只会在某些专题比对时提及。
1. 产品产地
从产地上可以简单地分作 国外产品 和 国内产品 两类，这个看起来似乎没什么意思，但其实这两类产品还是有较明显的差别，而且这样分类后在以下的讨论中也能比较方便地讲述。
从产品名称上很容易就区分出这两个类别（上述列表中全英文名的是国外的），这里就不再重复罗列了。
国外产品一般都价格较为昂贵（常被称作高端产品），而国内产品则普遍比较便宜，个别报价较贵的，也能被砍得很便宜；国外产品大多数都带有 BI 色彩，而国内产品则大多是纯报表产品；
当然，也有个别特例，比如国外产品 stylereport 的报表部分就比较便宜，比国内产品润乾报表的企业版便宜许多；而国内产品博易智软与和勤都有较强烈的 BI 色彩，国外产品 crystalreport （水晶报表）的 BI 色彩则不太浓（ BO 公司有更适合于主打 BI 的产品）。
另外，国外产品是从简单的西方报表模型抽象出来的，处理中国复杂报表的能力都较差，而且一般不会提供任何变通的手法，而国内产品中无论自创的还是抄国外的，大多数对复杂报表解决也不够好，但针对个别问题一般都会有些变通手法，因此对国内应用适应性更强一些；国外产品的历史大都很久，做工非常精细，除了模型算法不太适应国内需求外，常识性的细节都会搞得很好（如编辑器中的 UNDO 、统计图绘制的美观度等），而国内产品历史积累较短，个别厂商技术能力也较差，导致产品较粗糙和细节不完整。
2. 实现技术及原创程度
目前 J2EE 技术在国内的 B/S 应用开发中占主导地位，对 JAVA 的支持也是报表工具的一个重要考查指标。从这个意义上讲，报表工具可以分为 纯 JAVA 和 非纯 JAVA 两种 ，注意所有声称支持 B/S 应用的报表工具都能支持 JAVA ，所以不必再区别这一点。
相比之下，纯 JAVA 产品具有明显的优势。产品能够与 J2EE 应用完全无缝结合以达到最高的运行效率、安装部署很轻松简单（其机制与应用本身完全一致）；同时还可充分利用 J2EE 应用服务器强大的集群平衡负载及共享管理的能力，适合支持用户数众多的大型应用系统；由于 JAVA 的跨平台能力，还能让整个应用系统轻松地从低端体系向高端体系迁移，系统容量变大时只要更换硬件、操作系统及数据库等系统部件而无需或很少需要重写软件。
而非纯 JAVA 产品则相反，经常只能在 Windows 下运行（个别国外产品宣称支持 UNIX 但部署极为复杂，和不能用差不多）、同样的应用在不同规模下可能需要两套解决方案，或在大型应用中除了 UNIX 主服务器外还必须专门部署 Windows 作为报表服务器 , 显得体系结构非常古怪；产品也不能和 J2EE 的应用无缝结合、沟通需要沟通额外的网络协议导致运行效率较低，而且由于不能享受应用服务器的集群机制（国外产品常常有自己的集群机制但显然没有 J2EE 应用服务器搞得专业），难以支持多用户的大型应用。
国外产品中 stylereport 是纯 JAVA 的，而常见的 crystalreport （水晶报表） , bo, brio, cognos, mstr, actuate 都不是纯 JAVA 的，开源产品 jasperreport 也是纯 JAVA 的。国内产品中润乾报表、博易智软、和勤、杰表是纯 JAVA 的，而如意报表、数巨报表、中创 InforReport 、用友华表都不是纯 JAVA 的。
除了采用的技术外，其技术的原创程度也是个较重要的指标，它能够在某种程度上体现公司的研发能力以及产品的后续升级能力。手中不掌握原创技术的厂商无法对产品有完全的控制，其产品发展将严重受制于人，显然不适合与之长期合作。
所有国外产品都是原创技术的，国内产品中润乾报表、中创 InforReport 、用友华表都有原创技术，可以放心长期应用；和勤是引进的技术，但应已消化吃透，也基本没大问题；但如意报表和数巨报表则是采用了第三方控件，长期合作则可能有技术风险。
3. 绘制方案
从绘制方案上分一般有 网格式 和 控件拖拽式 两种，前者采用和 EXCEL 类似的方案，用网格线围出报表；而后者则是用矩形框等元素拼出报表。
国内报表对样式要求非常复杂而且严格，绘制方案是报表工具相当重要的指标，它决定了报表样式的复杂度和绘制效率，以及导出 EXCEL 的能力（这是用户很强调的功能）。
网格式在这方面有明显的优势，能够画出样式很复杂的报表，绘制效率也比控件拖拽式高出 10 倍以上，而且导出 EXCEL 时格式上不会失真，个别产品还可以直接读入 EXCEL 画好的表以进一步提高效率。相反，控件拖拽式则显得非常笨拙，表格线需要靠矩形边框重合摆放拼接出来，常见的复杂多层表头画起来非常繁琐，数据区某些纵向合并格甚至无法绘制出来，拼出的格线还与分辨率相关，屏幕上对齐的表在打印时或在 WEB 上显示时又可能不整齐，生成 EXCEL 时经常丧失格式或导致格线太多太细而无法应用，读入 EXCEL 格式则更是完全不可能有的功能。
国外产品中除 actuate 中提供的 spreadsheet 是采用网格式外，其它全部采用控件拖拽式（从另一侧面能反映国外产品对国内需求的不适应），开源产品 jasperreport 也采用控件拖拽式。国内产品中润乾报表、中创 InforReport 、杰表、用友华表、久其报表采用网格式，而博易智软、和勤、如意报表、数巨报表则采用控件拖拽式。
4. 数据统计模型
数据统计模型则是报表工具最重要的指标，它决定了报表工具的制表能力和效率，一般可分作 电子表格 和 传统工具 两类， 润乾报表 则不属于任何一类，是新一代报表模型。
电子表格类工具完全模拟 EXCEL ，没有真正意义的数据统计模型，数据须由程序员自行编程取出并运算后写入表格中，也就是没有任何自动化处理的能力，严格意义上讲电子表格类产品并不能称作报表工具，但有时也会混在一起讨论。用友华表是电子表格类产品的优秀代表作，几年前还有个国外的 formula1 比较流行，后来被 actuate 收购后改造成 spreadsheet 后拥有了数据处理能力。
传统工具目前还是报表市场上的主流，其基本特征是单数据源、条带式编辑与统计方案，在不编码的情况下只能完成简单地行式（分组）报表和单片交叉报表，稍有复杂的中国报表都需要另行编写代码准备数据，导致报表制作效率低下甚至不能完成，这一点可参见 " 新一代报表工具的标准 " ，其中较详细地阐述了传统工具处理中国复杂报表时遇到的困难。
除上述提到的电子表格类以及润乾报表和中创 InforReport 外，其它产品，无论控件式还是网格式，都采用同样的数据统计模型，都是传统工具，处理中国报表时都会有类似困难。
润乾报表采用了完全不同的数据统计模型，比较彻底地解决了中国复杂报表中的多源分片、不规则分组、动态格间运算和行列对称等困难问题（ " 新一代报表工具的标准 " 中有述），比传统工具的制表能力和效率有大幅度提高。
中创 InforReport 要另类一些，从表面上看起来也是采用了自己独特的数据统计模型，比某些其它传统工具处理复杂报表时有优势，但仔细深究，其实是传统工具是另一种变形，并没有从根本上解决了上述中国报表的困难。但考虑到其独特性，会专门再对此进行讨论。
5. 前端展现方案
在浏览器中展现一般有 HTML 和 控件 两种方案，某些产品两种方案都提供。有时还可以 EXCEL 和 PDF 的方式嵌入在浏览器中展现，但不是重点，这里不作讨论。
HTML 的优势是客户端完全无须安装程序，也不会有安全（病毒或泄密）问题，但由于 HTML 的先天不足，其交互操作和精确打印能力性要弱一些；控件则弥补了这方面的不足，但又需要下载从而带来安全问题（病毒等木马），而且只能支持 IE ，某些应用环境直接不允许安装任何控件。
HTML 方案还可再分为 纯标准 HTML 和 支持 IE 的 DHTML 两种，前者可以展现在任何浏览器上（ IE 和 Netscape ，这样客户端可以是 Linux ），后者则只能在 IE 上工作。
统计图的展示也是个需要关注的环节，一般可分为 纯 HTML 图片 和 控件 两种形式，有些工具虽然可以提供 HTML 的报表展现，但统计图部分却只能采用控件，这里需要特别关注的。 HTML 图片方式应用非常简单，但交互能力略差，控件则反之，交互能力强些但有下载等安全类问题。
另外，打印是个非常重要的展现环节，一般会有 HTML 打印 、 控件打印 、 JavaApplet 打印 和 生成 EXCEL/PDF 打印 几种方式。 HTML 打印不够精确，一般用于信息输出是可以，但很难用作正式格式的文件；控件和 JavaApplet 都能够实现精确打印，与控件相比， JavaApplet 从协议上没有安全问题，但又不能一次下载，若不大还可接受，否则也很不方便；生成 EXCEL/PDF 再打印能保证精确度，但要求客户端事先安装好相应程序，解决方案也不一致，有时也不是很方便。
所有的纯 JAVA 产品（无论国内国外的）都提供 HTML 报表展现、 HTML 图片的统计图方案和 JavaApplet 打印机制；国外产品中除 stylereport （纯 JAVA 的）都能提供 HTML 和控件两种形式展现和打印形式，但几乎全是仅支持 IE 的 DHTML ，某些产品（如 bo ）的统计图还只能以控件形式提供；国内产品中，如意报表、数据报表可提供仅支持 IE 的 DHTML 和控件两种，但 DHTML 实际上很少用，用友华表和中创 inforreport 只提供控件。
6. 后台集成方案
后台集成方案主要有 完全嵌入 、 独立服务器 和 控件数据服务 三种。
完全嵌入指报表运算服务不单独存在、而与用户应用程序结合成一体，主程序对报表服务的无缝调用，这样可以达到最高的运行效率和最深入的控制，同时可以享受应用系统的集群部署与数据连接共享能力以及不必专门处理权限门户的事务，是最经济高效的集成方案，但必须是报表工具与应用程序基于同种技术实现才可以做到。
独立服务器指报表运算在物理上独立存在（有时甚至会是一台专门的机器），用户应用程序通过网络协议调用报表服务，效率受到影响且控制力度不深，并且不能共享应用系统的集群和负载平衡能力，还迫使应用程序必须采用报表服务器的门户权限机制，导致多余的工作量。独立服务器的优点在于对宿主应用程序的技术体系没有要求，采用不同技术的应用可以同样的方案集成起来。
控件数据服务则专指以控件作为前端方案的产品在后台的集成方案，运算接口都在前端的控件中，需要把复杂的程序写到页面的 JavaScript 中；后台则几乎没有运算，只是将数据取出送给前端，程序简单可完全嵌入但并没什么接口，这种方式无法发挥后台服务器的强大计算能力，而且有关处理代码将在前端暴露出来造成安全隐患，不适合大型应用。
除了报表运算本身的集成外，还要考查有生成的统计图（及 EXCEL/PDF ）等二进制数据的引用方案，一般有 数据流服务 和 临时文件 两种。前者是将这类运算在后台组织成一个服务（在 J2EE 中是 servlet ），将结果以数据流（如 JPG 图像流）的形式返回给前端显示或下载，后台服务器上并不会真地产生一个文件；而后者则会将统计图（或 EXCEL/PDF ）物理地在后台服务器中产生成一个临时文件，浏览器上的图片或下载链接指向该文件，采用最传统的 http 机制完成图片显示和下载文件。
相比之下临时文件方案有明显的劣势，必须操作系统放开对硬盘某处的写权限（这在某些系统下可能导致是严重的安全问题），创建临时文件会占用硬盘空间而且降低访问速度，而且这些文件的命名（不得重名）及删除都需要较复杂的管理（有些产品只会创建而不会自动删除）。
纯 JAVA 的产品在 J2EE 机制下理论上都可提供出完全嵌入的方案，但 stylereport 、博易智软、和勤等产品仍以独立服务器方式提供，润乾报表和开源的 jasperreport 均提供完全嵌入的方案；而在非 J2EE 机制下，这些 JAVA 产品都只能以独立服务器方式存在。除 stylereport 外，其它国外产品在任何环境下都仅提供独立服务器方式。国内以控件为展现方式的产品均只有控件数据服务方式，如数巨报表、如意报表、用友华表。
纯 JAVA 产品均可提供数据流服务来引用二进制数据，而非 JAVA 的独立服务器产品（都是国外产品）大多采用古老的临时文件方案提供这项服务。
7. BI 色彩
事实上，有许多作为报表工具销售的产品其实是 OLAP 前端工具，并非纯正的报表工具。这些产品虽多少有些报表的功能，但处理得很不专业，处理复杂的中国报表固然差得很远，就算是简单的西方报表也在细节处理上大不如人意，其绘制方案、集成方案、展现方案等都很不适合国内报表的需求。但由于国内市场上 OLAP 的应用面尚比较狭小，这些产品凭借自己在 BI 领域的声望也来抢夺客户。
国外产品中 crystalreport 和 stylereport 是主要为报表服务的，其它产品如 bo 、 brio 、 cognos 、 mstr 、 actuate 则都是 BI 类产品。 actuate 的 spreadsheet 可算作报表工具， cognos 最近推出的 reportnet 也加强了报表的能力。国内产品中博易智软与和勤都是 BI 类的产品，其它如润乾报表、杰表、如意报表、数巨报表等都是纯正的报表工具。
8. 填报能力
填报是国内报表应用中非常关注的能力，有时甚至是必不可少的关键功能。但绝大多数报表工具完全没有填报的能力。所有国外产品、有 BI 色彩的产品、采用传统数据统计模型、控件式编辑的产品一律没有填报功能，生成的报表只能显示，不能填写。支持填报的产品非常少，常见的有润乾报表、用友华表、武汉新连线、久其报表几家，而用友华表由于没有数据模型，表格可以填写，但需要大量编程才能完成数据入库的工作；久其报表和武汉新连线的数据模型过于死板简单，只能填出固定的数据结构，对于复杂的入库要求依然需要编码完成。润乾报表的填报方案则相对完整，可参见 " 新一代填报方案的标准 " ，其中更详细地描述了填报产品应当具备的数据处理能力。
9. 价格与商业模式
大多数报表工具都是以收取 授权使用 费用形式销售的，即应用部署一次即收取一次费用。产品的价格大体可分成 高端 和 低端 两类。
高端产品一般会按服务器 CPU 或用户数 (name user ，不是并发用户 ) 计费，其价格很不透明，很难给出明确价位，一般在几万元至十几万元之间，以前还有高达几十万上百万的销售记录，但近期由于竞争的激烈已经比较少了，有时附加上 BI 功能后仍可能卖得很高；低端产品一般在几千元（ 3000-6000 ）左右，一般只按装机量计费。
所有国外产品和有 BI 色彩的产品都可以算是高端产品，国产的润乾报表（除普及版）也是高端产品；如意报表和数巨报表、杰表和润乾报表普及版则属于低端产品。有些产品的产品线较长，在询价时要确定地知道需要的版本和组件，否则差距可能非常大，如 crystalreport 的单机版只有几千元、而企业版（全面支持 WEB 功能）很可能要十几万甚至更多， stylereport 的报表部分只有两三万元、但加上部分 BI 能力了就会高达十几万元，润乾报表的普及版报价只有 3000 元、但企业版则要 25 万元， ... 。
还有的产品是以 开发工具 方式销售的，即用户一次购买后就可以无限重复使用，对于有较多次重复应用开发的开发商而言显然是最便宜的方式。活跃产品中目前只有用友华表采用这种商业模式，还有个国产报表 finereport 也采用这种方式，但很少有应用。
除了作为独立产品销售的，而在国内市场上还有一类报表产品是以项目服务形式提供的，比较著名的有广州菲奈特的 BI.Office 和久其报表，不知是产品化程度不够还是对这种商业模式偏号，这些产品一向很少由第三方开方商采用，而都是由自己直接承接相关项目，把产品在项目中应用起来，近一两年内菲奈特的产品才开始有些第三方采用，但仍不多。这些产品在业界的名声尚可，在终端客户的投标中很可能碰到，但在开发商选型时却几乎从不出现。
http://www.cnblogs.com/freeze44/
报表工具的考查指标与比较
国内市场上的报表工具大约有二三十种，比较活跃的也有十多种。面对这些绘乱杂陈的产品，很难仅从某一个方面就将它们都分类阐述清楚，更无法简单地分别打分评出优劣，必须分别从多个角度把各产品放在一起加以比较讨论才能对其在市场中所处地位有较深入清晰的认识。考虑到目前应用现状，我们主要讨论支持 B/S 应用的产品，具体范围主要集中在如下 16 种产品（这里是按字母次序、排名不分先后）：
actuate 、 bo 、 brio 、 cognos 、 crystalreport 、 jasperreport 、 mstr 、 stylereport 、博易智软、和勤、杰表、如意报表、润乾报表、数巨报表、用友华表、中创 inforreport 。
这些是市场上比较活跃的产品。其它产品或应用量太少或未采用商品化的运作模式，在程序员群体中上缺乏影响力，在讨论中不再重点陈述，只会在某些专题比对时提及。
1. 产品产地
从产地上可以简单地分作 国外产品 和 国内产品 两类，这个看起来似乎没什么意思，但其实这两类产品还是有较明显的差别，而且这样分类后在以下的讨论中也能比较方便地讲述。
从产品名称上很容易就区分出这两个类别（上述列表中全英文名的是国外的），这里就不再重复罗列了。
国外产品一般都价格较为昂贵（常被称作高端产品），而国内产品则普遍比较便宜，个别报价较贵的，也能被砍得很便宜；国外产品大多数都带有 BI 色彩，而国内产品则大多是纯报表产品；
当然，也有个别特例，比如国外产品 stylereport 的报表部分就比较便宜，比国内产品润乾报表的企业版便宜许多；而国内产品博易智软与和勤都有较强烈的 BI 色彩，国外产品 crystalreport （水晶报表）的 BI 色彩则不太浓（ BO 公司有更适合于主打 BI 的产品）。
另外，国外产品是从简单的西方报表模型抽象出来的，处理中国复杂报表的能力都较差，而且一般不会提供任何变通的手法，而国内产品中无论自创的还是抄国外的，大多数对复杂报表解决也不够好，但针对个别问题一般都会有些变通手法，因此对国内应用适应性更强一些；国外产品的历史大都很久，做工非常精细，除了模型算法不太适应国内需求外，常识性的细节都会搞得很好（如编辑器中的 UNDO 、统计图绘制的美观度等），而国内产品历史积累较短，个别厂商技术能力也较差，导致产品较粗糙和细节不完整。
2. 实现技术及原创程度
目前 J2EE 技术在国内的 B/S 应用开发中占主导地位，对 JAVA 的支持也是报表工具的一个重要考查指标。从这个意义上讲，报表工具可以分为 纯 JAVA 和 非纯 JAVA 两种 ，注意所有声称支持 B/S 应用的报表工具都能支持 JAVA ，所以不必再区别这一点。
相比之下，纯 JAVA 产品具有明显的优势。产品能够与 J2EE 应用完全无缝结合以达到最高的运行效率、安装部署很轻松简单（其机制与应用本身完全一致）；同时还可充分利用 J2EE 应用服务器强大的集群平衡负载及共享管理的能力，适合支持用户数众多的大型应用系统；由于 JAVA 的跨平台能力，还能让整个应用系统轻松地从低端体系向高端体系迁移，系统容量变大时只要更换硬件、操作系统及数据库等系统部件而无需或很少需要重写软件。
而非纯 JAVA 产品则相反，经常只能在 Windows 下运行（个别国外产品宣称支持 UNIX 但部署极为复杂，和不能用差不多）、同样的应用在不同规模下可能需要两套解决方案，或在大型应用中除了 UNIX 主服务器外还必须专门部署 Windows 作为报表服务器 , 显得体系结构非常古怪；产品也不能和 J2EE 的应用无缝结合、沟通需要沟通额外的网络协议导致运行效率较低，而且由于不能享受应用服务器的集群机制（国外产品常常有自己的集群机制但显然没有 J2EE 应用服务器搞得专业），难以支持多用户的大型应用。
国外产品中 stylereport 是纯 JAVA 的，而常见的 crystalreport （水晶报表） , bo, brio, cognos, mstr, actuate 都不是纯 JAVA 的，开源产品 jasperreport 也是纯 JAVA 的。国内产品中润乾报表、博易智软、和勤、杰表是纯 JAVA 的，而如意报表、数巨报表、中创 InforReport 、用友华表都不是纯 JAVA 的。
除了采用的技术外，其技术的原创程度也是个较重要的指标，它能够在某种程度上体现公司的研发能力以及产品的后续升级能力。手中不掌握原创技术的厂商无法对产品有完全的控制，其产品发展将严重受制于人，显然不适合与之长期合作。
所有国外产品都是原创技术的，国内产品中润乾报表、中创 InforReport 、用友华表都有原创技术，可以放心长期应用；和勤是引进的技术，但应已消化吃透，也基本没大问题；但如意报表和数巨报表则是采用了第三方控件，长期合作则可能有技术风险。
3. 绘制方案
从绘制方案上分一般有 网格式 和 控件拖拽式 两种，前者采用和 EXCEL 类似的方案，用网格线围出报表；而后者则是用矩形框等元素拼出报表。
国内报表对样式要求非常复杂而且严格，绘制方案是报表工具相当重要的指标，它决定了报表样式的复杂度和绘制效率，以及导出 EXCEL 的能力（这是用户很强调的功能）。
网格式在这方面有明显的优势，能够画出样式很复杂的报表，绘制效率也比控件拖拽式高出 10 倍以上，而且导出 EXCEL 时格式上不会失真，个别产品还可以直接读入 EXCEL 画好的表以进一步提高效率。相反，控件拖拽式则显得非常笨拙，表格线需要靠矩形边框重合摆放拼接出来，常见的复杂多层表头画起来非常繁琐，数据区某些纵向合并格甚至无法绘制出来，拼出的格线还与分辨率相关，屏幕上对齐的表在打印时或在 WEB 上显示时又可能不整齐，生成 EXCEL 时经常丧失格式或导致格线太多太细而无法应用，读入 EXCEL 格式则更是完全不可能有的功能。
国外产品中除 actuate 中提供的 spreadsheet 是采用网格式外，其它全部采用控件拖拽式（从另一侧面能反映国外产品对国内需求的不适应），开源产品 jasperreport 也采用控件拖拽式。国内产品中润乾报表、中创 InforReport 、杰表、用友华表、久其报表采用网格式，而博易智软、和勤、如意报表、数巨报表则采用控件拖拽式。
4. 数据统计模型
数据统计模型则是报表工具最重要的指标，它决定了报表工具的制表能力和效率，一般可分作 电子表格 和 传统工具 两类， 润乾报表 则不属于任何一类，是新一代报表模型。
电子表格类工具完全模拟 EXCEL ，没有真正意义的数据统计模型，数据须由程序员自行编程取出并运算后写入表格中，也就是没有任何自动化处理的能力，严格意义上讲电子表格类产品并不能称作报表工具，但有时也会混在一起讨论。用友华表是电子表格类产品的优秀代表作，几年前还有个国外的 formula1 比较流行，后来被 actuate 收购后改造成 spreadsheet 后拥有了数据处理能力。
传统工具目前还是报表市场上的主流，其基本特征是单数据源、条带式编辑与统计方案，在不编码的情况下只能完成简单地行式（分组）报表和单片交叉报表，稍有复杂的中国报表都需要另行编写代码准备数据，导致报表制作效率低下甚至不能完成，这一点可参见 " 新一代报表工具的标准 " ，其中较详细地阐述了传统工具处理中国复杂报表时遇到的困难。
除上述提到的电子表格类以及润乾报表和中创 InforReport 外，其它产品，无论控件式还是网格式，都采用同样的数据统计模型，都是传统工具，处理中国报表时都会有类似困难。
润乾报表采用了完全不同的数据统计模型，比较彻底地解决了中国复杂报表中的多源分片、不规则分组、动态格间运算和行列对称等困难问题（ " 新一代报表工具的标准 " 中有述），比传统工具的制表能力和效率有大幅度提高。
中创 InforReport 要另类一些，从表面上看起来也是采用了自己独特的数据统计模型，比某些其它传统工具处理复杂报表时有优势，但仔细深究，其实是传统工具是另一种变形，并没有从根本上解决了上述中国报表的困难。但考虑到其独特性，会专门再对此进行讨论。
5. 前端展现方案
在浏览器中展现一般有 HTML 和 控件 两种方案，某些产品两种方案都提供。有时还可以 EXCEL 和 PDF 的方式嵌入在浏览器中展现，但不是重点，这里不作讨论。
HTML 的优势是客户端完全无须安装程序，也不会有安全（病毒或泄密）问题，但由于 HTML 的先天不足，其交互操作和精确打印能力性要弱一些；控件则弥补了这方面的不足，但又需要下载从而带来安全问题（病毒等木马），而且只能支持 IE ，某些应用环境直接不允许安装任何控件。
HTML 方案还可再分为 纯标准 HTML 和 支持 IE 的 DHTML 两种，前者可以展现在任何浏览器上（ IE 和 Netscape ，这样客户端可以是 Linux ），后者则只能在 IE 上工作。
统计图的展示也是个需要关注的环节，一般可分为 纯 HTML 图片 和 控件 两种形式，有些工具虽然可以提供 HTML 的报表展现，但统计图部分却只能采用控件，这里需要特别关注的。 HTML 图片方式应用非常简单，但交互能力略差，控件则反之，交互能力强些但有下载等安全类问题。
另外，打印是个非常重要的展现环节，一般会有 HTML 打印 、 控件打印 、 JavaApplet 打印 和 生成 EXCEL/PDF 打印 几种方式。 HTML 打印不够精确，一般用于信息输出是可以，但很难用作正式格式的文件；控件和 JavaApplet 都能够实现精确打印，与控件相比， JavaApplet 从协议上没有安全问题，但又不能一次下载，若不大还可接受，否则也很不方便；生成 EXCEL/PDF 再打印能保证精确度，但要求客户端事先安装好相应程序，解决方案也不一致，有时也不是很方便。
所有的纯 JAVA 产品（无论国内国外的）都提供 HTML 报表展现、 HTML 图片的统计图方案和 JavaApplet 打印机制；国外产品中除 stylereport （纯 JAVA 的）都能提供 HTML 和控件两种形式展现和打印形式，但几乎全是仅支持 IE 的 DHTML ，某些产品（如 bo ）的统计图还只能以控件形式提供；国内产品中，如意报表、数据报表可提供仅支持 IE 的 DHTML 和控件两种，但 DHTML 实际上很少用，用友华表和中创 inforreport 只提供控件。
6. 后台集成方案
后台集成方案主要有 完全嵌入 、 独立服务器 和 控件数据服务 三种。
完全嵌入指报表运算服务不单独存在、而与用户应用程序结合成一体，主程序对报表服务的无缝调用，这样可以达到最高的运行效率和最深入的控制，同时可以享受应用系统的集群部署与数据连接共享能力以及不必专门处理权限门户的事务，是最经济高效的集成方案，但必须是报表工具与应用程序基于同种技术实现才可以做到。
独立服务器指报表运算在物理上独立存在（有时甚至会是一台专门的机器），用户应用程序通过网络协议调用报表服务，效率受到影响且控制力度不深，并且不能共享应用系统的集群和负载平衡能力，还迫使应用程序必须采用报表服务器的门户权限机制，导致多余的工作量。独立服务器的优点在于对宿主应用程序的技术体系没有要求，采用不同技术的应用可以同样的方案集成起来。
控件数据服务则专指以控件作为前端方案的产品在后台的集成方案，运算接口都在前端的控件中，需要把复杂的程序写到页面的 JavaScript 中；后台则几乎没有运算，只是将数据取出送给前端，程序简单可完全嵌入但并没什么接口，这种方式无法发挥后台服务器的强大计算能力，而且有关处理代码将在前端暴露出来造成安全隐患，不适合大型应用。
除了报表运算本身的集成外，还要考查有生成的统计图（及 EXCEL/PDF ）等二进制数据的引用方案，一般有 数据流服务 和 临时文件 两种。前者是将这类运算在后台组织成一个服务（在 J2EE 中是 servlet ），将结果以数据流（如 JPG 图像流）的形式返回给前端显示或下载，后台服务器上并不会真地产生一个文件；而后者则会将统计图（或 EXCEL/PDF ）物理地在后台服务器中产生成一个临时文件，浏览器上的图片或下载链接指向该文件，采用最传统的 http 机制完成图片显示和下载文件。
相比之下临时文件方案有明显的劣势，必须操作系统放开对硬盘某处的写权限（这在某些系统下可能导致是严重的安全问题），创建临时文件会占用硬盘空间而且降低访问速度，而且这些文件的命名（不得重名）及删除都需要较复杂的管理（有些产品只会创建而不会自动删除）。
纯 JAVA 的产品在 J2EE 机制下理论上都可提供出完全嵌入的方案，但 stylereport 、博易智软、和勤等产品仍以独立服务器方式提供，润乾报表和开源的 jasperreport 均提供完全嵌入的方案；而在非 J2EE 机制下，这些 JAVA 产品都只能以独立服务器方式存在。除 stylereport 外，其它国外产品在任何环境下都仅提供独立服务器方式。国内以控件为展现方式的产品均只有控件数据服务方式，如数巨报表、如意报表、用友华表。
纯 JAVA 产品均可提供数据流服务来引用二进制数据，而非 JAVA 的独立服务器产品（都是国外产品）大多采用古老的临时文件方案提供这项服务。
7. BI 色彩
事实上，有许多作为报表工具销售的产品其实是 OLAP 前端工具，并非纯正的报表工具。这些产品虽多少有些报表的功能，但处理得很不专业，处理复杂的中国报表固然差得很远，就算是简单的西方报表也在细节处理上大不如人意，其绘制方案、集成方案、展现方案等都很不适合国内报表的需求。但由于国内市场上 OLAP 的应用面尚比较狭小，这些产品凭借自己在 BI 领域的声望也来抢夺客户。
国外产品中 crystalreport 和 stylereport 是主要为报表服务的，其它产品如 bo 、 brio 、 cognos 、 mstr 、 actuate 则都是 BI 类产品。 actuate 的 spreadsheet 可算作报表工具， cognos 最近推出的 reportnet 也加强了报表的能力。国内产品中博易智软与和勤都是 BI 类的产品，其它如润乾报表、杰表、如意报表、数巨报表等都是纯正的报表工具。
8. 填报能力
填报是国内报表应用中非常关注的能力，有时甚至是必不可少的关键功能。但绝大多数报表工具完全没有填报的能力。所有国外产品、有 BI 色彩的产品、采用传统数据统计模型、控件式编辑的产品一律没有填报功能，生成的报表只能显示，不能填写。支持填报的产品非常少，常见的有润乾报表、用友华表、武汉新连线、久其报表几家，而用友华表由于没有数据模型，表格可以填写，但需要大量编程才能完成数据入库的工作；久其报表和武汉新连线的数据模型过于死板简单，只能填出固定的数据结构，对于复杂的入库要求依然需要编码完成。润乾报表的填报方案则相对完整，可参见 " 新一代填报方案的标准 " ，其中更详细地描述了填报产品应当具备的数据处理能力。
9. 价格与商业模式
大多数报表工具都是以收取 授权使用 费用形式销售的，即应用部署一次即收取一次费用。产品的价格大体可分成 高端 和 低端 两类。
高端产品一般会按服务器 CPU 或用户数 (name user ，不是并发用户 ) 计费，其价格很不透明，很难给出明确价位，一般在几万元至十几万元之间，以前还有高达几十万上百万的销售记录，但近期由于竞争的激烈已经比较少了，有时附加上 BI 功能后仍可能卖得很高；低端产品一般在几千元（ 3000-6000 ）左右，一般只按装机量计费。
所有国外产品和有 BI 色彩的产品都可以算是高端产品，国产的润乾报表（除普及版）也是高端产品；如意报表和数巨报表、杰表和润乾报表普及版则属于低端产品。有些产品的产品线较长，在询价时要确定地知道需要的版本和组件，否则差距可能非常大，如 crystalreport 的单机版只有几千元、而企业版（全面支持 WEB 功能）很可能要十几万甚至更多， stylereport 的报表部分只有两三万元、但加上部分 BI 能力了就会高达十几万元，润乾报表的普及版报价只有 3000 元、但企业版则要 25 万元， ... 。
还有的产品是以 开发工具 方式销售的，即用户一次购买后就可以无限重复使用，对于有较多次重复应用开发的开发商而言显然是最便宜的方式。活跃产品中目前只有用友华表采用这种商业模式，还有个国产报表 finereport 也采用这种方式，但很少有应用。
除了作为独立产品销售的，而在国内市场上还有一类报表产品是以项目服务形式提供的，比较著名的有广州菲奈特的 BI.Office 和久其报表，不知是产品化程度不够还是对这种商业模式偏号，这些产品一向很少由第三方开方商采用，而都是由自己直接承接相关项目，把产品在项目中应用起来，近一两年内菲奈特的产品才开始有些第三方采用，但仍不多。这些产品在业界的名声尚可，在终端客户的投标中很可能碰到，但在开发商选型时却几乎从不出现。