【每周一期-數(shù)據(jù)蔣堂】存儲過程的利之弊

存儲過程是數(shù)據(jù)庫領(lǐng)域中應(yīng)用非常廣泛的技術(shù)，關(guān)于它的利弊討論由來已久，我們這里針對存儲過程的兩個公認度較高的優(yōu)點進行剖析，從而更清楚存儲過程的潛在風險及應(yīng)用場景。

存儲過程利于界面與邏輯分離！

界面與邏輯分離是現(xiàn)代應(yīng)用開發(fā)的一個基本準則。相對于后臺數(shù)據(jù)處理邏輯，界面會有更多樣性的環(huán)境，如PC、手機等，而且業(yè)務(wù)穩(wěn)定性也不強，經(jīng)常會改。如果能把兩者分離，開發(fā)和維護界面時綁著數(shù)據(jù)處理邏輯一起改，成本就低很多。

支持存儲過程的觀點認為，使用存儲過程能實現(xiàn)界面與邏輯分離。存儲過程在后臺數(shù)據(jù)庫中運算，只要向前端提供數(shù)據(jù)，而不必關(guān)心界面的形式和異動。把所有的數(shù)據(jù)處理邏輯都寫成存儲過程，還有利于統(tǒng)一數(shù)據(jù)的出入口，易于實現(xiàn)數(shù)據(jù)權(quán)限管控。

但是，仔細想想會發(fā)現(xiàn)，實現(xiàn)界面與邏輯分離并不是存儲過程的專利。只要做一個數(shù)據(jù)訪問層，所有數(shù)據(jù)的進出都通過這個訪問層，也會有同樣效果，事實上也確實有些應(yīng)用是這么做的，但并不普遍。這是什么原因呢？這樣的數(shù)據(jù)訪問層和采用存儲過程有什么區(qū)別呢？

差別在于開發(fā)復(fù)雜度上。

數(shù)據(jù)處理邏輯會經(jīng)常涉及到批量結(jié)構(gòu)化數(shù)據(jù)的處理，而數(shù)據(jù)庫之外的程序設(shè)計語言在這方面能力都很弱，用Java寫個數(shù)據(jù)求和都要很多行，更不要說過濾、分組之類的運算了。而存儲過程的基本部件是SQL，這方面支持得很好，雖然存儲過程也有開發(fā)調(diào)試困難的毛病，但大多數(shù)情況下用于編寫復(fù)雜的數(shù)據(jù)處理邏輯還是要比高級語言更容易。

換句話說，存儲過程確實利于界面與邏輯分離，不過存儲過程實現(xiàn)后臺數(shù)據(jù)邏輯的優(yōu)勢是SQL的集合運算能力支撐的。它主要來自于開發(fā)便捷，而不是應(yīng)用結(jié)構(gòu)。

有些場合無法利用存儲過程的計算能力，就只能實現(xiàn)庫外的數(shù)據(jù)訪問層了。比如數(shù)據(jù)來源涉及多數(shù)據(jù)庫或非數(shù)據(jù)庫的情況。

存儲過程利于界面與邏輯分離？

界面與邏輯分離的準則還有兩面性，它并沒有明確定義什么程序算是界面，更沒有說界面環(huán)節(jié)就不再有數(shù)據(jù)計算任務(wù)。

一個典型的任務(wù)就是報表。報表要在界面中呈現(xiàn)，其業(yè)務(wù)穩(wěn)定性也較弱，經(jīng)常增改，很顯然屬于界面環(huán)節(jié)的事務(wù)。但是，報表經(jīng)常卻有復(fù)雜的數(shù)據(jù)源計算過程，如果把這部分計算也作為后臺邏輯強行放進存儲過程中，則不僅不會獲得界面與邏輯分離的好處，反而帶來巨大的麻煩，這與網(wǎng)上許多推薦將復(fù)雜報表的計算過程中采用存儲過程的觀點正好相反。

報表的呈現(xiàn)模板一般是由報表工具繪制的，以文件形式存放在應(yīng)用中，如果數(shù)據(jù)源計算由存儲過程完成，則這兩個緊密相關(guān)的部分在物理上分別存放在兩處，要修改一張報表時需要兩個部分需要同步調(diào)整，不僅容易遺漏出錯，還可能增加溝通成本（兩部分的負責人員可能不同）。共享數(shù)據(jù)庫中的存儲過程還可能被其它報表甚至其它應(yīng)用調(diào)用，修改時就可能造成其它模塊的不正常。用存儲過程實現(xiàn)報表數(shù)據(jù)源會破壞應(yīng)用的模塊結(jié)構(gòu)，增大應(yīng)用的耦合度，造成維護成本升高。

采用存儲過程還會造成安全性和高效率的矛盾。原則上開發(fā)報表只需要對數(shù)據(jù)庫有只讀權(quán)限，但如果數(shù)據(jù)源是存儲過程開發(fā)的，則需要向報表開發(fā)人員開放編譯和運行存儲過程的權(quán)限，這幾乎可以對數(shù)據(jù)庫做一切操作了，安全隱患非常大。一個辦法是加強管理，所有上載的存儲過程都需要多人審核把關(guān)，但這勢必會導(dǎo)致低效率，本來報表開發(fā)人員自己就能完成的事情要涉及更多崗位。

