原文地址：http://c.raqsoft.com.cn/article/1571024764129?r=CGQ
原地址可以下載更清晰的pdf版
報表選型中那些想不到的
坑
傳統的選型是什麼樣的？
找廠商應答
自己根據項目需求想一個或者找一個
自己去驗證
需求列表
這麼選的結果如何？
你信了他的邪，你就掉進了
Keng
坑
你信了列表，你也掉進了
自己跟着列表測
廠家說：我們都滿足！！！！！
什麼原因造成了這樣的結果？
列表太過寬泛，不夠專業， 沒有抓住驗證的重點
廠家一看，確實寫得我都滿足
自己一測，寫的也基本都滿足
用進項目中，很多沒想到
得知道坑在哪裏才能不掉坑
找到那些坑 實際去驗證看它到底行不行？？？
怎麼樣能不掉進坑？
報表選型中都有哪些坑？
喬布斯說：到處都是坑！！
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
開發工具
★是否提供獨立安裝的本地報表設計器 1
★佈局方式是Excel式的還是控件式的 2
★能否直接將excel轉換成報表模板
3
……. 4
5
6
7
要桌面設計器還是web設計器？
Web設計器：看着高大上，其實是雞肋 行走江湖這麼多年，沒有幾個真正用web設計器
設計報表的，影響 web應用穩定性，開發效率低。這個需求不提也罷
桌面設計器：必須 開發效率高，不會因爲設計階段的問題影響web應用。本質上報表
工具是給程序員用的，您見過哪個成熟的開發工具是WEB的？
桌面設計器穩定、功能全面、開發快捷
web設計器功能不全，受網絡、服務器影響開發效率低
這個其實問一下工程師的感受就知道了，基本沒有工程師願意選擇web端製表
佈局方式是Excel式的還是控件式的？
Excel式的更直觀，易上手，易操作
國產貨大都都是Excel風格的，都滿足，不用考察
其他方式的，控件式 條帶拖拽式等，都不易擺放，不易對齊，設計不便
國外產品和開源產品很多都這樣，可以批量放棄
控件式設計器，是不是看着就很陌生，無從下手
完全和我們平時看到的表格不一樣，增加學習成本不說，即使學會了也不好設計
需要集成到eclipse中的，更費勁
各種依賴包，驅動，漢化，就得折騰一天
問自己一下：工程師一人天多少錢，每個工程師各浪費1人天，多少錢？是在省錢還是燒錢
能否直接將Excel轉換成報表模板？
顯然這樣會很方便，業務報表經常已經有Excel的表樣，直接讀入省得再畫。
也是國內的基本都滿足，不用考察
國外的有些就不行，得完全手工重新畫，工作量多出了很多
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
數據源
★非關係數據源是如何訪問的？ 2
★txt，xls，xlsx，csv文件做爲數據源支持情況 3
★報表可否同時從多數據源中取數
4
★特別要注意：SQL植入的安全問題 5
6
7
★對關係數據庫的支持該怎麼驗證？ 1
關係數據庫的支持該怎麼驗證
Oracle、DB2、SQL Server、MYSQL、INFORMIX
達夢 金倉 Gbase
。。。。。。。。。。。。。。等等 一大堆我都支持
是不是寫得越多越牛？
其實這項不用考察，只要是關係數據庫，寫上的沒寫上的統統都會支持，因爲這是世
界標準，列更多並不更值錢！
可訪問的非關係數據源種類
1）不能簡單相信“支持xx等”的說法，咱們需要
什麼，必須自己想清楚，然後去驗證
2）所謂的支持，是直接做好讀取功能，還是隻給
個二次開發的接口 ，這二者是完全不同的
文本數據源都會有，但是大數據量的呢？
txt，xls，xlsx，csv文件做爲數據源，大部分國產的都允許，有些開源和免費的不行
BUT
你的讀取方式是啥的，是流式讀取的嗎？如果不是，那大數據量肯定卡死，怎麼解決
多數據源取數又如何
也是都號稱支持
實際要看看自己都有哪些種類的數據源
文本
Webservice
hive
來自這些地方的數據能否同時在一個報表中關聯，實際測一下就能刷掉一批
SQL植入的安全問題
參數查詢 SQL相對固定，基本無風險
通用查詢 語句替換，非常靈活，但是卻可能泄露數據庫信息喲！
該怎麼防範？那就去問問報表廠商唄。
什麼？沒搞懂是啥意思，猛戳這裏：報表的 SQL 植入風險及規避方法 - 乾學院
或者搜索 乾學院 再搜索文章標題
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
★分組交叉列表報表 1
★動態格間運算，支持跨行跨組的運算，支持獨立
格的運算
2
★多級的分組與交叉報表，不規則分組，例如按段
分組、條件分組
3
★排名、同比、比上期、環比等設置 4
★表頭橫向縱向雙向鎖定 5
6
7
報表模型
報表模型
分組交叉列表報表的驗證
什麼？？？？這麼簡單的功能也是坑？？？？
對，是
坑是啥，是不要被列表誤導去驗證這些大家都支持的，在簡單報表身上都不用浪費時間，
都支持！！！！！
中國式複雜報表的驗證
來
我們挨個看看 哪裏複雜
複雜表樣
多片區整合、多表關聯、複雜報表、條件彙總
複雜計算---特殊分組
不完全劃分
（例如類別爲：其他）
單片說明：
複雜計算---跨行組計算
排名
同期比
無規律跨格計算
·····
特殊分頁需求
每頁固定行數
分頁彙總
補足空行
特殊分欄需求
按紙分頁、橫向分欄、數據明細
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
呈現輸出
★圖形種類是否全 1
★集成第三方統計圖組件，如echarts，D3等，並
可以導出打印
2
★三種打印方式：applet、flash、pdf
3
★將報表結果、文本、圖片等插入word模板中 4
★大屏 DashBaord 5
★移動端該如何支持？ 6
7
統計圖種類該怎麼考察？
不用考查
很多人喜歡把這個列一大堆，純屬多餘。常見圖形對任何成熟報表工具全都支持
而且還有很多開源圖形包，要啥有啥；太特殊的真沒有，也是到處都沒有，只能自己做
是否支持種類更全第三方的統計圖，才應該是考察重點
Echarts等第三方統計圖的集成
爲什麼必須有？因爲人家 漂亮 全面 簡單，而且還 不要錢！！
有兩個要點要驗證：
1）是否內置支持，而不是開放接口
2）是否可以導出打印，圖表不是光看就可以的，而這常常是開源包本身不提供的咯
坑的解讀
★支持集成第三方統計圖組件，如
echarts，D3等
工具中集成第三方圖，可直接使用，不
需要通過二次開發方式引入
★echarts統計圖也支持打印導出
前端動態的echarts圖做爲報表的一部
分打印或者導出成文件，不需要二次開
發操作
幾種打印方式
APPLET打印 PDF打印 FLASH打印
word報告式報表有集中實現方式
只能在設計器中硬排版是不夠的！！！！！！！
需要支持把報表實時插入到已有word中才可以，更方便
不要問我能不能做大屏
很多人覺得做大屏是報表工具的重要功能，其實呢：
大屏Dashboard主要是圖，這是圖形包以及程序員+美工的本事
程序員管數據、美工管樣式、圖形包負責呈現
其實沒報表工具多少事！用不用工具，工作量都一樣！
報表工具無非就是把圖形包封裝一下，省那麼一點點從數據庫取數的工作
坑的解讀
簡單的大屏
報表工具就是起個頁面框架作用，
費功夫的內容還是這些圖表
坑的解讀
牛B的大屏
是美工精心設計再加工程師努力
實現的，工作量少不了。
報表工具仍然只是個框架
移動端應該怎麼測評？
一個對所有用戶都是一樣的固定的移動端app，能直接拿來用嗎？？？
答案顯然是：用不了！每個應用都需要自己的APP，報表工具直接提供APP毫無意義！這
一項完全不用考察
那應當提供啥？
支持H5的輸出，並且有demo讓用戶可以參考功能開發
目的是讓應用程序員能方便地做出一個自己的APP，或者把報表功能嵌入到已有APP中！
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
自助報表的坑
★自助報表不是萬能的！！！ 1
★支持排名、佔比、環比、同比等指標計算 2
★是否可以一次建模滿足多種跨表關聯查詢
3
★是否可被集成，是否提供源碼供客戶改造 4
5
6
7
自助報表不是萬能的，上一套BI就啥也搞定了？
絕對不可能！！！！
目前市面上的BI，多維分析，自助報表，都做不了複雜的報表
比如上面提到的中國式複雜報表，就必須得用固定報表工具來做
排名、佔比、環比、同比能直接做嗎
很簡單
實際驗證下就可以
是否可以一次建模滿足多種跨表關聯查詢
一次性建模，有新的關聯查詢需求時並不需要更新模型，
只有數據庫中表及字段以及關聯發生了改變纔要再次改造模型
用下一頁的驗證示例，能卡掉一大半廠商哈，一般人我不告訴他
驗證例子
老闆說：明天我想針對每個銷售，把上半年的訂單情況做一個分析
工程師想：分析銷售訂單情況，需要 訂單表、訂單明細表、僱員表，於是做了cube，把
三個表做了關聯
第二天：老闆忽然又想針對省份，和客戶做一下分析
工程師蒙了。因爲他的CUBE裏沒有加地區表和客戶表，老闆也太坑了，又得重新改模型
了
不是老闆坑，而是工具不給力，能被這一條卡到重新建模的工具都不是好工具
大寬表是解決方案嗎？
有人會問：那我一次性把能想到的表和列都加到一個大 表裏
不就行了嗎
大寬表確實是大家常用來對付這件事的手段，也有一定效果
但是：壞處是空間太大，性能差
而且還是有搞不定的情況，比如自關聯
能把數據結構以層次形式呈現並自動生成JOIN纔是解決方案
是否需要集成和改造，要想好！！！
想一想，是否需要把自助報表功能嵌入到自己的頁面中？
想！那就要考查自助報表是不是可集成，能不能被改造了
很不幸，大部分廠商提供的產品都無法被集成，也不允許用戶自己改造
因爲自助報表功能需要元數據支持，是在一個完整應用系統內的東西，很難將這一個功能
集成到別的應用中了
不能被集成，又不給源碼，那就只能祈禱廠商給定製了，阿門。。。
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
集成部署
★支持與javaweb程序無縫集成
1
★報表支持熱加載 2
★對集羣的支持
3
★安全問題 4
5
6
7
能與javaweb程序無縫集成
無縫嵌入式集成
方便項目管理，報表作爲整個系統的一部分，
統一使用用戶系統的權限，流程等
大部分java項目，都願意報表工具可以無縫集
成
不能無縫集成呢？
那就只能獨立部署，然後調用了
當然獨立部署也有一定的好處，可以把報表和
應用分離，互不干擾
但更多的是不便之處
要管理兩個應用 兩個服務器
要考慮調用的安全性，或者單點登錄
報表支持熱加載
大部分廠商都可以做到報表熱加載了
如果做不到，那就會有大問題，誰的生產機也不可能會讓頻繁重啓
但是如果報表中用到了程序數據源，這個就多半做不到熱加載了
現在有一些廠商有數據中間層，數據中臺的產品，可以做到熱加載，這個是加分項，20%
困難的報表基本都會用到程序數據源
程序數據源的熱加載
怎麼才叫支持集羣
應用都可以部署到集羣上的 但這只是初始階段
真地要支持集羣，得有集羣緩存同步的本事纔行
訪問A節點計算完的報表，再通過B節點查看就不用再算了，緩存已經同步，直接用就可
以了
如果沒有緩存同步，那跳轉了節點就得重新算，性能會損失很多；這個所謂的集羣就不是
個整體，只是一堆獨立機器的集合而已
安全問題很重要，但卻不用考查
報表作爲中間件產品，總是要嵌入到用戶的系統中的
大部分安全問題，就該由主應用系統來負責了，報表工具不用管也管不了
不過前面說過的SQL植入問題除外，需要報表工具配合一下哈
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
填寫採集的坑
★輸入控件評測重點在哪
1
★可以用Excel中離線填寫，並能複製Excel內容填
寫
2
★能不能讓業務人員不依賴於數據庫進行自定義填
報，並自行生成統計表
3
4
5
6
7
輸入控件評測重點在哪？
1.種類要多？
種類不用考察，號稱支持填報的產品都會提供，各種下拉控件，複選框等
2.性能
這纔是重點！必須有異步加載功能，因爲一些下拉框，下拉樹，數據量大的時候，如果沒
有異步加載，就卡死了
3.動態關聯
各控件之間要有動態關聯能力（關聯過濾，級聯）
Excel導入填報重點看啥？
1. 填報模板能生成帶有校驗或自動計算的Excel
2. 導出的excel編輯後，可重新填進填報模板
3. 以上功能要包括複雜格式填報，而不僅僅是簡單行式的（見下頁示例）
簡單行式excel導入填報，誰都可以做，做不了纔怪
4. 導入的excel數據量大時，可以設置分批加載
導入填報示例
比如這樣的表，能不能和填報模板對應起來，不寫代碼就能正確採集數據入庫？
業務人員自定義填報
業務人員設計上
傳填報模板
各級人員填報
自動彙總
數據分析
Excel離線填報
業務填報如果支持的不好會怎樣
找技術去搞
搞技術去
因爲需要填進數據庫，
而填進數據庫需要做
結構化，要懂數據庫
原理
爲啥要找技術？
1.自動結構化
2.不用數據庫彙總
分析
因爲要再彙總分析，
不計算的數據填報
上來也沒意義
爲啥要填進數據庫？
那咋辦？
這種表入庫時會對應多個數據表，還有主外鍵關聯！你想業務人員能自己造出
數據結構嗎？
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
報表平臺的坑
★是否開源
1
2
3
4
5
6
7
系統功能是否開源
用戶組織、權限、調度、這些功能點其實都 不 用 考 查
一方面，只要喊報表平臺，這些功能一定有，而且都差不多
另一方面，這些東西和應用環境密切相關，肯定不會全適合，到了現場反正還得改
所以，還不如問問是不是開源，或者是不是提供定製修改的服務？要收多少錢？
目錄頁
01 開發工具
02 數據源
03 報表模型
04 呈現輸出
05 自助報表
06 集成部署
07 填寫採集
08 報表平臺
09 性能
CONTENTS
性能如何評測
★幾種不專業的說法
1
★數據準備階段的性能 2
★報表呈現階段的性能
3
4
5
6
7
什麼說法不專業
• 我們可以支撐多大多大數據量
• 千萬數據幾秒可以響應
不說場景，只說性能是不負責任的
在自己設計的場景下跑的快，未必在用戶的場景下就靈
數據準備階段的性能
大部分的性能問題，都出在數據準備階段！！！！這時候考查報表工具的性能沒有意義
• 數據量太大，不會異步加載
• jdbc讀取慢
• 計算太複雜，需要複雜sql或者長存儲過程
這些其實不該歸罪與報表廠商，因爲沒有報表時候他們本身也慢
當然，如果廠商有數據計算工具，計算層來解決這些問題，那是應該加分的
報表呈現階段的性能
少部分情況下才會體現報表本身的計算性能
怎樣才能測出純報表的性能
拋開數據準備的時間，單獨統計報表運算的時間
• 多數據集關聯的複雜報表
• 帶部分明細的分組彙總表
可以用上面的兩個例子來測試對比看看哪家的工具
計算能力更強
按着先烈們趟出的這些坑
挨個去評測
就可以排除掉一大部分了
開源的、免費的基本都不靈
功能不全，bug太多
總結！！！
然後就是從倖存者當中再篩選了
看您更看重什麼
價格？
品牌？
服務？
然後！！！
THANKS