用存儲過程和 JAVA 寫報(bào)表數(shù)據(jù)源有什么弊端？跟著小編一起來一看一下吧！

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

3008 行，141KB 的存儲過程，會給報(bào)表開發(fā)帶來什么不好的影響？1. 編輯調(diào)試性
存儲過程難以編輯調(diào)試，這樣幾千行存儲過程的開發(fā)周期往往要以周或月計(jì)，這樣會嚴(yán)重影響報(bào)表的開發(fā)效率，而業(yè)務(wù)提的報(bào)表需求似乎都“很急”。2. 維護(hù)性
相對開發(fā)的一次性，維護(hù)的工作可能要經(jīng)常做。實(shí)際業(yè)務(wù)中報(bào)表經(jīng)常會修改，這種現(xiàn)象叫做報(bào)表業(yè)務(wù)的穩(wěn)定性差。報(bào)表的數(shù)據(jù)準(zhǔn)備邏輯變化，修改上千行的存儲過程對絕大多數(shù)報(bào)表開發(fā)人員來說都是噩夢。
有時這樣的報(bào)表會分兩撥人來做，DBA 或?qū)I(yè)程序員負(fù)責(zé)編寫存儲過程給前端報(bào)表開發(fā)人員做報(bào)表，這樣就避免了報(bào)表開發(fā)人員寫存儲過程。但這樣報(bào)表修改的流程會變長，修改一張報(bào)表涉及多個人員之間溝通（還包括業(yè)務(wù)人員），如果負(fù)責(zé)報(bào)表前后端的兩撥人隸屬不同的團(tuán)隊(duì)就更麻煩了。3. 知識傳承
從維護(hù)性可以直接引出另一個“知識傳承”的問題。還是拿上面的報(bào)表為例，如果一個新人要改上面的報(bào)表，你覺得他要多久能看懂存儲過程，改完報(bào)表？
當(dāng)然，這個問題還涉及很多管理方面的手段，單純從技術(shù)本身來看，這樣的報(bào)表想要很好地傳承知識是很難的。4. 安全性
對存儲過程的修改需要較高的數(shù)據(jù)庫權(quán)限，而報(bào)表經(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)致報(bào)表應(yīng)用（前端）和數(shù)據(jù)庫（后端）緊耦合。緊耦合除了會導(dǎo)致前面的三個問題外，還會讓數(shù)據(jù)庫編的臃腫，影響數(shù)據(jù)庫性能。
重要的事情說好多遍，報(bào)表的業(yè)務(wù)不穩(wěn)定，報(bào)表除了經(jīng)常增加和修改，有時還會刪除（不用了），而為這個報(bào)表準(zhǔn)備的存儲過程還在數(shù)據(jù)庫里，這時想要刪掉這個存儲過程就比較難了。
為什么？
因?yàn)槟悴恢朗遣皇沁€有其他程序在共用這個存儲過程，刪除會不會對其他程序產(chǎn)生影響。結(jié)果就是數(shù)據(jù)庫的存儲過程越積越多導(dǎo)致數(shù)據(jù)庫臃腫，而有的存儲過程還會涉及自動運(yùn)行，雖然存儲過程可能不再使用，但仍然在消耗數(shù)據(jù)庫資源，長此以往數(shù)據(jù)庫性能下降就成為必然了。7. 多源支持
存儲過程運(yùn)行在封閉的數(shù)據(jù)庫內(nèi)，無法進(jìn)行跨多數(shù)據(jù)源混合計(jì)算。關(guān)于多源問題，幾年前在報(bào)表開發(fā)還不顯著，那時大家都用關(guān)系庫；但現(xiàn)在不一樣了，同一個報(bào)表的數(shù)據(jù)可能來自多個不同類型的數(shù)據(jù)源（RDB/NoSQL/TxT/Excel/Hadoop/ES 等等），這時存儲過程就無能為力了。如何搞定這些問題？
有沒有辦法解決存儲過程帶來的這些問題呢？
當(dāng)然有！
沒有什么是硬編碼解決不了的！用 JAVA 替代存儲過程，脫離數(shù)據(jù)庫運(yùn)行來解決上面的問題（自行搜索 SOA 和微服務(wù)理念）。存儲過程一個顯示的好處是可以分步實(shí)現(xiàn)報(bào)表數(shù)據(jù)準(zhǔn)備邏輯，這個優(yōu)點(diǎn) JAVA 也有，甚至比存儲過程更徹底，說句文縐縐的話：JAVA 的離散性更好。
只是 JAVA 寫起來比較麻煩，對于報(bào)表開發(fā)人員來講太難了，如果還要加一個修飾詞那就是太 XX 難了。存儲過程使用的 SQL 語言非常適合做集合運(yùn)算，分組匯總一句 group by 就寫出來了，反觀 JAVA 就不具備這個優(yōu)點(diǎn)了，分組匯總可能要寫上幾十上百行才行（類庫缺失會讓開發(fā)復(fù)雜度急劇上升，想想你為什么不用匯編寫程序而要用 JAVA？）。
JAVA 還有一些其他的問題也不容忽視。不支持熱切換
JAVA 還有一個非常致命的缺點(diǎn)，就是不支持熱切換。報(bào)表經(jīng)常要改（又來一遍），修改報(bào)表數(shù)據(jù)源以后還要重新編譯、重啟應(yīng)用才能生效，對絕大多數(shù)業(yè)務(wù)系統(tǒng)都是不能接受的。報(bào)表講究的不僅是查詢立等可取，修改也要實(shí)時生效才行。報(bào)表與應(yīng)用緊耦合
與使用存儲過程會導(dǎo)致報(bào)表與數(shù)據(jù)庫緊耦合類似，用 JAVA 準(zhǔn)備報(bào)表數(shù)據(jù)源會導(dǎo)致報(bào)表模塊和應(yīng)用的其他業(yè)務(wù)模塊緊耦合不宜維護(hù)。
我們知道，報(bào)表大多數(shù)情況都是作為一個模塊集成到應(yīng)用系統(tǒng)提供報(bào)表查詢服務(wù)，集成的方式可以是 API（jar 包）方式緊集成；也可以將報(bào)表單獨(dú)發(fā)布成服務(wù)，通過服務(wù)調(diào)用的方式松集成，這樣報(bào)表服務(wù)器產(chǎn)生的任何壓力或問題都不會影響應(yīng)用系統(tǒng)（高可用）。
*API 緊集成后，由于報(bào)表數(shù)據(jù)源是 JAVA 寫的，這樣就要和主應(yīng)用的代碼一起打包，無法作為獨(dú)立的模塊維護(hù)，而未來想要拆分也基本不可能了；
* 服務(wù)松集成則完全無法實(shí)現(xiàn)。
所以，用 JAVA 寫報(bào)表數(shù)據(jù)源雖然可行，但也不是特別理想。
那有沒有其他辦法呢？
我們比較一下存儲過程和 JAVA 的優(yōu)缺點(diǎn)可以發(fā)現(xiàn)，解決問題應(yīng)該是沿著繼承二者優(yōu)點(diǎn)，改進(jìn)缺點(diǎn)的方向進(jìn)行。清晰起見，總結(jié)一下需要的點(diǎn)。

