用儲存過程和 JAVA 寫報表資料來源有什麼弊端？

我們在報表開發中經常會使用儲存過程準備資料，儲存過程支援分步計算，可以實現非常複雜的計算邏輯，為報表開發帶來便利。所以，報表開發中這樣的儲存過程並不少見：

3008 行，141KB 的儲存過程，會給報表開發帶來什麼不好的影響？

1. 編輯除錯性
儲存過程難以編輯除錯，這樣幾千行儲存過程的開發週期往往要以周或月計，這樣會嚴重影響報表的開發效率，而業務提的報表需求似乎都“很急”。

2. 維護性
相對開發的一次性，維護的工作可能要經常做。實際業務中報表經常會修改，這種現象叫做報表業務的穩定性差。報表的資料準備邏輯變化，修改上千行的儲存過程對絕大多數報表開發人員來說都是噩夢。

有時這樣的報表會分兩撥人來做，DBA 或專業程式設計師負責編寫儲存過程給前端報表開發人員做報表，這樣就避免了報表開發人員寫儲存過程。但這樣報表修改的流程會變長，修改一張報表涉及多個人員之間溝通（還包括業務人員），如果負責報表前後端的兩撥人隸屬不同的團隊就更麻煩了。

3. 知識傳承
從維護性可以直接引出另一個“知識傳承”的問題。還是拿上面的報表為例，如果一個新人要改上面的報表，你覺得他要多久能看懂儲存過程，改完報表？

當然，這個問題還涉及很多管理方面的手段，單純從技術本身來看，這樣的報表想要很好地傳承知識是很難的。

4. 安全性
對儲存過程的修改需要較高的資料庫許可權，而報表經常要改就要經常運算元據庫，這對資料庫安全也是一個隱患，同樣需要強管理機制才能保障一二。

5. 移植性
現在絕大多數規定禁止使用儲存過程的原因，首當其衝的就是儲存過程沒有移植性。如果未來資料庫發生變化需要遷移，不管將來是更換資料庫型別，還是系統擴充套件（分表分庫），大量無法移植的儲存過程絕對是最頭疼的問題。

當然，“換庫”這件事情即使在今天仍然不會頻繁發生，但是隻要發生一次就夠受了（有國產化或系統擴充套件預期的就要注意了）。

6. 耦合性
從維護性、安全性和移植性看來，儲存過程會導致報表應用（前端）和資料庫（後端）緊耦合。緊耦合除了會導致前面的三個問題外，還會讓資料庫編的臃腫，影響資料庫效能。

重要的事情說好多遍，報表的業務不穩定，報表除了經常增加和修改，有時還會刪除（不用了），而為這個報表準備的儲存過程還在資料庫裡，這時想要刪掉這個儲存過程就比較難了。

為什麼？

因為你不知道是不是還有其他程式在共用這個儲存過程，刪除會不會對其他程式產生影響。結果就是資料庫的儲存過程越積越多導致資料庫臃腫，而有的儲存過程還會涉及自動執行，雖然儲存過程可能不再使用，但仍然在消耗資料庫資源，長此以往資料庫效能下降就成為必然了。

7. 多源支援
儲存過程執行在封閉的資料庫內，無法進行跨多資料來源混合計算。關於多源問題，幾年前在報表開發還不顯著，那時大家都用關係庫；但現在不一樣了，同一個報表的資料可能來自多個不同型別的資料來源（RDB/NoSQL/TxT/Excel/Hadoop/ES 等等），這時儲存過程就無能為力了。

如何搞定這些問題？
有沒有辦法解決儲存過程帶來的這些問題呢？

當然有！

沒有什麼是硬編碼解決不了的！用 JAVA 替代儲存過程，脫離資料庫執行來解決上面的問題（自行搜尋 SOA 和微服務理念）。儲存過程一個顯示的好處是可以分步實現報表資料準備邏輯，這個優點 JAVA 也有，甚至比儲存過程更徹底，說句文縐縐的話：JAVA 的離散性更好。

只是 JAVA 寫起來比較麻煩，對於報表開發人員來講太難了，如果還要加一個修飾詞那就是太 XX 難了。儲存過程使用的 SQL 語言非常適合做集合運算，分組彙總一句 group by 就寫出來了，反觀 JAVA 就不具備這個優點了，分組彙總可能要寫上幾十上百行才行（類庫缺失會讓開發複雜度急劇上升，想想你為什麼不用匯編寫程式而要用 JAVA？）。

JAVA 還有一些其他的問題也不容忽視。

不支援熱切換
JAVA 還有一個非常致命的缺點，就是不支援熱切換。報表經常要改（又來一遍），修改報表資料來源以後還要重新編譯、重啟應用才能生效，對絕大多數業務系統都是不能接受的。報表講究的不僅是查詢立等可取，修改也要實時生效才行。

報表與應用緊耦合
與使用儲存過程會導致報表與資料庫緊耦合類似，用 JAVA 準備報表資料來源會導致報表模組和應用的其他業務模組緊耦合不宜維護。

我們知道，報表大多數情況都是作為一個模組整合到應用系統提供報表查詢服務，整合的方式可以是 API（jar 包）方式緊整合；也可以將報表單獨釋出成服務，透過服務呼叫的方式松整合，這樣報表伺服器產生的任何壓力或問題都不會影響應用系統（高可用）。
*API 緊整合後，由於報表資料來源是 JAVA 寫的，這樣就要和主應用的程式碼一起打包，無法作為獨立的模組維護，而未來想要拆分也基本不可能了；
* 服務松整合則完全無法實現。

所以，用 JAVA 寫報表資料來源雖然可行，但也不是特別理想。

那有沒有其他辦法呢？

我們比較一下儲存過程和 JAVA 的優缺點可以發現，解決問題應該是沿著繼承二者優點，改進缺點的方向進行。清晰起見，總結一下需要的點。

把主要的點列了一下，我們的目標就是找到支援這些點的技術手段（問號所在行）。

易開發、易維護
這注定了這些能力應該是報表工具內建的，這樣報表開發人員自己就能使用工具搞定報表開發，而不必依賴其他人或團隊；

熱切換
熱切換要求這個技術應該是解釋執行的，這樣才能做到實時修改實時生效；

支援多源
能夠對接多種不同型別的資料來源進行混合計算，比如文字和資料庫表的 join；

低耦合、可移植
資料準備能力和報表呈現能力都報表內建了，自然與應用和資料來源都解耦了，未來系統擴充套件自然毫無壓力。

這樣我們可以很容易想到在報表端增加一個計算模組，來替代儲存過程或 JAVA 為報表準備資料，這個模組可以是由嵌入報表工具的指令碼來實現，結構可以是這樣的

指令碼要具備完善的計算能力（什麼計算都能算），支援多源，解釋執行允許熱切換這些能力。

這才是報表工具的未來！

參考資料：