ITPub博客

热切换（Hot Swap）是指在系统不停机的情况下更换系统部件，在报表业务中则是指在不重启报表及相关应用的情况下完成对报表的维护（新增、修改、删除），冷切换则恰好相反。报表业务很不稳定，业务开展的过程中会刺激出更多查询统计需求，如果每次需求实现后都要等系统空闲（往往是非工作时间）时重启系统才能让修改后的报表生效，那将会对业务使用造成非常大影响（延迟）。因此在需求经常会变化的报表业务中，热切换显得尤

我们首先来理一下 DashBoard、大屏和报表的关系。DashBoard 是指企业仪表盘，也叫管理者驾驶舱，通常被简称为 DBD。从表现形式上来看，DBD 由多个决策者关注的各类指标数据拼接而成，每部分数据的表现形式不同，可以是图形、表格或文字，可以理解成每部分是一个报表；从技术本质上来看，DBD 是由多个 HTML 元素（布局）组成的页面，跟普通的页面是一样的，从这点来看 DBD 的本质和报表

啥是 SQL 注入风险？数据库要执行 SQL 访问数据，数据库是个执行机构，它只会检查传来的 SQL 是不是合乎语法，而并不会关心这个语句是否会造成伤害（数据泄露或破坏）。正因为只要符合语法规则就会执行的机制，导致 SQL 有了注入的风险。SQL 本身就是个字符串，而且一般没有加密，字符串可能被黑客劫持修改，这样就可能造成数据库执行了不该执行的动作。SQL 注入的惯用做法是通过把 SQL 子串插入

在 C/S 时代，报表是由应用程序显示的，可以直接操控打印机来实现打印。进入到 B/S 时代后，报表呈现变成浏览器的事情了，而浏览器中的 JS 编程不能直接控制打印机，只能依靠浏览器本身的打印能力。这种方式下的问题很多，比如不能精确分页，浏览器一般是根据用户设置的页面大小和 web 页面的内容多少来自行决定分页位置，程序员很难控制；再比如不能准确对齐边边距及打印文字，无法实现发票套打等功能。浏览器

在数据库中有一类用于保存中间计算结果的物理表，通常被称为“中间表”。中间表主要跟 OLAP（在线联机分析）业务有关，产生的原因主要有以下几方面。中间表来源1. 计算逻辑复杂在 OLAP（报表或查询）业务中，有些计算逻辑很复杂，每次都从头写会导致报表开发过于繁琐，而且有的计算用 SQL 很难写出来。这时会采用中间表事先计算好，再基于预计算的中间结果开发报表。计算逻辑复杂常见于报表业务中，以固定报表最

实际业务中有些报表比较“大”，查询出的报表数据行数可以达到几千万甚至上亿，这类行数很多的报表通常被成为“大报表”。大报表大部分情况下是清单明细报表，少量是分组报表。大报表查询通常不会采用一次性取出所有记录再交给前端呈现的方式，因为这样要等很久，用户体验极差；而且报表服务器内存也吃不消。常见的方式是通过分页来呈现大报表，一次只取一小部分数据，取数结束后立刻交给前端呈现，当页码变化时再取出相应页数的数

报表性能是总也避不开的话题，报表作为 OLAP（在线联机分析）中的主要应用场景，无论从涉及数据的宽度（表数量），还是数据的广度（查询范围）都可能非常巨大；而且在报表中还经常伴随非常复杂的数据处理逻辑，这些都会影响报表的运行速度。而服务器环境、数据库环境、JDBC 效率、网络环境、客户端环境这些也都都跟报表性能密切相关。报表性能可能跟很多因素有关，非常复杂。这里我们试着从报表运行的各个阶段来分析报表

在报表开发早期，报表连接的数据源基本只有关系数据库，而且经常只有一种或者只有一个数据库。但今天就不一样了，数据源种类繁多，除了 RDBMS 还有1.MongoDB、Cassandra、HBase、Redis 这些 NoSQL 数据库；2.TXT/CSV、Excel、JSON/XML 等文件；3.HDFS 等分布式文件系统；4.webService；5.ES、Kafka 等其他数据源形式……当这些都

我们在报表开发中经常会使用存储过程准备数据，存储过程支持分步计算，可以实现非常复杂的计算逻辑，为报表开发带来便利。所以，报表开发中这样的存储过程并不少见：3008 行，141KB 的存储过程，会给报表开发带来什么不好的影响？1. 编辑调试性存储过程难以编辑调试，这样几千行存储过程的开发周期往往要以周或月计，这样会严重影响报表的开发效率，而业务提的报表需求似乎都“很急”。2. 维护性相对开发的一次性

我们知道，报表开发主要有两个阶段。第一阶段：数据准备。将原始数据加工成报表需要的结果集（数据源）；第二阶段：数据呈现。根据已准备的结果集（数据源）编写表达式将数据以表格或图形方式呈现。这两个阶段虽然处于同一报表开发过程，但实现方式却大不相同。通常原始数据距离报表“能用”还相去甚远，通过 SQL/JAVA/ 存储过程等编码方式准备报表可用的数据源是第一阶段的目标，过程中可能涉及复杂的数据处理过程，因

