ITPub博客

如果以后可能换库，不管是从收费的换到开源的，还是从国外的换到国产的，对于报表开发的一个忠告：别用存储过程，少写复杂 SQL存储过程没有移植性，换库基本要重写；而各种数据库“方言”会导致语法不一致，同时支持的功能也不一样（如窗口函数的支持），复杂 SQL 会面临换库后巨大的改造成本。其实这个问题相当于问有没有跟数据库低耦合的报表开发方式。目前业界解耦报表应用和数据库的方式有两个：1、用 JAVA 实

如果报表通过报表工具开发，且报表中只涉及 SQL/ 存储过程，拆分相对容易些，只需要整理好报表模块需要的数据库资源即可，比如：会涉及到哪些数据源、数据库连接数需要分配多少等，然后将报表模块单独作为报表应用部署维护即可。如果报表中涉及 JAVA 编写的内容（通常是为报表准备数据）会比较麻烦。首先因为 JAVA 代码要跟主程序一起打包部署，所以报表模块和主应用是紧耦合在一起的，要解耦报表模块需要另一种

报表工具一般擅长处理规则一致的数据，若条件不一致的动态运算在报表中是很难实现的。常见做法是先写段程序把数据源准备好，然后传给BIRT再去画图，而不是在BIRT中去直接处理这种数据并画图。  比如要处理这么个场景：统计图X轴以时间为刻度，根据传入不同参数条件显示不同值。统计1小时，每5分钟一条，要生成12条，期望结果:  统计1天，每小时一条，要生成24条，期

这是 JAVA 编译型语言特性决定的，修改 JAVA 程序重启应用也正常。只不过改报表就要重启整个应用就有点夸张了，报表变动比较频繁，每次都重启应用会影响业务的。这个问题的根本原因是耦合性问题，报表里一旦涉及到 JAVA 代码就要跟主应用程序一起打包部署了，也就是耦合在一起，想要修改报表实时生效（热切换）也就不可能了，所以解决这个问题的思路是解耦报表和主应用程序。一般来说报表中使用 JAVA 编码

BIRT虽然提供了访问基于SOAP的Web Services，可以使用SOAP响应作为生成报表的数据。但总的来说，操作起来还是太麻烦了，灵活性也不够：1、配置过程步骤多，过于繁琐。2、引入的JAR很多，太重了。3、API接口多，代码写起来很长，调试不方便。4、只能接收简单结果，没有二次计算的能力。比如要处理这么个场景：根据传入参数，调用外部WebService，返回该地区的天气情况。URL：htt

由于BIRT不直接支持数组型参数参与查询，即:无法把一个数组直接传给DataSet执行带in的SQL，所以很难直接在数据集中把SQL拼出来。不过，可以通过一个间接的方式来实现：1、在DataSet中定义选出所有数据的SQL(select * from XX)，然后定义参数(如arg1，显示类型为List Box)，允许多值。2、在DataSet的Script页签下选择beforeOpen事件，并编

敏捷 BI 工具中包含的常规 BI 功能都差不多，更多需要考虑的功能是：关联处理、跨行组计算等，这些功能对产品的性能和处理能力要求很高，大部分产品对这方面的支持性都比较弱。大宽表是通用的处理方式，但是它灵活性很差，经常需要技术人员重新 JOIN 建模，所以要着重考察敏捷 BI 工具对于关联处理的机制是否有独特高效。润乾报表对关联计算的处理就很好，web 端的数据结构呈现成树状，业务人员对关联关系一

如果只是需要常规的 BI 功能，比如拖拽、钻取、切片、旋转、汇总等，那基本所有的 BI 工具都可以，因为这是基础功能，谁都满足，找一个便宜、稳定的就可以。但是大部分 BI 的需求其实是需要考虑集成和定制的事情的。因为 BI 一般只是作为已有项目的一个功能插件，这就要求选择的 BI 工具能够支持单独被集成；不同用户对于 BI 的实际效果要求不同，那么就需要允许定制，如果定制的工作交给 BI 厂商就会

BI 主要侧重于数据分析，虽然可以进行数据钻取、联动、切片、旋转等操作，但是展现的结果通常为网格、分组、交叉这几类简单格式的报表；而报表主要侧重于数据展现，可以支持复杂格式的表格数据呈现，且支持数据填报，把页面数据更新入库。如果项目里边有格式较为复杂的报表，一般来说还是需要由专业的报表工具来实现的。实际项目中用的比较多的是 “BI+ 报表”这种方式，业务人员的分析功能用 BI 来做，报表用来做复杂

这类报表相对简单且规整，按照几个维度进行汇总，基于查询的数据进行切片、钻取等。多维分析的本质就是基于一个数据集进行过滤和分组汇总，写成 SQL 大概是这样：select sum(x1),count(x2),… from DS group by dim1,dim2,…，如果做切片和切块就再加上 where 条件，而多表 JOIN 常常需要事先准备数据集（有些产品允许用户先做关联运算生成数据集再做多维

