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

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

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

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

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

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

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

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

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