引言:一直在從事資料庫開發和設計工作,也看了一些書籍,算是略有心得。很久之前就想針對關聯式資料庫設計進行整理、總結,但因為種種原因遲遲沒有動手,主要還是惰性使然。今天也算是痛下決心開始這項卓絕又令我興奮的工作。這將是一個系列的文章,我將以講座式的口吻展開討論個人偷懶,這裡的總結直接拿去公司培訓新人用)。
系列的第一講我們先來回答下面幾個問題:
資料庫是大樓的根基
大多數程式員都很急切,在瞭解基本需求之後希望很快的進入到編碼階段可能只有產出代碼才能反映工作量),對於資料庫設計思考得比較少。
這給系統留下了許多隱患。許多軟體系統的問題,如:輸出錯誤的資料,效能差或後期維護繁雜等,都與前期資料庫設計有著密切的關係。到了這個時候再想修改資料庫設計或進行最佳化等同於推翻重來。
我經常把軟體開發比作汽車製造。汽車製造會經過圖紙設計,模型製作,樣車製造,小批量試生產,最後是批量生產等步驟。整個過程環環相扣,後一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏,我們可以重新進行圖紙設計,如果到了樣車製造階段發現這個錯誤,那麼我們就要把從圖紙設計到樣車製造的階段重來,越到後面發現設計上的問題,所付出的代價越大,修改的難度也越大。
資料庫是整個應用的根基,沒有堅實的根基,整個應用也就岌岌可危了。
強大的資料庫面對不良設計也無能為力
現代資料庫管理系統DBMS)提供了方便的圖形化介面工具,通過這些工具可以很方便的建立表、定義列,但我們設計出的結構好嗎?
關聯式資料庫有許多非常好的特性,但設計不當會使這些特性部分或完全的喪失。
我們來看看以下幾個資料庫不良設計造成的情境:
1. 資料一致性的喪失
一個訂單管理系統,維護著客戶和客戶下的訂單資訊。使用該系統的使用者在接到客戶修改收貨地址的電話後,在系統的客戶資訊頁面把該客戶的收貨地址進行了修改,但原先該客戶的訂單還是送錯了地址。
2. 資料完整性的喪失
公司戰略轉移,準備撤出某地區。系統操作人員順手把該地區的配置資訊在系統中進行刪除,系統提示刪除成功。隨後問題就來了,客服人員發現該地區的曆史訂單頁面一開啟就出錯。
3. 效能的喪失
一個庫存管理系統,倉庫管理員使用該系統記錄每一筆進出貨情況,並能查看當前各貨物的庫存情況。在系統運行幾個月後,倉庫管理員發現開啟當前庫存頁面變得非常慢,而且整個趨勢是越來越慢。
上面這些情境都是由於資料庫設計不當造成的,根源包括:設計時引入了冗餘欄位,沒有設計合理的約束,對效能沒有進行充足設計等,上面的例子也只是滄海一粟。