資料庫移植性 移植什麼？

有個同行跟我說，他們家的系統移植性很棒，DB2, Oracle, MS SQL每個資料庫都可以搭

我心裡在說，那是你沒碰上要一秒內要處理上百萬上千萬筆資料的狀況，沒碰上那種連IBM大暴龍都搞不定的運算，等再過五年，你再來說說這話。

實際上，你就是會碰上這種操資料庫，就是會碰上需要那種需要某牌資料庫特異功能的應用，碰上這種東西，資料庫移植性，就變成一句笑話。

讓我們面對現實吧，鳥托邦並不存在，我們不能保證完美的資料庫移植性。我們應該要考慮的是，我的系統要支援幾個資料庫?　為什麼? 通常，考慮的因素是


一、商業的需求
客戶已經講的很清楚，他們家就是用DB2 Oracle，維護人員受的訓也都是DB2, Oracle。如果你不用，那最好你們家的系統強悍無比，Domain knowledge比客戶還精，客戶不找你不行，要不然，接不到案子不要怪別人。

二、功能的需求
如果客戶熟悉的資料庫，功能不符合你系統的需求。像是你就是需要某牌資料庫的特異功能，才能把他要的功能或報表跑出來，那你可以堅持，要不然，還是別太鐵齒。

三、預算的需求
這就更簡單了，付錢的是老大，老大要什麼，我們就給什麼。如果老大沒錢，那更簡單，我們就是老大，就用PostgreSQL吧，畢竟系統原生就是在PostgreSQL環境發展的。

資料庫移植性，這其實是一個角力的問題，其實終端客戶才不管你用什麼資料庫，只是有時候你需要去符合客戶IT部門的某些政策，某些規定。碰上這種東西，我都是叫業務先去談上線，再談移植計劃。先把系統裝進去，符合客戶的需求，終端客戶用上手了，我們再來談資料庫移植。

而在大多的的狀況下，移植資料庫要花時間改程式，要花時間測試，更重要的，是終端客戶也要花時間確認沒有問題，客戶會願意花時間去做這些沒用的功嗎？有這些時間，不如幫他多寫一隻新功能，滿足他一個新需求，資料庫移植這件事，自然就無疾而終了。

但是，這種作法，有時候也會碰上鐵板，特別是在應用很成熟的領域裡。在月度工作會議裡，終端客戶的部門沒有新需求提出，IT部門就會把這件事拉出來講。我的作法是，就配合嘛，反正這領域沒有新功能好寫了，那就排進度做移植，擴充支援的資料庫，也是增強這個產品線的競爭力，要不然，客戶簽維護是讓我們大眼看小眼嗎? 總要有個交待吧，是吧 !!