如果有不依賴于數(shù)據(jù)庫的便捷計算能力，則可以避免掉存儲過程的這些劣勢。把業(yè)務(wù)穩(wěn)定性不強、與界面相關(guān)緊密的計算移到數(shù)據(jù)庫外，和應(yīng)用程序集成到一起，維護成本更低。即使業(yè)務(wù)穩(wěn)定性強的計算邏輯也可以用庫外計算實現(xiàn)，解決多數(shù)據(jù)庫、非數(shù)據(jù)庫等多樣性數(shù)據(jù)源的問題。不采用存儲過程的整體應(yīng)用結(jié)構(gòu)更為合理。

存儲過程有更好的數(shù)據(jù)計算性能？

實際測試表明，用存儲過程實現(xiàn)數(shù)據(jù)計算，常常比用SQL取出數(shù)據(jù)后在外部計算的性能更好。存儲過程快在哪里了？

網(wǎng)上有觀點說，因為存儲過程是預(yù)編譯的，而每次執(zhí)行SQL時要臨時編譯，所以存儲過程會更快。其實編譯SQL的那點時間相對于數(shù)據(jù)計算而言可以忽略不計，以不同參數(shù)反復(fù)執(zhí)行的SQL也可以預(yù)先準備，只要編譯一次。有些程序員把不同參數(shù)拼進SQL，每次向數(shù)據(jù)庫發(fā)送不同SQL，編譯時間就不可忽略了。

存儲過程的快，主要在于數(shù)據(jù)不出庫。外部程序訪問庫內(nèi)數(shù)據(jù)時必須通過數(shù)據(jù)庫提供的接口，而這些接口的性能大都不好，特別是面向Java程序的JDBC接口。每次發(fā)出SQL讓數(shù)據(jù)庫執(zhí)行都會調(diào)用這個接口，速度就上不去。如果應(yīng)用程序和數(shù)據(jù)庫不在同一臺物理機器上時，還會有一些網(wǎng)絡(luò)延遲，不過和接口的低性能相比并不算嚴重。在外部計算時，從數(shù)據(jù)庫獲取數(shù)據(jù)的時間常常會超過計算本身的時間。

存儲過程本身的執(zhí)行性能并不好。我們針對某著名商用數(shù)據(jù)庫進行過測試：一句SQL可以完成的運算（比如對某個大表的字段求和），如果改用存儲過程把數(shù)據(jù)一行行取出來計算，差不多會慢出一個數(shù)量級。用Java等語言從文件系統(tǒng)中讀數(shù)做同樣的計算，也會比存儲過程快很多；外部計算相對容易寫出并行代碼，充分利用現(xiàn)代服務(wù)器多CPU的優(yōu)勢，存儲過程一般都沒有這個機制了。而且，如果把很多計算都放到存儲過程中，并發(fā)運算時會加重數(shù)據(jù)庫的負擔，使本來就不快的存儲過程更慢。

存儲過程的性能更好，與其說是優(yōu)勢，倒不如說是被低效的數(shù)據(jù)庫訪問接口綁架所致。

目前業(yè)內(nèi)還只有關(guān)系數(shù)據(jù)庫有較好的交易一致性能力，適合充當OLTP業(yè)務(wù)的后臺，這樣從前端采集到的數(shù)據(jù)會直接進入關(guān)系數(shù)據(jù)庫，這導(dǎo)致原始數(shù)據(jù)大量存儲于數(shù)據(jù)庫中。如果要對這些數(shù)據(jù)進行計算，采用外部計算方案時，取出數(shù)據(jù)太慢，總體性能就會很差；而使用存儲過程，雖然計算本身不快，但數(shù)據(jù)不出庫也會獲得較好性能。這是存儲過程不能被完全替代的主要原因和場景。

蔣步星，清華大學計算機碩士，著有《非線性報表模型原理》等

1989年中國國際奧林匹克數(shù)學競賽團體冠軍成員，個人金牌。

2000年創(chuàng)立潤乾公司，首次在潤乾報表中提出非線性報表模型，完美解決了中國式復(fù)雜報表制表難題，目前該模型已經(jīng)成為報表行業(yè)的標準。

2008年開始研發(fā)不依賴關(guān)系型數(shù)據(jù)的計算引擎，歷經(jīng)多個版本后，于2014年集算器正式發(fā)布。有效地提高了復(fù)雜結(jié)構(gòu)化大數(shù)據(jù)計算的開發(fā)速度和運算效率。

2016年榮獲中國電子信息產(chǎn)業(yè)發(fā)展研究院評選的“2016年中國軟件和信息服務(wù)業(yè) ? 十大領(lǐng)軍人物”。

2017年將帶領(lǐng)潤乾軟件朝著擁有自主產(chǎn)權(quán)的非關(guān)系型強計算數(shù)據(jù)倉庫、云數(shù)據(jù)庫等產(chǎn)品邁進。