最便宜的当然是开源和免费的工具，但因场景需求不同各有优势，在小型报表项目开发时，更多倾向于是开源报表，因为免费不涉及版权，在满足大部分报表需求的同时，不必拘泥于有限的内置功能。比如常用的 birt 报表就属于开源的，基于 OSGI 框架的报表引擎便于扩展和集成, 报表制作上也很简单，通过内置组件可以快速生成统计报表和统计图，也可以把报表导出成不同格式：excel、html、pdf 等，但不支持数据

目前，做手机报表的工具主要有两种类型：一种是提供移动端 APP 的，一种是 HTML5 解析方式的。提供通用移动端 APP的，这种无法定制出自己需要的效果，因为 APP 中报表数据展现，需要根据不同用户使用场景，提供不同的功能。其实即使是同一个功能，也要根据用户不同的使用场景选择不同的展示形式。外围部分还是只能由应用开发人员实现，所以，提供 APP 的产品不仅不便于集成，即使做了大量修改后也未必能

常规的不是太复杂的大屏，一般的报表工具中的 Dashboard 功能就可以实现。开发人员可以借助报表工具对布局进行设置，根据不同场景选用背景图，以及统计图形，加上合理配色，就可以做出一个下图这样可自适应屏幕的大屏展示效果。更为酷炫的复杂大屏，那就要在页面上下功夫，例如下面的这种效果，需要美工和工程师一起做了。这种大屏即使工具厂商不同，但实现方式也都基本一样，报表工具负责提供组件和框架，提供的组件如

市面上常规的 BI 工具都具备这样的功能，而且功能都大同小异，没有什么大的区分度。常规的自助报表工具应该有什么样的功能，可以参考这个总结。自助报表应有的功能(http://c.raqsoft.com.cn/article/1568095434513)然后在常规之外，也有一些比较重要的考察点需要重点去验证，比如下面的1. 是否支持排名、占比、环比、同比等指标计算；很多分析场景中，是需要有占比，排名的

国内报表工具更好用些，功能、易用性、延展性等方面都比国外报表工具要好。国外报表工具的优势主要体现在以下两点：商用产品用于 BI 时呈现效果比较好；开源产品免费。但弊端也很大，比如商用的价格都偏高；开源的对开发人员的技术要求很高、文档技术支持缺乏；不支持中国式报表开发等。国内报表工具的设计更加符合本土操作习惯，而且功能上更加齐全，例如：1、国内报表工具大部分采用网格式报表，更加贴合用户使用 exce

这个答案不是肯定的，而是需要根据不同的场景去看这个问题。如果系统中只需要图形化展现，或者图形下面带简单的明细，那么直接用 echarts 实现需求就可以了。如果绘制图表的数据来源比较复杂（通过写代码处理后传递给 echarts 使用也是可以的 ) 但是随着需求复杂度的提高，代码的复杂度和实现难度也越来越大，如果用报表工具来完成这个事情，就会简单很多。如果数据来源和图形要求都很简单，但是页面上要求展

报表工具关于开源还是商用的争论一直没有消停过，其实不管两者存在哪些差异，都应该不忘初心、按需选择。正因为需求不同，选择也不一样，所以在做出选择之前，要先搞清楚自己的需求是什么，然后再去做有针对性的对比，这样更有意义。关于两个有什么不同 简单列出如下几点：1、 开发模式不同国外开源报表工具编辑器大多是拖拽控件式的较国内商用报表工具类 excel 的编辑器 兼容性差，不易上手2、 国外开源报表工具很难

1：关系型数据库。比如常见的 mysql、oracle、sqlserver 等，这类数据库基本上都支持 jdbc 或者 odbc 链接，所以报表工具基本上都支持。2：文本文件常见的 txt、csv、excel 等文本文件，这类文本文件就看各类报表的支持情况了，有的不支持，有的需要通过 api 接口解析支持，做的好的工具能够直接读取文档文件做为报表的数据来源。3：程序数据源在 java 语言的报表工

在小型报表项目开发时，更多倾向于是开源报表，因为免费不涉及版权，在满足大部分报表需求的同时，不必拘泥于有限的内置功能。比如常用的 birt 报表就属于开源的，基于 OSGI 框架的报表引擎便于扩展和集成, 报表制作上也很简单，通过内置组件可以快速生成统计报表和统计图，也可以把报表导出成不同格式：excel、html、pdf 等。开源报表在以前市场上占有很大的优势，现在逐渐被商用报表所取代了，那么被

当前报表工具很多，可以按地域、开闭源等划分，包括有杰表、水晶、Style Report、birt、ireport、润乾、FR 等等，各家打印方式也各不相同，但总的来说，有 activex、applet、flash、pdf 等打印模式。对比来看：Activex 打印：主要是在 c/s 架构时代使用，当时发挥了极大作用的，处理得好且稳定，但随着 web 报表的普及，这种打印控件几乎没人采用了