很多报表工具都把零编码作为宣传口号，这是真的吗，真的能减少到零吗，真有那么神吗？
简单情况下能做到零编码
当数据来源，表格样式和计算都比较简单时，确实可以做到零编码，比如只需要把数据select出来后展现，这样的情况，大部分工具，都可以通过拖拽来完成报表，是真正的一个字符都不需要输入的零编码
上面这类简单的列表、分组、交叉报表，都是可以通过拖拽生成的，格子中的汇总统计等简单公式，也可以通过点选按钮来自动生成，是真正的零编码
等公式稍复杂一些，就不能自动生成了，就得手动输入一下了
比如上面例子里我们要加个订单金额的统计项，订单金额=单价 数量 （1-折扣），这个就只能手写了
虽然需要手写，但这样的公式非常简单，在工程师眼中不能算作编码，所以这样的报表也可以算零编码的报表
再看更复杂一些的，排名、同比环比，多源分片等，逻辑更复杂，写的也就更复杂了
到这里，我们仍然可以勉强把这些算作是零编码，毕竟公式再复杂也不会有程序代码复杂，这几行公式，比起不用工具手写报表的代码量，不知道要少了多少了
把上面的报表都能算作零编码的，我们会遗憾地发现，所谓的零编码能做的表大概也就到此为止了，数据计算再复杂一些的，就不能硬说是没有编码了，而实际应用中这类复杂的报表恰恰还是占比比较多的
复杂情况下只能追求少编码
报表的复杂情况主要体现在两个部分，1是表格内计算复杂，2是前期数据准备复杂，这两个方面，都需要一定的编码了，不同的报表工具因为能力的不同，编码量的多少也不同，能力强的编码就少一些，能力弱的，编码多一些
我们仍然是通过实际例子来看看各种复杂情况下报表工具的编码量情况
先看一个函数能力强弱的例子
表格内的复杂计算，有些情况下之所以复杂是因为产品的函数能力较弱导致的，比如要算5个10，有乘法函数的，直接5*10就可以，没有的，只能用加法算，10+10+10+10+10
我们通过成绩表，做一个如下的报表
我们主要看最下面一个格子的数据，要算出提升最快的三位同学
大部分工具都没有专门做这样计算的函数，都需要设置辅助格，先对名次变化幅度做个排名，然后再根据幅度排名获取前三位，比如下图中的H3格
这样原本B4一个格子的计算，就需要多弄一个辅助格才能完成，不仅写起来复杂，数据多的时候还会影响性能
如果有高级函数的工具，算起来就方便了，B4一个格子写个表达式就算完了，比如下面润乾报表中的SPL函数：+string(esproc(“?.m(?.ptop(-3))”,B3{},K3{}))
可见，同样的计算，报表工具中函数能力的不同，会导致零编码的程度截然不同。同样都号称零编码，但其零编码适应的范围，对于不同工具是完全不同的
再看看表格内多步计算的
有些表格内计算更复杂的情况，需要多步、分步计算，单一函数能力无法覆盖，那就得用更复杂的过程去算，但是这个过程也有很大差异，有的一步都少不了，有的可以三步并两步，写的少还算的快
上例子，我们从如下销售数据中取出指定时段的大客户
所谓大客户，定义为销售额占前一半的客户，也就是把客户销售额从大到小排序后，前面若干个客户的合计销售额构成总销售的一半，这些客户被称为大客户
报表结果：
可以看到数据和表样其实都很简单，但是制作的时候计算却不简单，需要分多步在报表中完成计算才可以，大部分的报表工具，都是先在报表格子中算出销售额总计、累计销售额，然后进行数据判断来确定哪些客户是大客户并对数据统计，最后再将这些用于中间过程计算，但却不需要显示的辅助行列隐藏掉，报表才算完成，比如下图中的B2和C3
这样的，通过一堆辅助格和公式去一步步算，虽然看起来还是没有写代码，但捋清楚逻辑也挺费时间，复杂度甚至比写代码还高了
如果像润乾报表那样有自己独有的计算引擎，使用内置脚本来处理这类多步、逻辑复杂的计算就简单了很多
简单几句脚本直接把需要的结果集计算出来返回，报表模板只要的常规行式报表设计就可以了
这一下，就节省出了不少的工作量
零编码的目的是减少工作量，降低复杂度，但如果复杂的计算只能一步步在辅助格里通过公式来算，弄出一大堆没用的格子和公式来处理数据，这样的零编码反倒不如去编码来的更快了，只有工具具备强力的数据处理能力，才能正真的做到少编码、更接近零编码
再来看一个前期数据准备复杂的
前面的两个例子都是数据准备好以后，在格子中的计算比较复杂需要编码的情况，实际应用中，数据准备的过程才是更复杂的场景，才是更需要大量编码的地方，我们来看看报表工具有没有能力在这个过程中实现零编码
例子：报表中需要呈现连续上涨超过 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这个SQL,无论如何要算成是编码了，有多年经验的程序员都不一定能驾驭。而且，这种编码是省不掉的，只能想办法简化，追求少编码了
我们继续用SPL脚本去写一下，看看能减少多少编码
| A | |
|---|---|
| 1 | =mysqlDB.query@x("select * from tbl") |
| 2 | =A1.sort(day).group(code).select(~.group@o(price>price[-1]).max(~.len())>3).(code) |
短短两行就可以搞定，而且逻辑更清晰易懂了
（注释：导入股市数据表，并按日期排序。使用函数 group 的选项 @o，根据股价是否上涨进行分组。分组时只和相邻的对比，当股价是否上涨发生变化时产生新组。计算出每支股票连续上涨的最大天数，最后选出连续上涨超过 3 天的）
这个SQL还只是一个很简单的计算例子，实际应用中的数据准备场景大都要比这个复杂，有些甚至要复杂百倍千倍，成百上千行的SQL和存储过程也是总能见到的
这样大的编码量，大部分的报表工具别说是把它变成零编码，就算是少一行都基本是无能为力的，能像上面的例子一样用专业计算工具SPL把编码量减少一部分就是最好的结果了
另外如果数据源不是关系数据库，而是文本、NoSQL、JOSN这些，那这个前期数据准备就更是去写代码了，报表工具号称的零编码就更是口号有余但力不足了
当然，用SPL这样的计算工具去处理，去做准备，仍然有一定的编码量，但还是能减少不少开发量，这时候我们就不是追求零编码，而是追求少编码了
通过上面3个例子可以看出，涉及格内复杂计算和复杂数据准备过程的报表，所有报表工具想通过简单的零编码方式来实现都是绝无可能的，都得工程师去费时间捋顺其中的逻辑，然后去写公式和代码才能做出来的
不同之处在于，计算能力较强的工具，可以利用它的高效函数和算法，使得编码量少而简单，更接近零编码，能力一般的，那就还是得费劲去硬编码了
总结
报表工具的设计初衷，旨在减少手工设计报表的编码量，能真正做到少编码的就已经算作是好产品了，至于零编码，那是少编码的终极状态，是各工具远没有达到的，也是需要去持续努力才能一步步接近的
