潤乾報表、帆軟報表、Smartbi、永洪 BI、億信 BI 這幾款國內產品都把中國複雜報表做爲宣傳點。咱們以常見的多源分片爲報表爲用例，來對比評測這些產品的處理能力（因爲時間和知識限制，個別很偏的功能點可能會有遺漏）。sql
內容比較長，若是不想看細節，能夠直接跳到最後看結論。數據庫
用例說明
報表式樣數據結構
數據結構nosql
[訂單表]函數
主數據存儲在訂單表中，該表經過僱員 ID 和銷售員表關聯，經過產品 ID 和產品表關聯。工具
[銷售員表]佈局
銷售員表中存儲職務、姓名，報表左下角統計數據時按照職務和姓名統計，該表經過僱員 ID 和訂單表關聯。學習
[產品表]開發工具
產品表中包含類別 ID 和產品 ID，而且是一對多關係，報表中須要按照類別分組，也就是要按該類別下多個產品的信息彙總。經過產品 ID 和訂單表關聯url
[類別表]
這是一箇中文字典表，經過它將類別 ID 映射成中文名稱。
假定數據都來自數據庫，可用 SQL 語句取出。
報表特色分析
一、 這是一個典型的多源分片報表，報表能夠分紅左上、右上、左下、右下四片區域，每片數據來自不一樣數據表（甚至可能不一樣數據庫），須要實現多個數據集之間的關聯。
二、 對字段數據的處理，數據庫中存儲的是訂購日期，報表中須要按照年、月分組統計，須要根據日期解析出年、月，彙總區域是金額，數據庫中存儲的是單價、數量，須要對字段進行相乘操做。
三、 上表頭中的產品類別須要按肯定的次序排列，也就是維表 ID 的次序。
四、 左表頭的層次不同，上半兩層，下半三層。
下面看下幾款工具製做這個報表的過程和工做量。
關於工做量的評估，咱們假定使用者均熟悉 SQL 語句且瞭解相應的報表工具，並只記錄實際的製做和正常調試的時間，不包括查閱產品函數資料的時間，也就是一個熟手的完成時間。
潤乾報表
製做過程
一、 配置並鏈接數據源，這個各個工具操做基本都相似，按照嚮導方式配置就行。
二、 設置數據集
潤乾報表支持多數據集，本例的數據存儲在四個表內，因此在報表中增長四個數據集，只要分別取四個表的數據（select * from …），能夠經過嚮導操做。
三、 設計報表模板
多源分片報表是一個比較基礎的中國式報表，國內報表工具基本都支持，這裏看下幾個關鍵單元格的設置：
3.一、 A3 單元格表達式：=ds1.group(year( 訂購日期);year(訂購日期):1)+「年」，需求中要求按照年月分組，而數據庫中存儲的是訂購日期，因此此處先經過 year 函數取訂購日期中的年份。
3.二、 D3 單元格：=ds1.sum( 數量_單價 )，報表統計項中的金額是經過單價_數量這兩個字段生成。
3.三、 E2 單元格按照類別 ID 分組統計，可是要求這個單元格顯示中文，單元格有個顯示值表達式屬性：
中文能夠來自單獨的一個數據集，這樣經過內置的函數就能夠將 id 映射成中文。
3.四、 E3 單元格：=ds1.sum(數量 * 單價, 產品 ID in ds4.select( 產品 ID))，多源分片最主要的要將多個數據源數據關聯在一塊兒，函數裏邊寫入過濾條件就行，銷售額在 ds1 數據集中，E2 單元格的類別來自 ds4 數據集，ds1 和 ds4 經過產品 ID 關聯，ds4 中類別 ID 和產品 ID 是一對多的關係，因此此處關聯用 in，這樣報表右上方就能取出對應類別下的數據彙總。
3.五、 報表第四行表達式相似，主要是 ds1 和 ds3 數據集之間的關聯，這裏就不細說了。
3.六、 單元格邊框、合併單元格，這些操做和 excel 中基本一致，按照需求設置就行。
運行結果
完成後點評
一、 用時 0.5 小時。
二、 常規設置和操做 excel 相似，再加上報表內的函數，製做起來很快。
三、 函數豐富，好比 =ds1.group(year( 訂購日期);year(訂購日期):1)+「年」 ，對訂購日期的年份進行分組，直接用 year 函數取年就行，沒必要對源數據集進行單獨設置；相似地，=ds1.sum( 數量 * 單價) 數據由其餘字段組合生成時，直接使用函數，不須要單獨寫 sql 語句等，這樣只關心報表中幾個函數的使用就行。
四、 多源關聯方便，好比：=ds1.sum(數量 * 單價, 產品 ID in ds4.select( 產品 ID))，仍是經過函數內置的一些功能實現，不用在數據集中處理，絕大多數操做都是在單元格函數中控制。
五、 產品類別用維表擴展（E2 格中用 ds2.group 根據類別 ID 分組），很容易保證次序，再設置顯示值就能顯示相應的中文名稱。
六、 採用類 Excel 操做，佈局、樣式設置按照之前的思惟處理就行，包括一些數據彙總等等。
七、 表達式基本上都是手填，雖然有表達式編輯界面，但還不如手填來得方便。
帆軟報表
製做過程
一、 配置並鏈接數據源
二、 設置數據集
帆軟報表支持單元格中的多數據集關聯，在報表中新增四個數據集，分別對應 4 個數據表。但訂單表的 SQL 特殊一點，先要用 單價 * 數量 as 銷售金額，報表中要對銷售金額彙總，金額來自單價和數量兩個字段的乘積。由於在報表中沒找到字段相乘彙總的辦法，因此在取數時新增一個列。
三、 設計報表模板
3.1 分別根據訂購日期的年份、月份分組，將 ds1 中的訂購日期拖拽到單元格 A3 中，在自定義分組對話框中設置自定義公式:year($$$)+」年」， 將 ds1 中的訂購日期字段拖拽到 C3 中，一樣增長自定義公式分組，分組表達式爲 month($$$)+」月」
3.2 D2 單元格按照城市排序，程序裏默認按照中文的 ASCII 碼排序，若是想按照拼音排序則須要在單元格屬性的擴展排序中設置公式，如：
使用該函數須要下載函數插件。類別字段是按 ID 排序，則不須要專門處理。
3.3 交叉點中的銷售金額統計，在數據集中先作了處理生成了銷售金額字段，此處直接進行求和操做。
3.4 多數據集單元格關聯。帆軟在作多源關聯的時候，經過下拉選擇數據列，操做符和比較的對象，經過點擊增長按鈕，自動生成關聯的條件表達式。
3.5 顯示值設置
對 C5 中僱員 ID 須要最終顯示出僱員的姓名，在形態中要選擇數據查詢，設置對應的顯示值字段。
報表結果
完成後點評
一、 用時，0.5 小時。
二、 數據集設置裏直接用嚮導取數，沒有特殊的寫法，製做這樣的報表對寫 SQL 能力要求不高。
三、 處處都有可視化界面，操做體驗對初學者很是良好。好比報表中多源關聯時，經過下拉選擇數據列、操做符和比較的對象，就能自動生成關聯的條件表達式，不須要對源數據進行關聯處理。
四、 工具採用類 Excel 操做，佈局、樣式設置按照之前的思惟處理就行，包括一些數據彙總等等。
五、 運算模型把字段和表達式分別處理的，須要增長自定義表達式才能拖拽填入，對熟手略顯囉嗦。
六、 中文排序默認是按照 ASCII 排序，並非按照常規的首字母方式，要按首字母排序要用 StringPinyin() 函數轉換下，須要單獨下載插件，這裏有點不方便。
七、 銷售金額來源於單價 * 數量，帆軟單元格里不能直接先對字段相乘而後再求和，本例中是經過 SQL 語句新增字段，文本數據源或者 nosql 數據庫沒法執行 SQL 時，只能在報表中增長隱藏行，會比較麻煩。
Smartbi
製做過程
一、 配置並鏈接數據源。
二、 準備數據集
報表支持多數據集，這裏按照須要準備四個，每一個數據集分別取自描述中數據結構的四個物理表。
其中訂單數據集：「select _, 數量_單價金額,year(訂購日期) 年,month(訂購日期) 月 from 訂單」 ，由於報表內要根據訂購日期按 年和月分組，但 smartbi 沒有對應的單元格函數支持，因此須要在數據準備階段把須要分組的字段獨立成一個字段。彙總金額也是一樣的，在數據集已有字段先算出「金額」。其他數據集取出相應數據就行。
三、 設計報表模板
3.1 訂單數據集中已經處理了年、月、金額等，因此報表中直接使用處理後的字段，用鼠標將相應的字段拖拽到對應單元格就行，和其餘類 Excel 開發工具相似，此處就不作過細說明了。
3.2 多數據集間關聯是經過「過濾」功能，普通條件類型選擇數據列，下面的過濾條件就能夠直接能夠和其餘數據集的字段關聯了，以下
設計界面
運行結果
完成後點評
一、 用時：1 小時左右。
二、 Smartbi 在 excel 中進行報表開發，比較符合常規使用習慣，主要查看下具體函數使用以及關聯操做就行。
三、 關聯直接在報表單元格中經過嚮導方式設置，簡單的關聯不須要手寫代碼。
四、 儘管是點選方式設置過濾表達式，不過有些可複用的表達式無法複製粘貼，都必須重複點選一次。
五、 對於年、月分組的處理，沒有可用的單元格函數，須要在數據準備階段，基於「訂購日期」字段把年、月單獨處理成獨立字段。訂單金額一樣，須要在數據集中設置。若是數據來源是文本文件或者是 NOSQL 數據庫，沒法寫 SQL 語句處理這些字段，這類需求就很難實現了，只能更改數據結構或者報表中增長輔助行列（本例是彙總表，須要增長大量隱藏行列），可行性不大，因此在實際應用中仍是有必定限制的。
六、 在設計過程當中發現，當有增刪行時，其餘格子設置的主格不自動變化，這個有點費勁了，一旦有這種狀況，都得檢查改一遍。
七、 沒有真實值和顯示值的分類，致使存放在不一樣庫的碼錶沒法把名稱給顯示出來。 若是必須弄，須要藉助「轉換規則」，先建轉換規則，而後給業務數據集的字段選擇規則，而後單元格屬性勾選「使用顯示值」這個東西是系統配置，也就是須要系統功能配合才能作到 ID 反顯名稱。
永洪 BI
製做過程
一、 配置並鏈接數據源
二、 設置數據集
永洪中自由格式報表支持多數據源，按照嚮導方式新增四個數據集，每一個數據集對應數據庫中的一張表，造成銷售員、訂單、產品、類別名稱四個數據集。永洪報表單元格內支持多數劇集關聯的，但使用起來有問題，好比類別表和訂單表關聯是經過產品 ID，類別和產品 ID 是個一對多的關係，永洪單元格內關聯不支持這種 in 的形式，因此沒辦法用它的多數據集模型來實現這張報表。只能換個思路，在數據集階段將多個數據集合成一個數據集。本例中實質上是一個事實表和三個維表的關聯，還能夠改用組合數據集，經過嚮導將多個數據集結果關聯造成一個單數據集：
2.一、 新建組合數據集，將已經建立好的四個數據集經過關聯字段關聯起來，經過嚮導方式設置就行。
2.二、 訂購日期年、月的處理，在數據集設置中，能夠在訂購日期上新增長統計字段，用內置函數生成新的字段年和月
2.三、 金額的話一樣，能夠新增字段，裏邊寫入 單價 * 數量，生成新的計算列
三、 設計報表模板
在數據集設置中，用「組合數據集」將多個數據集關聯成了一個數據集，而且對年、月、金額等數據作了處理，因此報表中設計器來就比較方便了，直接用鼠標將字段拖拽到對應的位置，設置擴展方向、合併格等就能夠了。
運行結果
完成後點評
一、 報表製做用時，1 小時多。數據集多數據源關聯須要較長時間。
二、 數據處理能力較強，提供「組合數據集」將已有的數據集（可跨庫）關聯成一個新的數據集。可以在數據集基礎上新增統計列。
三、 多源關聯支持有必定侷限性，最好的關聯方式應該是報表內單元格間多數據集的關聯，這樣就不用考慮具體數據集的來源，永洪自己是支持單元格內作格間過濾的，可是關聯只能用「=」，而像本例中的類別和產品一對多的關聯要用 in 形式，它就不支持了，因此必需要轉成單數據集。本例是一個事實表和三個維表的關聯，還能轉換成單數據集對付，實際應用中數據集個數可能會更多，關聯會更復雜、甚至會出現多對多的關聯，就作不成單數據集了。並且即便是維表和事實表的簡單關聯，還須要考慮 left join 等關聯方式，設置工做量大增。本例製做時維表中有冗餘數據，致使數據不許確，花了較長時間才發現問題，嚴格上來講並非一個好方案。整體來看，永洪的多源關聯能力還不夠完善。
四、 上表頭的類別排序實現困難，永洪中單元格不支持顯示值屬性的設置，要想顯示中文單元格內只能從數據集中取中文字段，這樣就會按照中文字段排序了，沒法達到按照 ID 排序需求，卻是能夠加個隱藏行，裏邊按照 ID 分組排序，而後下邊增長一行顯示中文，須要增長輔助行，有點費事了。
五、 報表中設置了表頭斜線，結果中能顯示，可是在設計模板中看不到效果，容易形成混淆。包括單元格多選，不能像 excel 那樣鼠標選中一片，要按 ctrl 鍵，不太方便。
億信
製做過程
一、 配置並鏈接數據源。
二、 設置數據集
億信支持多個數據來源，在數據集中增長多個數據集，數據集類型分爲主題表和維表，主題表是報表中用到的主數據來源，也就是事實表，好比本例的訂單信息，維表用於中文顯示值映射，也就是碼錶。按照嚮導設置，內容就是普通的 sql 語句，好比（select * from ……）。
億信報表也支持數據來自多個數據集，可是若是兩個數據集要關聯取數的話報表單元格內是沒法作到的，要提早在數據集設置頁面設置表間關係。好比本例中訂單表和銷售員表是經過僱員 ID 關聯，那麼要設置一下兩個數據集間的表關聯關係：
三、報表設計頁面
億信報表的計算和其餘報表工具不一樣，其餘報表是先執行數據集取數，而後報表內根據表達式從數據集結果中取數運算，而億信是分析單元格、解析單元格表達式、查找表間關係、拼 sql 取數返回到單元格，好比產品類別那列，第二行是 CHANPIN 數據集，第三行是 DINGDAN 數據集，
若是數據集建立階段沒有設置表間關係，那麼會解析成兩個 SQL 去數據庫取數，因爲報表單元格內沒法設置關聯，這兩段數據是沒有任何關聯的，本例要求取對應類別下的數據，因此在數據集處建立了 CHANPIN 和 DINGDAN 的關聯，這樣這塊就會解析成相似：select price*num from DINGDAN,CHANPIN where DINGDAN. 產品 ID=CHANPIN. 產品 ID，將這個 SQL 發送到數據庫端而後取結果返回，這樣就能關聯展現，這裏能夠看到，由於要解析成一個 SQL，因此要求兩個數據集來源必須是同一個庫。從這個意義講，億信並不能算嚴格支持多源關聯報表，關鍵運算是轉換成 SQL 丟給數據庫去作的。
億信的難點在於前期的數據整合、設置表間關聯，報表設計的具體操做和其餘工具就都比較相似了，好比類別那能夠取類別 ID 並按照 ID 排序，在設置顯示值，具體這裏就不一一說明了。
運行結果
完成後點評
一、 製做用時 1 小時。
二、 多源關聯時的處理，要對源數據進行數據的關聯處理，數據集多時，找表間關聯關係還要驗證關聯後的數據準確性，耗時較長。
三、 能夠經過函數對數據集字段操做，好比年、月維度的控制，銷售金額來源於 danjia*shuliang，不須要在數據集中控制。
四、 難點在數據關聯處理，數據處理完成後，這個報表格式比較簡單，實際報表製做主要經過鼠標拖拽仍是比較方便，固然這個好像多個報表工具操做都差很少。
五、 多源關聯支持是有問題的，億信的機制是報表計算時解析單元格內的表達式而後尋找表間關係再拼成 SQL 方式去數據庫取數（其實本質仍是數據庫內的關聯），那麼就要求多個數據集來自同一個庫，這樣沒法處理異庫數據集間的關聯，更沒法支持非數據庫來源的數據。即便是同一數據庫，在設置表關聯時爲保證維數據的不丟失，還要考慮 left join 等狀況，實際操做起來仍是有些難度的，還要避免出現多對多的狀況，不然沒法保證數據的正確性，當前機制下處理多源關聯類報表難度大。
總結
多源分片報表是很是典型的複雜報表，僅僅從這一個簡單例子，也能看出各家產品的風格，並且，這些風格並不僅侷限於這一個報表，能夠說是這些產品的基本特徵。
-
若是不糾結細節的話，各家產品都能完成這個報表，從功能上講算是都能過關的。
-
從報表開始起家的潤乾和帆軟明顯要更強，製做過程流暢性要比永洪和億信這兩家以 BI 起家的產品好不少。後二者並不以複雜報表做爲主要賣點，但受市場壓力，也要提供這種能力，基本上就是作到「能夠用」的水平，但遠遠談不上好用。Smartbi 介於這兩類中間，它以 BI 起家，但年代要久遠，受到複雜報表的需求壓力也較多，能力比永洪億信要好不少，但和潤乾帆軟相比仍有必定的差距。
-
報表模型上，潤乾和帆軟基本同樣，Smartbi 也相似；永洪和億信則相差較大。這種單元格擴展來解決分片報表的機制先由潤乾發明，帆軟以後跟隨，擴展模型層面基本上全抄，只是改了術語名稱（主格改叫父格），所以是同樣的，能力也基本至關。Smartbi 以後再抄過來（延用了帆軟的術語，這裏面還有故事就不說了），結果造成了類似的模型。而永洪和億信的 BI 基因較強，對複雜報表的邏輯理解還不夠深入，模型就差了不少，能力固然也會差不少，這兩家產品的複雜報表只能算是入門階段，和其它三家相比不在一個檔次。
-
潤乾和帆軟的使用都較爲流暢，但風格也仍有不一樣。潤乾製做過程當中提倡手寫表達式，而帆軟則更多用可視化界面。看起來後者會對使用者更友好，這也是業界經常說用潤乾難帆軟易的現象。但對於熟手來說，手寫表達式的效率更高，並且能夠隨意靈活組合；使用界面編輯對生手門檻低，熟手卻會嫌煩，還犧牲靈活性。好比此例中帆軟須要先定製數據集把表達式邏輯化成字段才行，而潤乾對於表達式和字段是同一套規則，無需專門處理。
-
從這個意義上，潤乾和帆軟的擴展模型雖然都同樣，但底層運算模型仍是有差別。潤乾的抽象程度更深，數據計算能力也就更強，初期掌握難度略大，但一旦掌握就會發現可以橫掃一切；而帆軟考慮的狀況要簡單，在簡單狀況下更順手，但碰到特殊狀況時還要再用特殊手段，反而進一步提升學習成本。結果的表現是：初次使用且沒碰到複雜狀況時帆軟的效率更高（選型考察產品時經常是這樣的），長期反覆使用時（總會碰到複雜狀況了）潤乾的效率就會明顯佔優。