报表工具的架构，原本设计的很巧妙，稳定的服务和应用无缝集成到一起，由应用统一管理，随需而动的报表模板，独立在数据库和应用之外，互不干扰，不管是新增还是修改报表，只需要动模板和里面的 SQL 就可以，不需要动数据库也不需要动应用

报表理想的架构：

但随着大数据时代的到来，这巧妙的架构被打破了，数据变多了，计算变复杂了，原本在报表模板中就可以做好的数据准备和计算，现在搞不定了，只能通过外部手段辅助完成，这一辅助，就和数据库或者应用耦合了，架构就被破坏了

报表怎么造成耦合

数据库耦合

原本报表的数据都是在模板的数据集中处理，一段 SQL 就可以把数据准备好，给到报表呈现，但计算复杂后，单凭 SQL 就搞不定了，就得用存储过程、中间表等手段来辅助计算，准备好以后，再给报表用

存储过程和中间表，都得存在数据库中，就和数据库产生了耦合

应用耦合

有些时候更复杂的计算或者是非关系型数据来源的多源混算还得用 JAVA 来做，JAVA 代码需要和应用放到一起编译，就会和应用产生耦合

被破坏后的架构：

耦合的危害

耦合不可怕，可怕的是耦合带来的危害

数据库耦合的危害

有安全隐患

报表开发人员，原本只需要写 SQL，做报表就可以，但用到存储过程和中间表，就需要动数据库，就得赋予相应权限，比如存储过程需要编译权限，这个权限就太高了，改数删表都有可能，安全性得不到保障，要么就得数据库管理员花时间去审核，不仅效率低，成本还高

影响数据库容量

存储过程和中间表，都会有一个问题，就是随着业务的增多时间的拉长，会变的越来越多，但它们又不好管理，不能随意删除，因为系统过了这么多年，人员换了一波又一波，很多早已分不清楚谁是谁的，哪个在用哪个停用了，删除很有可能就影响了系统，带来更大的问题，所以只能放任其野蛮生长

这就会占用大量的数据库空间，尤其是中间表，量大了以后，数据库就得被迫扩容，不管是横向还是纵向扩容，成本都很高

影响数据库性能

每个存储过程和中间表都会进行计算，甚至有些已经弃用的还在定期做着运算，量大的时候，这些非关键性的计算就会抢占数据库关键业务的计算资源，带来性能问题，影响数据库的关键业务，这问题就严重了

人员成本高

现在的主流的报表工具都好用又简单，初级人员就可以轻松完成报表，但有了存储过程，中间表，那就得高级一些的工程师参与了，而且还有可能麻烦 DBA，人员成本就会变高

应用耦合的危害

影响应用稳定

为报表做数据准备的 JAVA 代码需要和应用一起编译，数据一有改动，就得改代码，就得重新编译，应用就得停机重启，严重的影响了业务的稳定性，这是很致命的

人员成本高

同样，写 JAVA, 就得 JAVA 人员，成本会更高

怎么解耦

从耦合造成的原因我们可以看出，所有的耦合，其实都是为了弥补报表工具本身准备数据的能力不足而造成的

如果报表准备数据的能力强一些，就可以不用这些会带来耦合问题的方式协助了

润乾报表集成 SPL 集算器以后，就有了这样的能力

润乾报表新架构：

SPL 是一款流行的专业的数据计算处理工具，很多项目开发商都在用，因为它不仅能解决问题，而且还免费，开源，是常年做项目，总需要做数据处理的工程师的好帮手

集成 SPL 后，润乾报表相当于多了一个数据准备计算层，这个计算层计算能力很强，可以替代存储过程、中件表、JAVA 来做数据准备和计算，让报表的架构又重新回到了那个巧妙理想的状态

SPL 算法强大

SPL 有很多高效的函数和算法，可以轻松写出 SQL 难写的，需要存储过程或者中间表来做的分步计算，复杂计算

比如这个小例：报表中需要呈现连续上涨超过 3 天的股票

这样的报表，制表时候只需要设计几个格子，很简单，但数据准备却不简单，大部分的工作量都得花在这个数据的准备上

用 SQL 来算的话，得写好几层嵌套

SELECT code, MAX(ContinuousDays)
    FROM (
        SELECT code, NoRisingDays, COUNT(*) ContinuousDays
        FROM (
            SELECT code,
            SUM(RisingFlag) OVER (PARTITION BY code ORDER BY day) NoRisingDays
            FROM (
                SELECT code, day,
                CASE WHEN price>
                    LAG(price) OVER (PARTITION BY code ORDER BY day)
                THEN 0 ELSE 1 END RisingFlag
                FROM tbl
            )
        ) GROUP BY NoRisingDays
    )
    GROUP BY code
    HAVING MAX(ContinuousDays)>=3

而用润乾计算层的 SPL，则短短两行就可以搞定，而且逻辑也更清晰易懂

（注释：导入股市数据表，并按日期排序。使用函数 group 的选项 @o，根据股价是否上涨进行分组。分组时只和相邻的对比，当股价是否上涨发生变化时产生新组。计算出每支股票连续上涨的最大天数，最后选出连续上涨超过 3 天的）

这里因为篇幅原因，就只能举这样的小例子来看了，这个小例子，虽然没有用到存储过程和中间表，但已经很难写出了，再长一些，复杂一些的，就得用存储过程和中间表了

而 SPL 不管长短，都可以把难写难算的变的简单，就不再需要存储过程和中间表了，当然也不需要 JAVA 去写了

SPL 支持多样性数据源

SPL 支持各类数据源，可以直接对接计算

轻松几行代码就可以完成跨库混算，之前不得不用 JAVA 来做的工作，也可以放弃 JAVA 了

SPL 简单不耦合

SPL 不仅可以代替存储过程、中间表和 JAVA，而且写起来更简单（可以看上面的 SPL 脚本），简单就可以由初级人员来做，就可以节省成本

SPL 的脚本是写在报表模板里的，和模板一起存在文件系统中，自然也就不和数据库以及应用发生耦合，有什么变动，直接改模板和里面的脚本就可以，轻松热切换，不需要动数据库，更不需要重启应用

一个 SPL 就轻松把之前的耦合问题全解决了，而且还更高效简单

总结

耦合，是因为要辅助报表做数据准备造成的，但因为没有更好的方案和更新的技术出现，人们也只能忍受着它的弊端，毕竟腿再疼也还是能走路的，锯掉了，就走不了了

庆幸的是，技术总在进步，有了润乾报表的 SPL 计算层这样的新技术，腿疼的毛病不仅根治了，还走的更快了

而且这新技术不仅不需要额外花更多的成本，还能省一笔，因为润乾报表1W 一套，3W 一年随便用，一套工具，既能做报表，还能解决耦合难题，比起其他的，那不就省下很多了