用存儲過程和JAVA寫報表數(shù)據(jù)源有哪些弊端

本篇內(nèi)容主要講解“用存儲過程和JAVA寫報表數(shù)據(jù)源有哪些弊端”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“用存儲過程和JAVA寫報表數(shù)據(jù)源有哪些弊端”吧!

我們在報表開發(fā)中經(jīng)常會使用存儲過程準(zhǔn)備數(shù)據(jù)，存儲過程支持分步計算，可以實現(xiàn)非常復(fù)雜的計算邏輯，為報表開發(fā)帶來便利。所以，報表開發(fā)中這樣的存儲過程并不少見：

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

1. 編輯調(diào)試性
存儲過程難以編輯調(diào)試，這樣幾千行存儲過程的開發(fā)周期往往要以周或月計，這樣會嚴(yán)重影響報表的開發(fā)效率，而業(yè)務(wù)提的報表需求似乎都“很急”。

2. 維護(hù)性
相對開發(fā)的一次性，維護(hù)的工作可能要經(jīng)常做。實際業(yè)務(wù)中報表經(jīng)常會修改，這種現(xiàn)象叫做報表業(yè)務(wù)的穩(wěn)定性差。報表的數(shù)據(jù)準(zhǔn)備邏輯變化，修改上千行的存儲過程對絕大多數(shù)報表開發(fā)人員來說都是噩夢。

有時這樣的報表會分兩撥人來做，DBA 或?qū)I(yè)程序員負(fù)責(zé)編寫存儲過程給前端報表開發(fā)人員做報表，這樣就避免了報表開發(fā)人員寫存儲過程。但這樣報表修改的流程會變長，修改一張報表涉及多個人員之間溝通（還包括業(yè)務(wù)人員），如果負(fù)責(zé)報表前后端的兩撥人隸屬不同的團(tuán)隊就更麻煩了。

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

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

4. 安全性
對存儲過程的修改需要較高的數(shù)據(jù)庫權(quán)限，而報表經(jīng)常要改就要經(jīng)常操作數(shù)據(jù)庫，這對數(shù)據(jù)庫安全也是一個隱患，同樣需要強(qiáng)管理機(jī)制才能保障一二。

5. 移植性
現(xiàn)在絕大多數(shù)規(guī)定禁止使用存儲過程的原因，首當(dāng)其沖的就是存儲過程沒有移植性。如果未來數(shù)據(jù)庫發(fā)生變化需要遷移，不管將來是更換數(shù)據(jù)庫類型，還是系統(tǒng)擴(kuò)展（分表分庫），大量無法移植的存儲過程絕對是最頭疼的問題。

當(dāng)然，“換庫”這件事情即使在今天仍然不會頻繁發(fā)生，但是只要發(fā)生一次就夠受了（有國產(chǎn)化或系統(tǒng)擴(kuò)展預(yù)期的就要注意了）。

6. 耦合性
從維護(hù)性、安全性和移植性看來，存儲過程會導(dǎo)致報表應(yīng)用（前端）和數(shù)據(jù)庫（后端）緊耦合。緊耦合除了會導(dǎo)致前面的三個問題外，還會讓數(shù)據(jù)庫編的臃腫，影響數(shù)據(jù)庫性能。

重要的事情說好多遍，報表的業(yè)務(wù)不穩(wěn)定，報表除了經(jīng)常增加和修改，有時還會刪除（不用了），而為這個報表準(zhǔn)備的存儲過程還在數(shù)據(jù)庫里，這時想要刪掉這個存儲過程就比較難了。

為什么？

因為你不知道是不是還有其他程序在共用這個存儲過程，刪除會不會對其他程序產(chǎn)生影響。結(jié)果就是數(shù)據(jù)庫的存儲過程越積越多導(dǎo)致數(shù)據(jù)庫臃腫，而有的存儲過程還會涉及自動運行，雖然存儲過程可能不再使用，但仍然在消耗數(shù)據(jù)庫資源，長此以往數(shù)據(jù)庫性能下降就成為必然了。

