润乾报表一万一套，三万买断！

1. 开源报表不好用，全凭自己编程序；商用报表又太贵，全给厂商打工了

很多软件都有开源的，报表工具也一样，但是开源报表都不好用，要么功能不全要么功能很差，需要自己编程去补足功能，而且操作复杂，开发效率低下

商用报表工具大都比较贵，很多时候一个项目的利润都没有一套工具的价格高，每年有很多项目要做，每个项目节点也可能很多，这样一年下来就得买很多，工具成本就会压得人喘不过气，利润都贡献给报表厂商了，变成给报表厂商打工了。而且关键是，很多商用报表工具的功能也不健全，比如没有数据准备能力，复杂报表制作能力差等

用润乾报表就没有这些顾虑了，价格低，一万一套，3 万一年随便用，相当于花 3 万元就有自己的报表研发部了

润乾不仅便宜，还好用，润乾报表，专注报表二十年，功能全面，性能卓越，经历过无数项目验证，得到了无数用户信赖

2. 报表做个没完没了，成本无底洞，回款遥遥无期

项目中的报表，前期评估的时候总觉得没多少工作量，但做着做着就会发现，报表总是没完没了，总是要改旧的，做新的，成本投入也没完没了，成了无底洞，回款也变的遥遥无期

这是报表业务特征决定的，它就是会没完没了，但更重要的是因为工具不给力，才导致成本居高不下。如果工具给力，报表就算再多，也可以低成本应对了，就像全自动洗衣机，不管洗多少次、多少件衣服，都不需要投入过多的人工成本的

目前大部分报表工具做简单报表都没问题，但复杂的，工作量就会大了，尤其是数据准备比较复杂的，比如各种需要用大段 SQL，存储过程，JAVA 来做数据准备的，这样的报表，如果工具没有对应的数据准备能力，只能硬编码来应对，成本当然控制不住

如果用润乾报表，不仅报表制作工具化，连数据准备也工具化了（润乾报表基于流行计算工具–集算器 SPL 开发的脚本数据准备层），全面工具化，做表做得快，数据准备快，就可以大幅度提高效率，降低成本了，可以低成本应对，也就不怕报表多了，做的快，做的好，回款自然也就顺利了

3. 报表呈现慢，抽个烟喝个茶才能等到，用户体验恶劣

展现慢，通常都是因为报表数据量大，计算复杂，报表引擎又不够强大，处理不好造成的，而这个问题，初期考察报表的时候很难发现，因为验证报表时使用的测试用例，基本都是比较简单的，数据量比较少的，验证不出报表工具的真实性能，到实际项目中，就会发现数据量大的，计算复杂的，响应时间会很长，甚至卡顿

润乾报表以性能好著称，复杂报表引擎能力强劲，而且还有独有的脚本计算层辅助，可以成倍的提升数据准备和计算的能力，这么多年，润乾见过了各类有性能问题的报表，都难不倒润乾，选你最慢的报表，用润乾报表试试吧

性能案例参考：https://c.raqsoft.com.cn/article/1647044867607#toc_h2_1

4. 百万级大清单好久才出第一页，翻个页又半天，要不干脆就爆了

大清单报表就是数据量非常大的明细数据报表

很多行业都有大清单报表的需求，比如电信行业，需要呈现一段时间内的通话记录，金融行业，需要看某段时间的流水

这些报表，数据动辄百万千万条，这样庞大的数据体量，能否做到及时响应以及准确就很重要

普通报表工具通常用数据库的分页技术来解决这个难题，但数据库分页技术有很多弊端，比如页码大的时候，翻页会等待时间过长，每页的 SQL 是单独发送的，浏览期间数据如果发生变化，还会导致汇总错误，也无法实现数据分组，用起来就会有诸多不便

甚至有些工具干脆偷懒直接呈现了，没有用任何技术去处理，那结果当然是一浏览就卡死爆掉了

