很多報表工具都把零編碼作為宣傳口號，這是真的嗎，真的能減少到零嗎，真有那么神嗎？

簡單情況下能做到零編碼

當數據來源，表格樣式和計算都比較簡單時，確實可以做到零編碼，比如只需要把數據 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

這樣的，通過一堆輔助格和公式去一步步算，雖然看起來還是沒有寫代碼，但捋清楚邏輯也挺費時間，復雜度甚至比寫代碼還高了

如果像潤乾報表那樣有自己獨有的計算引擎，使用內置腳本來處理這類多步、邏輯復雜的計算就簡單了很多

簡單幾句腳本直接把需要的結果集計算出來返回，報表模板只要的常規行式報表設計就可以了

這一下，就節省出了不少的工作量

零編碼的目的是減少工作量，降低復雜度，但如果復雜的計算只能一步步在輔助格里通過公式來算，弄出一大堆沒用的格子和公式來處理數據，這樣的零編碼反倒不如去編碼來的更快了，只有工具具備強力的數據處理能力，才能正真的做到少編碼、更接近零編碼

再來看一個前期數據準備復雜的

前面的兩個例子都是數據準備好以后，在格子中的計算比較復雜需要編碼的情況，實際應用中，數據準備的過程才是更復雜的場景，才是更需要大量編碼的地方，我們來看看報表工具有沒有能力在這個過程中實現零編碼

例子：報表中需要呈現連續上漲超過 5 天的gu piao及上漲天數

這樣的報表，制表時候只需要設計幾個格子，很簡單，但數據準備卻不簡單，大部分的工作量都得花在這個數據的準備上

用 SQL 來算的話，得寫 好幾層嵌套

select code,max(risenum)-1 maxRiseDays 
from (  
      select code,count(1) risenum 
      from(
           select code,changeSign,sum(changeSign) over(partition by code order by ddate) unRiseDays 
           from(
                select code,ddate,case when price>=lag(price) over(partition by code order by ddate)
                       then 0 else 1 end changeSign
                from stock_record
                )
            )
       group by code,unRiseDays
      )
group by code
having max(risenum) > 5

select code,max(risenum)-1 maxRiseDays 
from (  
      select code,count(1) risenum 
      from(
           select code,changeSign,sum(changeSign) over(partition by code order by ddate) unRiseDays 
           from(
                select code,ddate,case when price>=lag(price) over(partition by code order by ddate)
                       then 0 else 1 end changeSign
                from stock_record
                )
            )
       group by code,unRiseDays
      )
group by code
having max(risenum) > 5

這個 SQL, 無論如何要算成是編碼了，有多年經驗的程序員都不一定能駕馭。而且，這種編碼是省不掉的，只能想辦法簡化，追求少編碼了

我們繼續用 SPL 腳本去寫一下，看看能減少多少編碼

短短三行就可以搞定，而且邏輯更清晰易懂了

這個 SQL 還只是一個很簡單的計算例子，實際應用中的數據準備場景大都要比這個復雜，有些甚至要復雜百倍千倍，成百上千行的 SQL 和存儲過程也是總能見到的

這樣大的編碼量，大部分的報表工具別說是把它變成零編碼，就算是少一行都基本是無能為力的，能像上面的例子一樣用專業計算工具 SPL 把編碼量減少一部分就是最好的結果了

另外如果數據源不是關系數據庫，而是文本、NoSQL、JOSN 這些，那這個前期數據準備就更是去寫代碼了，報表工具號稱的零編碼就更是口號有余但力不足了

當然，用 SPL 這樣的計算工具去處理，去做準備，仍然有一定的編碼量，但還是能減少不少開發量，這時候我們就不是追求零編碼，而是追求少編碼了

通過上面 3 個例子可以看出，涉及格內復雜計算和復雜數據準備過程的報表，所有報表工具想通過簡單的零編碼方式來實現都是絕無可能的，都得工程師去費時間捋順其中的邏輯，然后去寫公式和代碼才能做出來的

不同之處在于，計算能力較強的工具，可以利用它的高效函數和算法，使得編碼量少而簡單，更接近零編碼，能力一般的，那就還是得費勁去硬編碼了

總結

報表工具的設計初衷，旨在減少手工設計報表的編碼量，能真正做到少編碼的就已經算作是好產品了，至于零編碼，那是少編碼的終極狀態，是各工具遠沒有達到的，也是需要去持續努力才能一步步接近的。