存儲過程移植困難是經(jīng)常被詬病的，在羅列存儲過程的缺點時，這一條幾乎從來不會被遺漏。

存儲過程的移植確實很困難，一般業(yè)務(wù)邏輯復(fù)雜到需要寫存儲過程的地步，總會不可避免地用到數(shù)據(jù)庫獨有的特性和語法，更換數(shù)據(jù)庫時這部分代碼就需要重寫。如果只是簡單地替換函數(shù)名和參數(shù)規(guī)則(如日期轉(zhuǎn)換等)，那成本還不高;如果用到了新數(shù)據(jù)庫不支持的某種特性(如窗口函數(shù))，那還要重新設(shè)計算法來編寫計算邏輯;如果還要再兼顧性能因素，有時候就會是個不可能完成的任務(wù)了。

不過，還好，存儲過程移植的情況并不頻繁。

多年前數(shù)據(jù)庫市場還處于混戰(zhàn)階段時，用戶更換數(shù)據(jù)庫是相對常見的事情。而如今，傳統(tǒng)關(guān)系數(shù)據(jù)庫市場的競爭已經(jīng)趨于穩(wěn)定，各個行業(yè)和業(yè)務(wù)采用的數(shù)據(jù)庫已經(jīng)基本定型。更換數(shù)據(jù)庫并不只是存儲過程移植這么一件事，用戶從使用習(xí)慣到維護人員配備等各方面都要做出很深刻的改變，這是個成本巨大的工程。如果沒有重大事件，一般不會發(fā)生數(shù)據(jù)庫移植的事件。存儲過程移植雖然困難，但并不足以成為不采用它的重要理由。

至于需要面對各種行業(yè)不同用戶的通用BI類軟件，雖然經(jīng)常要接入不同的數(shù)據(jù)庫，但很少會用到存儲過程，只是些SQL函數(shù)更換，就沒有難度了。

其實，仔細研究一下會發(fā)現(xiàn)。存儲過程的移植困難主要發(fā)生于從商用數(shù)據(jù)庫到開源數(shù)據(jù)庫(包括一些近年來興起的一些基于大數(shù)據(jù)平臺的數(shù)據(jù)倉庫)的切換過程。同價位的商用數(shù)據(jù)庫之間的移植難度并不是很大，而從開源數(shù)據(jù)庫到商用數(shù)據(jù)庫則更是容易(雖然這種現(xiàn)象發(fā)生較少)。

如前所述，存儲過程在數(shù)據(jù)庫之間的移植難度，語法不同只是個載體，更深層次的原因在于各個數(shù)據(jù)庫的功能特性不同。同價位的商用數(shù)據(jù)庫，其功能相差并不大，移植時主要就是更換語法，難度就不會很大。而開源數(shù)據(jù)庫在功能方面和成熟的商用數(shù)據(jù)庫相差很遠，雖然大家都叫數(shù)據(jù)庫，都能跑基本SQL，但差別是巨大的，從許多關(guān)鍵的特性上看根本就是兩個不同的產(chǎn)品。比如世界上***的那個商用數(shù)據(jù)庫，對SQL2003的標(biāo)準(zhǔn)支持得很好，有較完整的窗口函數(shù);而世界上那個***的那個開源數(shù)據(jù)庫，別說窗口函數(shù)，連FULL JOIN都要轉(zhuǎn)換成UNION來做。這時候想移植存儲過程，那就是相當(dāng)于完全重新開發(fā)。這個困難根本就不是移植造成的，如果當(dāng)初選擇開源數(shù)據(jù)庫建設(shè)應(yīng)用，那困難一樣的大。

我們說移植成本，是指基于兩個能力基本相當(dāng)?shù)钠脚_，最初的開發(fā)工作無論基于哪個平臺，復(fù)雜度是差不太多的。比如一段C++程序，在Windows上寫和在Linux上寫，難度區(qū)別并不大，這時候討論移植工作量才有意義;但要把一段Java程序轉(zhuǎn)換成C++程序，這就不是個移植問題了，初始的開發(fā)復(fù)雜度就相差巨大。從商用數(shù)據(jù)庫到開源數(shù)據(jù)庫的遷移大抵類似于這種。

目前，從商用數(shù)據(jù)庫切換到開源數(shù)據(jù)庫或大數(shù)據(jù)平臺是一個業(yè)內(nèi)趨勢，這樣做在數(shù)據(jù)庫建設(shè)成本上會下降許多。不過這個世界是公平的，購置數(shù)據(jù)庫的成本下降了，而這并不是技術(shù)進步帶來的結(jié)果，那就從開發(fā)成本上找補回來吧。