用存儲過程和JAVA寫報表數據源有哪些弊端

本篇內容主要講解“用存儲過程和JAVA寫報表數據源有哪些弊端”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“用存儲過程和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 為報表準備數據，這個模塊可以是由嵌入報表工具的腳本來實現，結構可以是這樣的

腳本要具備完善的計算能力（什么計算都能算），支持多源，解釋執行允許熱切換這些能力。

到此，相信大家對“用存儲過程和JAVA寫報表數據源有哪些弊端”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！