數據庫已死(網友觀點)

我不同意什麼“數據庫已死”的說法，但我也不同意在系統設計階段就讓設計數據庫的工作摻和進來，我想這也是樓主想說的。

我不止一次地在項目中聽到人說：“幹嘛折騰什麼業務邏輯的設計，把數據庫設計好了，你想顯示什麼，一個sql語句就能搞定。”說這話的人大概沒有想過：“幹嘛折騰什麼高級語言，把彙編學好了，什麼軟件編不出來。”很多時候，數據庫的結構設計好了，並不能表示完成系統設計也指日可待了。若在設計階段就輕視業務邏輯層面上的面向對象的設計，後續的工作將舉步維艱。

舉個真實的例子，很多購物系統都會有“order”這麼個東西，系統或大或小，或簡或繁，但是設計數據表是很輕鬆的：“分析order從哪來，到哪去，就知道了它需要哪些字段，然後再加上一些額外的字段作爲備用，這樣不管它將來怎麼變，總該萬變不離其宗吧！”

數據表都有了，當然該寫程序了。當功能即將完工時，客戶提出，有些訂單項，當它跟另一個訂單項在一起時，是可以自動作爲贈品的；有一些商品需要捆綁銷售，order要打個折扣。

Leader（或者項目經理）覺得這種變更不會影響到數據表，改起來應該很容易，但真正改起來，卻牽一髮而動全身：系統到處冒bug和exception，程序員的頭上也差點要冒煙。

好不容易改好了，客戶看完又提出，order可以有多個發貨地址。多簡單的一句話啊，可是觸碰到數據表的修改了，不用說，又是一陣捉蟲的惡戰。

後來客戶又提出，order可以用打折碼來打折，可以用禮券來抵價……面對這種屢次三番的修改，以數據庫設計爲出發點的系統，穩定性能怎樣？而一個購物系統的order處理都不穩定，又有誰敢用呢？

這就是重數據庫設計，輕對象設計的惡果，因爲僅憑數據表和E-R圖，很難考慮到對象繼承、多態等基本的代碼重用設計，更別說設計模式了。我敢說，每天都有軟件公司、開發團隊發生這樣的事。而千萬不要說爲什麼一開始不把需求弄清楚，因爲需求的變化是永遠存在的。

這樣說，豈不是軟件開發做不下去了？其實不然，GOF的設計模式就能夠很好地面對這些變化，設計模式最強大的地方就是，它雖然不能告訴你需求會怎樣變，但它總能夠給變化留下空間，讓變更的過渡更加容易。

實際上，做應用軟件的，就應該以面向對象的系統設計爲主，數據庫的設計隨後跟上。如果有疑問，那麼可以想象一下這樣的情形：

假設Amazon提供一個數據持久化的服務，不管你使用什麼語言，只要你把對象傳給它，它就能給你存起來，下次你取出來，還能照樣用。這樣你就不用管數據庫的設計了，想管也管不了了，就可以專心去做面向對象的設計了。經歷了若干次的變動和修改，你的軟件交付了。直到有一天，Amazon告訴你，其實它們一直是用Mysql存儲你的數據的。它們給你一個數據庫的備份和一個ORM層的實現，就不用連接它的服務器了。那麼各位你一定不會覺得難辦，因爲你的面向對象的系統設計已是完好的，更換的只是一個存儲對象數據的地方而已。

所以我認爲，從數據庫爲主線的系統設計，是有弊端的，重點應該是業務邏輯層的面向對象的設計。但數據庫設計也並非不重要，它的表結構的優化，性能的優化，應該在整個軟件的生命週期內，持續地進行。