說多了都是淚--由開發自主選型

     最近有些好學的同事向我諮詢資料庫選型，我覺得這是好事。最起碼問專業的人，比起自以為懂資料庫的開發來選擇要好的多。我從使用場景、資料量、最佳化器以及單體還是分散式等等很多角度來說明各種資料庫的選擇。這年頭資料庫鋪天蓋地，尤其是國產資料庫（有幾個優秀的，但是大部分不怎麼優秀）。這種情況下，開發質量不高的程式，可能在Oracle DB2這樣的資料庫上能執行良好的，在MySQL等開源上執行的就不行了。我上週剛處理了一個這樣的案例。這幾年不少去O，但是沒人提去DB2和SQLSERVER，被去掉了嗎？可能因為O是第一，都想打贏第一。其他的資料庫說考慮一下我的感受。來打我呀。

     我之前也有一個案例，在MySQL上執行很好的，但是到了國產上就GG了。感興趣的請往前找找。所以換國產要大量的適配，比如改寫、比如重新設計、甚至必要時候推到了重來。這是極有可能的。具體如何選，做資料庫的人最知道。開發基本不知道資料庫有多少坑，因為即使Oracle MySQL這樣的一般開發人員也未必都知道應該怎麼做。即使從Oracle到MySQL上，碰的頭破血流的也有的是。當然其實任意兩種資料庫切換都是帶來各式各樣的問題。

    今天還遇到一件事，看到開發同學要清理表，問問為什麼？說這些表是記錄分散式資料的。重點是整個系統就一個資料庫，單例項資料。採用了分散式。這在做資料庫的人角度是玩命的不理解啊！ 單例項資料庫用毛分散式事務？答覆是服務拆分為了資料庫的一致性。比如甲向乙轉賬的場景，甲的扣款服務和乙得到收款服務兩個要一致。    聽到這裡但凡做過資料庫的人都想哭了吧？

    因為在幾十年前ACID的基礎就告訴我們，資料庫就是要把這兩個操作放在一個事務中來保證一致性。而如今微服務的居然把他們拆開，要用其他的來保證。（就實際情況而言，看上去沒保證，所以後臺要做處理）。我一向認為微服務的最小單元是事務，而不是SQL。也不知道現在為什麼都這樣來做？來打個比方吧。本來我們喝水小便都不用我們操心，生下來就自主完成的。現在做了一件事就是從胃接一個管子出來，到一個瓶子，再從瓶子接一個管子到膀胱。（例子有點不雅，但是事情就這麼個事情。是不是感覺多此一舉？）

    這種事情太多了，從A資料庫到B資料庫，方法很多可以用CDC，也可以做程式從A拿資料搬遷到B等等。但是現在不少人會設計一個程式M從A中拿資料到訊息佇列，再做一個程式N從訊息佇列中拿資料到B。你看事情總是相似的。