把主要的點(diǎn)列了一下，我們的目標(biāo)就是找到支持這些點(diǎn)的技術(shù)手段（問號所在行）。易開發(fā)、易維護(hù)
這注定了這些能力應(yīng)該是報(bào)表工具內(nèi)置的，這樣報(bào)表開發(fā)人員自己就能使用工具搞定報(bào)表開發(fā)，而不必依賴其他人或團(tuán)隊(duì)；熱切換
熱切換要求這個技術(shù)應(yīng)該是解釋執(zhí)行的，這樣才能做到實(shí)時修改實(shí)時生效；支持多源
能夠?qū)佣喾N不同類型的數(shù)據(jù)源進(jìn)行混合計(jì)算，比如文本和數(shù)據(jù)庫表的 join；低耦合、可移植
數(shù)據(jù)準(zhǔn)備能力和報(bào)表呈現(xiàn)能力都報(bào)表內(nèi)置了，自然與應(yīng)用和數(shù)據(jù)源都解耦了，未來系統(tǒng)擴(kuò)展自然毫無壓力。
這樣我們可以很容易想到在報(bào)表端增加一個計(jì)算模塊，來替代存儲過程或 JAVA 為報(bào)表準(zhǔn)備數(shù)據(jù)，這個模塊可以是由嵌入報(bào)表工具的腳本來實(shí)現(xiàn)，結(jié)構(gòu)可以是這樣的

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

總結(jié)

以上是生活随笔為你收集整理的java实现报表_用存储过程和 JAVA 写报表数据源有什么弊端？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。