後端開發中關聯式資料庫的開發管理新思路

在工作上遇到的各類開發需求中，只要涉及到後端功能，關聯式資料庫的使用幾乎不可避免。雖說有各類NoSQL產品競爭和補充，但是它們沒法完全替代關聯式資料庫，實際上也很難替代。各項技術，各有各的優點和長處。我這裡提出一個經過實踐檢驗總結出來的新的資料庫開發、管理思路。也許早已經有人採用這個思路和辦法，這裡的新是對我而言。

大量的開發者使用關聯式資料庫都會遇到一個痛點：“阻抗不匹配”。（阻抗不匹配：指持久化儲存資料所採用的資料模型與編寫程式時所採用的資料模型有差異。）因為資料庫使用標準的SQL語言操縱資料，而連線運算元據庫的語言則五花八門，語言特性差別很大。這裡面讓人頭疼的地方是：不管你是什麼用語言開發，運算元據庫都必須使用SQL語言，你需要把語言的資料及操作，對映到資料庫；此外，敏捷思維下迭代開發很多，特別是前期，資料庫表、檢視結構的設計並不是穩定的，也經常隨著需求變化，時不時的都要修改表結構、欄位屬性，同時再同步修改對它的操作過程。

對於運算元據庫的語言匹配問題，社群開發出各種語言內的ORM系統，試圖用本語言自己的物件及操作方法，自動的轉化為對資料庫的操作呼叫。這種模式發展的還算比較成功，Python/PHP/Java等語言，主流開發框架都有自己的ORM實現。除了個別特殊情況，現在幾乎已經沒人在開發框架內手寫拼接SQL語句查詢了。如果有，你需要立刻反思下自己的資料庫Model設計是否不夠合理，以及是否沒有了解掌握語言框架的ORM系統。使用ORM系統優點多多，方便安全，這是首選方法。

另外一個問題，目前看，似乎還沒有標準、成熟的解決方式。恐怕大部分人還是開發的時候，利用資料庫客戶端工具，手工設計、修改資料庫結構，處理各種資料庫表，再跟自己的程式聯調。後面需求變更，再繼續修改資料庫和程式，迴圈往復。即便藉助工具設計操作，也沒擺脫資料庫客戶端，也是手工的一類。

這樣的實踐過程，是比較低階的，對資料庫的變更操作往往缺乏記錄和管理。另外還需要開發者時不時的切換到SQL模式，使用它的規則來行動。這是一種心智負擔。你的關注點是分散的，需要同時關注資料庫的設計變更和開發中操作的變化。另外，開發過程往往是線上、測試兩套資料庫隔離，等開發出新版系統要部署上線，還需要對已有的資料庫進行修改變更，這個可不是簡單的輸出測試資料庫的表結構安裝覆蓋就能解決的了。線上的庫裡面可是有資料的呀！出現一點差錯都不可接受。手工操作的弊端和風險是很大的。

有的朋友可能會提到：是否可以使用儲存過程去遮蔽資料庫的結構變化？這個問題在這篇文章裡面有詳細的討論，可以參考：http://davidwaynebaxter.com/2013/10/28/orm-or-sprocs/

對於這個事情，我經過研究發現，業界著名的Python 語言Web開發框架 – Django的解決模式很不錯，值得學習研究和借鑑。

後端功能，並不一定是以Web形式存在。但是Web開發的飛速發展，業界積累了大量的開發經驗，開發出十分出眾的框架和配套工具。所以，開發者如果技術全面，這裡優點又體現出來了：“他山之石，可以攻玉”。你完全可以使用Web開發的框架/工具，來管理自己的關聯式資料庫，而並不需要開發Web的應用。即使需要也並不困難。

Django的思路是這樣的：它使用Python語言的物件型別，模擬資料庫表結構和關係。它使用ORM運算元據庫，又通過定義“遷移”的過程，管理表結構和關係的變化。只要你按照它的設計思路一直演進開發，它就能保證線上的庫也能按線下的測試庫一樣，得到正確的修改和變化。

你需要做的工作就是定義好應用裡面的Model – 它代表一個資料庫的表。當你需要修改資料庫的時候，不要去用客戶端工具修改MySQL這些資料庫，而是修改Django裡面的Model。你對Model的更改 – 增刪欄位、變更欄位的屬性等等，Django會在遷移操作中進行記錄並自動執行資料庫的修改。這樣，你的關注點就只有一個了。Django定義了一個makemigrations操作，自動掃描各應用中Model的狀態，與實際資料庫的差異並記錄下來。然後在後面的migrate操作中，執行修改行為，這樣線下線上的對映關係，就自動的保持一致了。Django會自動的儲存所有變更記錄，可以放在Git裡面管理。而且，你的Model就是ORM操作中使用的物件，完全不存在程式碼重複和管理麻煩的問題。

這個設計思路十分的優秀，非常合理。經過我的使用驗證，非常的好用方便。反觀另外一大Web開發陣營：PHP語言的框架則沒有這種思路的實現。它們也有所謂的“遷移”定義和工具，可是它們的操作是反的，執行的是從線上資料庫表對映到框架內的Model或者某種檔案的表示。如果你更改模型，並不能如同Django一般，簡單的對映到線上表示，自動同步，還需要自己編寫變更指令碼。如果誰知道哪個優秀的PHP框架做到了，煩請通告。Java陣營貌似有工具也可以幹這個事情，不過用的少，沒仔細研究。順便說一句，Django框架真的很棒，文件優秀，社群繁榮，效能也不錯，技術選型中需要的時候值得大力推薦。不同的陣營，設計出現這種差別，不知道是否是語言實現的原因，按道理大家都是相互學習借鑑的呀。Python語言天然的適合這種對映的表示，使用Django系統中的Python物件來表達資料庫表，真的是太容易、太方便了。而且Django把Model的表示內容單獨抽離，設計的結構很理想。

所以，如果你使用的框架無法做到從Model自動對映、同步到資料庫表結構，而你能操縱Python陣營的系統，在覺得成本合理的情況下，完全可以單獨建立一個Django工程來管理資料庫，而不必實現其Web功能，需要的時候也真的不難。同時，可以讓你採用的語言框架、系統，用工具從線上再同步回來，由Table對映到Model，這樣變更就容易的多了。等你的系統上線的時候，就會明白，有專業的系統管理是多麼好的一件事了，一條命令就實現了線上的資料庫變更操作。

下面給出一些參考連結，有興趣的朋友們可以繼續研究研究。更好的開發模式可以有效的提升產品質量和開發效率，所以，我對於尋找更好的方法從來都是樂此不疲的。

MyBatis Migrations：http://www.mybatis.org/migrations/index.html Flyway：https://flywaydb.org/documentation/ Phinx Migrations：https://book.cakephp.org/3.0/en/phinx.html Django Migrations：https://docs.djangoproject.com/en/2.0/topics/migrations/

作者部落格