1 开源报表不好用，全凭自己编程序；商用报表又太贵，全给厂商打工了
很多软件都有开源的，报表工具也一样，但是开源报表都不好用，要么功能不全要么功能很差，需要自己编程去补足功能，而且操作复杂，开发效率低下商用报表工具大都比较贵，很多时候一个项目的利润都没有一套工具的价格高，每年有很多项目要做，每个项目节点也可能很多，这样一年下来就得买很多，工具成本就会压得人喘不过气，利润都贡献给报表厂商了，变成给报表厂商打工了。而且关键是，很多商用报表工具的功能也不健全，比如没有数据准备能力，复杂报表制作能力差等用润乾报表就没有这些顾虑了，价格低，一万一套，3 万一年随便用，相当于花 3 万元就有自己的报表研发部了润乾不仅便宜，还好用，润乾报表，专注报表二十年，功能全面，性能卓越，经历过无数项目验证，得到了无数用户信赖 2 报表做个没完没了，成本无底洞，回款遥遥无期
项目中的报表，前期评估的时候总觉得没多少工作量，但做着做着就会发现，报表总是没完没了，总是要改旧的，做新的，成本投入也没完没了，成了无底洞，回款也变的遥遥无期这是报表业务特征决定的，它就是会没完没了，但更重要的是因为工具不给力，才导致成本居高不下。如果工具给力，报表就算再多，也可以低成本应对了，就像全自动洗衣机，不管洗多少次、多少件衣服，都不需要投入过多的人工成本的目前大部分报表工具做简单报表都没问题，但复杂的，工作量就会大了，尤其是数据准备比较复杂的，比如各种需要用大段 SQL，存储过程，JAVA 来做数据准备的，这样的报表，如果工具没有对应的数据准备能力，只能硬编码来应对，成本当然控制不住如果用润乾报表，不仅报表制作工具化，连数据准备也工具化了（润乾报表基于流行计算工具–集算器 SPL 开发的脚本数据准备层），全面工具化，做表做得快，数据准备快，就可以大幅度提高效率，降低成本了，可以低成本应对，也就不怕报表多了，做的快，做的好，回款自然也就顺利了 3 报表呈现慢，抽个烟喝个茶才能等到，用户体验恶劣
展现慢，通常都是因为报表数据量大，计算复杂，报表引擎又不够强大，处理不好造成的，而这个问题，初期考察报表的时候很难发现，因为验证报表时使用的测试用例，基本都是比较简单的，数据量比较少的，验证不出报表工具的真实性能，到实际项目中，就会发现数据量大的，计算复杂的，响应时间会很长，甚至卡顿
润乾报表以性能好著称，复杂报表引擎能力强劲，而且还有独有的脚本计算层辅助，可以成倍的提升数据准备和计算的能力，这么多年，润乾见过了各类有性能问题的报表，都难不倒润乾，选你最慢的报表，用润乾报表试试吧 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 和关系数据库内数据的混算
| A |
|
|---|
| 1 | =json(file("/data/EO.json").read()) | JSON 数据 |
| 2 | =A1.conj(Orders) |
|
| 3 | =A2.select(Amount>1000 &&Amount<=3000 && like@c(Client,"s")) | 条件过滤 |
| 4 | =db.query@x("select ID,Name,Area from Client") | 数据库数据 |
| 5 | =join(A3:o,Client;A4:c,ID) | 关联计算 |
还没有评论，来说两句吧...