應用適配資料庫還是資料庫適配應用

這個題目有點拗口，和最近有些話題有點關係，但是更多的還是我作為這些年過來的一些矛盾的闡述。

從前有個笑話。一隊軍艦在水域巡航，這天晚上大霧。軍艦看看到前方有燈光，立刻發出“海軍燈語”。請立即讓開。對方也給這艘軍艦發出燈語，請你繞開。軍艦不服，打出燈語：“我是旗艦，你必須要讓我先透過。”對只回應說：“你讓開，我是燈塔。我在這裡已經很久了，我為所有的船隻提供導航服務。沒有我，很多船隻都會撞到礁石上。”這個笑話利用了“旗艦”和“燈塔”這兩個詞的雙關含義。在海軍中，“旗艦”是指一艘指揮艦，所有軍艦要服從我，而在航海中，“燈塔”是一種為船隻提供導航指示的人工光源。因此，這個笑話的幽默之處在於軍艦和燈塔都認為自己的地位更重要，不願意讓對方先透過。

工作過一些公司和行業。有些公司是意識到應用開發(這裡指後端的)是幾乎全部圍繞著資料庫展開的。這裡的資料庫泛指關係型資料庫和NoSQL等資料庫。(很多人不把Redis、ELasticSearch、MongoDB等當做資料庫，不知道誰給灌輸的概念。可悲)。

也有一些公司從上到下沒有意識到這一點，領導覺得資料庫不重要，開發最重要。其實不少都是框架完成的，有些變數都是抄來的改一改，甚至改都不改拿來就用。我有時候做一些演示的時候就利用了這種方式。我也是透過這種學習發現後端程式中50%以上，甚至應用程式中80%是SQL。可以說主體是SQL。

也有一些公司開發人員覺得自己最大。物件導向程式設計而不是面向資料庫程式設計，資料庫應該圍繞著物件來。

凡是都是從不同角度出發，在我的角度我覺得我是對的。站在開發人員和領導層面覺得他們的認知中他們是對的。那麼只能講幾個事情來看看了。

事件1：在工作中引入專業的資料庫建模工具。在資料庫標準制定和建模過程中，發現模型分為業務模型、邏輯模型和物理模型。而這一切與物件導向程式設計不衝突。業務從需求設計開始就是要確定好，最終是透過邏輯模型對映到物理模型上(即資料庫表和欄位)。也就是說即使物件導向程式設計還是以資料庫為核心的。

事件2：某公司國產化要求。第三方服務商對資料庫遷移的專案報價，預計成本幾十萬(在100萬以內)，隨後應用開發方報價(應用程式改寫)成本幾千萬(一億以內)。從這個上面來說，資料遷移好做，應用改寫難做。用現在一句話說叫國產適配改造。從這句話上就可以看出，是應用程式去適配資料庫，不是資料庫來適配應用程式。

事件3：說到資料庫相容性。前幾天有文章說相容Oracle程度比較高的是達夢和OceanBase。可能從這個角度是資料庫適配應用。因為出發點是說最好應用程式不改變，而完成了替換。可能有人會說這就是資料庫適配應用。確實表面上是的。這種相容的特點就是原來應用程式(中的SQL)在新的資料庫上不報錯。這就是相容性。那麼這裡請思考一個這樣的問題，那就是SQL不報錯了。那麼效能是不是一模一樣。這時候幾乎所有的人都回答我說，怎麼可能還是不一樣的。那麼問題來了，語法不報錯。為了效能可能要做一些SQL改寫(能改寫好的算運氣好的了)，那這個改寫的算不算對新資料庫的適配改造呢?我覺得算。運氣不好的那就大改特改了，甚至是重構。網上有一篇文章，是陸金所去O的。從2015年開始說了好幾年。大家可以去網上查原文。說她們用MySQL替代(儘管不少業內人說用MySQL去替代Oracle，能叫替換嗎?這兩個是一家啊)。替換完成後85%的場景都是改為單表查詢。也就是說深度物件導向了，而且也結合新的資料庫全面適配了。花了好幾年，錢花了也不少。這個在網上都能查得到。感興趣的自己去查。 對於一般的傳統企業來說如果也這樣，那麼當初資訊化建設花了多少錢，現在就要再花一次。而且可能花的還要多。因為5年前的人工和現在的人工不一樣了。我就估算我司要是全重做一遍怎麼也要上億的開發人工投入。

事件4：一般的資料庫單表都不是問題。越多關聯可能就不行。做資料庫的都知道和最佳化器、執行器等等都有關。那麼基於陸金所那種改造，從邏輯模型和物理模型都徹底推翻的重構，已經不能用傷筋動骨來說了，就是涅槃重生。那麼諸位都知道讓開發最佳化SQL勢比登天的日常工作來說，讓開發人員把祖傳程式碼重第一行開始寫起來，不亞於殺人父母了。這種時候面對幾百上千的開發，能不能頂得住?關鍵這個時候還居然要考核你穩定性。如果不考核穩定性，就不會這麼矛盾。開發不改了，當機就當機。矛盾就沒有了。替換就容易多了。

透過以上我覺得我說明白了是誰適配誰。在我這個角度而言資料庫是“燈塔”，無論那種資料庫都是。

資料庫本身是數學和物理學的結合。你看看最佳化器和統計資訊就知道了。肉眼可見的統計學本身就是數學的一個分支，最佳化器的演算法不太可見。而CPU磁碟這些都是基礎物理的範疇，當然資料庫還涉及到網路。對了分散式資料庫的raft和Paoxs也是演算法。說這麼多，不重視的還是不重視。覺得切換一個資料庫過來就是資料匯出匯入的也是大有人在。只要不要穩定性，怎麼來都行啊，DBA們是沒有太大問題的。多學一個資料庫體系而已。只要不要穩定性，怎麼來都行，開發人員只要不讓他把自己和前幾任寫的程式碼都重新寫一遍也沒有多大的問題的。

但是資料庫"燈塔"的存在不是以人的主觀為轉移的。要不?撞一下試試?