很多報表工具都把零編碼作為宣傳口號，這是真的嗎，真的能減少到零嗎，真有那么神嗎？
簡單情況下能做到零編碼
當(dāng)數(shù)據(jù)來源，表格樣式和計算都比較簡單時，確實可以做到零編碼，比如只需要把數(shù)據(jù) select 出來后展現(xiàn)，這樣的情況，大部分工具，都可以通過拖拽來完成報表，是真正的一個字符都不需要輸入的零編碼
上面這類簡單的列表、分組、交叉報表，都是可以通過拖拽生成的，格子中的匯總統(tǒng)計等簡單公式，也可以通過點選按鈕來自動生成，是真正的零編碼等公式稍復(fù)雜一些，就不能自動生成了，就得手動輸入一下了比如上面例子里我們要加個訂單金額的統(tǒng)計項，訂單金額 = 單價 * 數(shù)量 *（1- 折扣），這個就只能手寫了
雖然需要手寫，但這樣的公式非常簡單，在工程師眼中不能算作編碼，所以這樣的報表也可以算零編碼的報表再看更復(fù)雜一些的，排名、同比環(huán)比，多源分片等，邏輯更復(fù)雜，寫的也就更復(fù)雜了
到這里，我們?nèi)匀豢梢悦銖姲堰@些算作是零編碼，畢竟公式再復(fù)雜也不會有程序代碼復(fù)雜，這幾行公式，比起不用工具手寫報表的代碼量，不知道要少了多少了把上面的報表都能算作零編碼的，我們會遺憾地發(fā)現(xiàn)，所謂的零編碼能做的表大概也就到此為止了，數(shù)據(jù)計算再復(fù)雜一些的，就不能硬說是沒有編碼了，而實際應(yīng)用中這類復(fù)雜的報表恰恰還是占比比較多的
復(fù)雜情況下只能追求少編碼
報表的復(fù)雜情況主要體現(xiàn)在兩個部分，1 是表格內(nèi)計算復(fù)雜，2 是前期數(shù)據(jù)準(zhǔn)備復(fù)雜，這兩個方面，都需要一定的編碼了，不同的報表工具因為能力的不同，編碼量的多少也不同，能力強的編碼就少一些，能力弱的，編碼多一些我們?nèi)匀皇峭ㄟ^實際例子來看看各種復(fù)雜情況下報表工具的編碼量情況先看一個函數(shù)能力強弱的例子
表格內(nèi)的復(fù)雜計算，有些情況下之所以復(fù)雜是因為產(chǎn)品的函數(shù)能力較弱導(dǎo)致的，比如要算 5 個 10，有乘法函數(shù)的，直接 5*10 就可以，沒有的，只能用加法算，10+10+10+10+10我們通過成績表，做一個如下的報表
我們主要看最下面一個格子的數(shù)據(jù)，要算出提升最快的三位同學(xué)大部分工具都沒有專門做這樣計算的函數(shù)，都需要設(shè)置輔助格，先對名次變化幅度做個排名，然后再根據(jù)幅度排名獲取前三位，比如下圖中的 H3 格這樣原本 B4 一個格子的計算，就需要多弄一個輔助格才能完成，不僅寫起來復(fù)雜，數(shù)據(jù)多的時候還會影響性能
如果有高級函數(shù)的工具，算起來就方便了，B4 一個格子寫個表達式就算完了，比如下面潤乾報表中的 SPL 函數(shù)：+string(esproc(“?.m(?.ptop(-3))”,B3{},K3{}))
可見，同樣的計算，報表工具中函數(shù)能力的不同，會導(dǎo)致零編碼的程度截然不同。同樣都號稱零編碼，但其零編碼適應(yīng)的范圍，對于不同工具是完全不同的再看看表格內(nèi)多步計算的
有些表格內(nèi)計算更復(fù)雜的情況，需要多步、分步計算，單一函數(shù)能力無法覆蓋，那就得用更復(fù)雜的過程去算，但是這個過程也有很大差異，有的一步都少不了，有的可以三步并兩步，寫的少還算的快上例子，我們從如下銷售數(shù)據(jù)中取出指定時段的大客戶
所謂大客戶，定義為銷售額占前一半的客戶，也就是把客戶銷售額從大到小排序后，前面若干個客戶的合計銷售額構(gòu)成總銷售的一半，這些客戶被稱為大客戶報表結(jié)果：
可以看到數(shù)據(jù)和表樣其實都很簡單，但是制作的時候計算卻不簡單，需要分多步在報表中完成計算才可以，大部分的報表工具，都是先在報表格子中算出銷售額總計、累計銷售額，然后進行數(shù)據(jù)判斷來確定哪些客戶是大客戶并對數(shù)據(jù)統(tǒng)計，最后再將這些用于中間過程計算，但卻不需要顯示的輔助行列隱藏掉，報表才算完成，比如下圖中的 B2 和 C3
這樣的，通過一堆輔助格和公式去一步步算，雖然看起來還是沒有寫代碼，但捋清楚邏輯也挺費時間，復(fù)雜度甚至比寫代碼還高了如果像潤乾報表那樣有自己獨有的計算引擎，使用內(nèi)置腳本來處理這類多步、邏輯復(fù)雜的計算就簡單了很多
簡單幾句腳本直接把需要的結(jié)果集計算出來返回，報表模板只要的常規(guī)行式報表設(shè)計就可以了
這一下，就節(jié)省出了不少的工作量零編碼的目的是減少工作量，降低復(fù)雜度，但如果復(fù)雜的計算只能一步步在輔助格里通過公式來算，弄出一大堆沒用的格子和公式來處理數(shù)據(jù)，這樣的零編碼反倒不如去編碼來的更快了，只有工具具備強力的數(shù)據(jù)處理能力，才能正真的做到少編碼、更接近零編碼再來看一個前期數(shù)據(jù)準(zhǔn)備復(fù)雜的
前面的兩個例子都是數(shù)據(jù)準(zhǔn)備好以后，在格子中的計算比較復(fù)雜需要編碼的情況，實際應(yīng)用中，數(shù)據(jù)準(zhǔn)備的過程才是更復(fù)雜的場景，才是更需要大量編碼的地方，我們來看看報表工具有沒有能力在這個過程中實現(xiàn)零編碼例子：報表中需要呈現(xiàn)連續(xù)上漲超過 3 天的股票這樣的報表，制表時候只需要設(shè)計幾個格子，很簡單，但數(shù)據(jù)準(zhǔn)備卻不簡單，大部分的工作量都得花在這個數(shù)據(jù)的準(zhǔn)備上用 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, 無論如何要算成是編碼了，有多年經(jīng)驗的程序員都不一定能駕馭。而且，這種編碼是省不掉的，只能想辦法簡化，追求少編碼了我們繼續(xù)用 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)
短短兩行就可以搞定，而且邏輯更清晰易懂了
（注釋：導(dǎo)入股市數(shù)據(jù)表，并按日期排序。使用函數(shù) group 的選項 @o，根據(jù)股價是否上漲進行分組。分組時只和相鄰的對比，當(dāng)股價是否上漲發(fā)生變化時產(chǎn)生新組。計算出每支股票連續(xù)上漲的最大天數(shù)，最后選出連續(xù)上漲超過 3 天的）這個 SQL 還只是一個很簡單的計算例子，實際應(yīng)用中的數(shù)據(jù)準(zhǔn)備場景大都要比這個復(fù)雜，有些甚至要復(fù)雜百倍千倍，成百上千行的 SQL 和存儲過程也是總能見到的這樣大的編碼量，大部分的報表工具別說是把它變成零編碼，就算是少一行都基本是無能為力的，能像上面的例子一樣用專業(yè)計算工具 SPL 把編碼量減少一部分就是最好的結(jié)果了另外如果數(shù)據(jù)源不是關(guān)系數(shù)據(jù)庫，而是文本、NoSQL、JOSN 這些，那這個前期數(shù)據(jù)準(zhǔn)備就更是去寫代碼了，報表工具號稱的零編碼就更是口號有余但力不足了當(dāng)然，用 SPL 這樣的計算工具去處理，去做準(zhǔn)備，仍然有一定的編碼量，但還是能減少不少開發(fā)量，這時候我們就不是追求零編碼，而是追求少編碼了通過上面 3 個例子可以看出，涉及格內(nèi)復(fù)雜計算和復(fù)雜數(shù)據(jù)準(zhǔn)備過程的報表，所有報表工具想通過簡單的零編碼方式來實現(xiàn)都是絕無可能的，都得工程師去費時間捋順其中的邏輯，然后去寫公式和代碼才能做出來的不同之處在于，計算能力較強的工具，可以利用它的高效函數(shù)和算法，使得編碼量少而簡單，更接近零編碼，能力一般的，那就還是得費勁去硬編碼了
總結(jié)
報表工具的設(shè)計初衷，旨在減少手工設(shè)計報表的編碼量，能真正做到少編碼的就已經(jīng)算作是好產(chǎn)品了，至于零編碼，那是少編碼的終極狀態(tài)，是各工具遠沒有達到的，也是需要去持續(xù)努力才能一步步接近的