润乾报表没有这些问题，润乾的脚本计算层，把取数和呈现做成了两个异步线程，取数线程发出 SQL 后就不断取出数据后缓存到本地高效二进制存储中，呈现线程根据页数计算出行数到本地缓存中去获取数据显示，这样就不会卡顿和出错，而且脚本计算层可以针对任意数据源来做大清单报表，不会只拘泥在关系数据库中

所以润乾大清单报表能做到秒级呈现，翻页流畅，不会出错，可以分组，可以用在任意数据源上

5. 报表 SQL 几百行，开发调试太费劲，还没法移植；存储过程更是繁，又多了安全隐患

有些报表的数据，一句简单 SQL 就可以准备好，有些则需要成百上千行去算，写起来很复杂，多层嵌套，都得高级工程师费很大劲才能搞定，万一更换数据库，有些独特的写法又不通用，移植起来不方便

如果用存储过程会更繁，也会更烦，存储过程开发同样困难，需要高级工程师完成，移植的时候也更难，存储过程缺乏统一规范，各数据库厂商的语法基本不通用，更难移植，遇到数据库迁移，或者开发商面对不同用户的不同数据库时，就需要重新开发，成本徒增，而且编译存储过程需要较高的数据库权限，也有一定的安全隐患

润乾报表有独有的脚本数据集功能，支持过程式计算，分步实施计算简化实现代码，无需嵌套，开发难度要远低于复杂 SQL，过程中可以复用中间结果，性能也更高
脚本在库外独立运算，迁移数据库的时候只需要重新连上新的即可，不需要改动脚本的计算逻辑

脚本还提供了翻译 SQL 函数的功能，在更换数据库时，脚本会自动把 SQL 翻译成新数据库能识别的样子

脚本数据集连接数据库所需要的权限和普通的 SQL 连接是一样的，不需要更高的存储过程的编译权限，这就不会带来额外的安全问题，也不需要专人审核代码，安全又方便

6. 微服务时髦了，但报表太难做，只能 JAVA 对付，搞得应用强耦合，再也不能热切换

微服务现在比较流行，它的优势自不必多说，独立，灵活，安全，低耦合，易扩展…。但在微服务架构中，数据库完全被挡在后面，应用层只能通过既定的微服务访问数据，而不能再用 SQL 直接计算数据了，这对于严重依赖于 SQL 准备数据的报表（也在应用层）就麻烦了

没有 SQL，那就得用 JAVA 来为报表做数据准备和计算，用 JAVA, 不仅开发维护困难，成本高，而且还会

影响应用稳定性，原本报表文件和应用是低耦合状态，还能热切换，有什么变动修改一下报表文件直接替换就可以浏览到最新的，但用了 JAVA 后，就需要和应用一起重新编译，修改一个数据集都可能使得整个应用停摆等待，做不到热切换，也造成了高耦合，然而报表动改又是家常便饭。这其实也违背了微服务少依赖，低耦合的理念

用润乾报表的脚本计算层处理数据计算，则不会有这些问题，开发简单，新手稍加学习就可以开发，可以与 JAVA 应用（微服务框架）无缝集成，还提供了完备的计算能力，脚本实施计算的简便性远超 JAVA（甚至 SQL），同时脚本存储在报表文件中，还是保留了低耦合、热切换的特性，不会对应用稳定性造成影响

7. 数据来源 Oracle + MySQL + Restful + Mongo + Kafka + …，这报表怎么做？又得 Java 上

大数据时代，很多报表的数据来源都比较复杂, 经常要进行各类数据源的混算，比如一个报表的数据源，既有生产数据库，又有历史数仓中，还有 NOSQL，还有临时文件、JSON 等，这些要放到一起算，很多都用不了

润乾报表的脚本计算层，可以直接连接各类数据源，可以直接针对各类数据源进行直接计算，混算，比如下面这个小例：短短 5 行代码就可以做到 JSON 和关系数据库内数据的混算