如果自己实现这种领导驾驶舱，需要将驾驶舱页面拆分成多个部分，通过 iframe 组合到一起，在实现组件的交互效果，会涉及到较多的前端技术。现在一般的报表工具其实就提供了 DBD 功能，可以使用报表工具厂商提供的 DBD 功能，可以方便布局，并且整个面板支持自适应，面板中的组件也支持自适应，支持一个面板的多个组件的联动效果，具体实现可以参考 大屏联动竟如此简单？？？ 。还能实现组

为什么？广义上的 BI 是包括数据仓库、多维分析、报表和可视化技术的一整套解决方案，而我们常说的 BI 则专指多维分析，也就是自助查询。建设 BI 往往是希望将简单、临时、多变的查询需求开放给业务人员自助完成，从而提高用户需求的响应速度，减轻 IT 技术部门的负担。这里面简单查询是个关键，多维分析的本质是基于一个数据集进行过滤和分组汇总，写成 SQL 大概是这样：select sum(x1),co

关于Json处理的开源包有很多，比如json-lib、jackson、Gson、Fastjson。Gson是谷歌做的，功能强大；Fastjson是阿里巴巴做的，性能较快。具体用哪个，你开心就好。Json解析出来一般都是为了再次计算，常见的这些开源包大多都对Json的读取与解析提供了丰富的接口，但是接下来如何把多层Json数据经过筛选、进行深入计算并展开成二维数据，供给其它服务使用，仍然需要复杂硬编

分库以后，存储过程直接就被判死刑了，铁定不能再用了；SQL 还要看情况（如多表 JOIN），总体来说方向有三个：一、使用数据库中间件使用像 Mycat 之类的数据库中间件，报表里的简单 SQL 基本都能延续使用（像 Mycat 支持 SQL92 标准），但对复杂 SQL（嵌套查询和多表 JOIN）就比较麻烦，要考虑全局表等设置。而报表业务里复杂查询会很多，有些还伴随过程和逻辑判断，这时用数据库中间

打印量这么大的报表，打印机可能会吃不消。可以算算打印 100 万行记录是什么情况。假设一页纸能打印 50 行记录（这已经算多了），100 万行记录就意味着 2 万页纸。2 万页的连续打印，有多少打印机能做到这个指标？你的用户真有这样的设备吗？2 万页纸大概有 2 米厚，什么打印机能把这些纸放进去？商用快速打印机一分钟也就 30 几页，就按 50 页 / 分钟算，2 万页也需要 7 个钟头！作为一个

导出报表内存溢出很可能是因为数据全内存导致的，得采用流式（分批）导出的方式。如果报表是自己写代码开发的，可以借助诸如 POI 等开源包实现流式导出，代码有点长，供参考：https://blog.csdn.net/gw5205566/article/details/100044236如果使用报表工具开发的报表，就要看看工具本身支不支持了，有的报表工具可以支持报表异步分页呈现、报表流式（分批）导出 E

现在大多报表工具都提供这样的功能，不需要 JS 方法，只需要简单设置就可以实现效果，而且提示的信息也可以是动态计算的，在动态扩展的格子中，格子中的数据不同，显示的提示信息也不同，具体实现可以参考看下这篇文章的介 鼠标悬停出现提示信息怎么做 。

BIRT对于两个数据源的联合提供了Joint DataSet的解决方案，它具有图形化的操作界面，可以完成简单的内外关联，但功能非常局限（几乎没有二次计算的能力，Join 后再计算只限于简单查询和固定查询，难以实现自由的组合查询和变量查询，更不能进行分组汇总再过滤这类多步骤计算）。BIRT虽然支持CSV/TXT等文件作为数据源，但不能构建JSON数据源，一些开源社区提供了解析JSON数据源插件，几乎

把表中某字段根据分隔符拆分成N个字符串后，再用这N个字符串把这一行演变成N行。用SQL来解决这个问题非常烦琐！SQL里没有提供集合对象，不能提供根据拆分后的字符串集合把一行变成多行的操作。解决这个问题的思路就是先求出字段拆分后的最大字符串个数M，然后构造一个M行1列的临时表T2，其列名为lv，则各行lv值分别为1,2,……,M，然后用原表与之叉乘，叉乘时取字段拆分后的第T2.lv个字符串。这样写出

数据分组以后，要找出在每个分组中都出现的某个字段值。用SQL来解决这个问题并不容易！SQL缺少单纯的分组操作，只能返回各分组的统计值，而不能对各组的成员再进行更细的交、差、并等集合运算。要解决这种问题就需要多层嵌套子查询来变相地实现。举个例子：查询每周都加班的员工以进行表彰。现有加班数据表OVERTIME_WORK数据如下：WORKDATENAME2019-07-01Tom2019-07-02Jo