7. 多源支持
存儲過程運行在封閉的數(shù)據(jù)庫內(nèi)，無法進(jìn)行跨多數(shù)據(jù)源混合計算。關(guān)于多源問題，幾年前在報表開發(fā)還不顯著，那時大家都用關(guān)系庫；但現(xiàn)在不一樣了，同一個報表的數(shù)據(jù)可能來自多個不同類型的數(shù)據(jù)源（RDB/NoSQL/TxT/Excel/Hadoop/ES 等等），這時存儲過程就無能為力了。

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

當(dāng)然有！

沒有什么是硬編碼解決不了的！用 JAVA 替代存儲過程，脫離數(shù)據(jù)庫運行來解決上面的問題（自行搜索 SOA 和微服務(wù)理念）。存儲過程一個顯示的好處是可以分步實現(xiàn)報表數(shù)據(jù)準(zhǔn)備邏輯，這個優(yōu)點 JAVA 也有，甚至比存儲過程更徹底，說句文縐縐的話：JAVA 的離散性更好。

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

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

不支持熱切換
JAVA 還有一個非常致命的缺點，就是不支持熱切換。報表經(jīng)常要改（又來一遍），修改報表數(shù)據(jù)源以后還要重新編譯、重啟應(yīng)用才能生效，對絕大多數(shù)業(yè)務(wù)系統(tǒng)都是不能接受的。報表講究的不僅是查詢立等可取，修改也要實時生效才行。

報表與應(yīng)用緊耦合
與使用存儲過程會導(dǎo)致報表與數(shù)據(jù)庫緊耦合類似，用 JAVA 準(zhǔn)備報表數(shù)據(jù)源會導(dǎo)致報表模塊和應(yīng)用的其他業(yè)務(wù)模塊緊耦合不宜維護(hù)。

我們知道，報表大多數(shù)情況都是作為一個模塊集成到應(yīng)用系統(tǒng)提供報表查詢服務(wù)，集成的方式可以是 API（jar 包）方式緊集成；也可以將報表單獨發(fā)布成服務(wù)，通過服務(wù)調(diào)用的方式松集成，這樣報表服務(wù)器產(chǎn)生的任何壓力或問題都不會影響應(yīng)用系統(tǒng)（高可用）。
*API 緊集成后，由于報表數(shù)據(jù)源是 JAVA 寫的，這樣就要和主應(yīng)用的代碼一起打包，無法作為獨立的模塊維護(hù)，而未來想要拆分也基本不可能了；
* 服務(wù)松集成則完全無法實現(xiàn)。

所以，用 JAVA 寫報表數(shù)據(jù)源雖然可行，但也不是特別理想。

那有沒有其他辦法呢？

我們比較一下存儲過程和 JAVA 的優(yōu)缺點可以發(fā)現(xiàn)，解決問題應(yīng)該是沿著繼承二者優(yōu)點，改進(jìn)缺點的方向進(jìn)行。清晰起見，總結(jié)一下需要的點。

把主要的點列了一下，我們的目標(biāo)就是找到支持這些點的技術(shù)手段（問號所在行）。

易開發(fā)、易維護(hù)
這注定了這些能力應(yīng)該是報表工具內(nèi)置的，這樣報表開發(fā)人員自己就能使用工具搞定報表開發(fā)，而不必依賴其他人或團(tuán)隊；

熱切換
熱切換要求這個技術(shù)應(yīng)該是解釋執(zhí)行的，這樣才能做到實時修改實時生效；

支持多源
能夠?qū)佣喾N不同類型的數(shù)據(jù)源進(jìn)行混合計算，比如文本和數(shù)據(jù)庫表的 join；

低耦合、可移植
數(shù)據(jù)準(zhǔn)備能力和報表呈現(xiàn)能力都報表內(nèi)置了，自然與應(yīng)用和數(shù)據(jù)源都解耦了，未來系統(tǒng)擴(kuò)展自然毫無壓力。

這樣我們可以很容易想到在報表端增加一個計算模塊，來替代存儲過程或 JAVA 為報表準(zhǔn)備數(shù)據(jù)，這個模塊可以是由嵌入報表工具的腳本來實現(xiàn)，結(jié)構(gòu)可以是這樣的

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

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