一步一步設計你的數據庫之數據庫設計的重要性
引言：一直在從事數據庫開發和設計工作，也看了一些書籍，算是略有心得。很久之前就想針對關系數據庫設計進行整理、總結，但因為種種原因遲遲沒有動手，主要還是惰性使然。今天也算是痛下決心開始這項卓絕又令我興奮的工作。這將是一個系列的文章，我將以講座式的口吻展開討論（個人偷懶，這里的總結直接拿去公司培訓新人用）。
系列的第一講我們先來回答下面幾個問題：
數據庫是大樓的根基
大多數程序員都很急切，在了解基本需求之后希望很快的進入到編碼階段（可能只有產出代碼才能反映工作量），對于數據庫設計思考得比較少。
這給系統留下了許多隱患。許多軟件系統的問題，如：輸出錯誤的數據，性能差或后期維護繁雜等，都與前期數據庫設計有著密切的關系。到了這個時候再想修改數據庫設計或進行優化等同于推翻重來。
我經常把軟件開發比作汽車制造。汽車制造會經過圖紙設計，模型制作，樣車制造，小批量試生產，最后是批量生產等步驟。整個過程環環相扣，后一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏，我們可以重新進行圖紙設計，如果到了樣車制造階段發現這個錯誤，那么我們就要把從圖紙設計到樣車制造的階段重來，越到后面發現設計上的問題，所付出的代價越大，修改的難度也越大。
數據庫是整個應用的根基，沒有堅實的根基，整個應用也就岌岌可危了。
強大的數據庫面對不良設計也無能為力
現代數據庫管理系統（DBMS）提供了方便的圖形化界面工具，通過這些工具可以很方便的創建表、定義列，但我們設計出的結構好嗎？
關系數據庫有許多非常好的特性，但設計不當會使這些特性部分或完全的喪失。
我們來看看以下幾個數據庫不良設計造成的場景：
1. 數據一致性的喪失
一個訂單管理系統，維護著客戶和客戶下的訂單信息。使用該系統的用戶在接到客戶修改收貨地址的電話后，在系統的客戶信息頁面把該客戶的收貨地址進行了修改，但原先該客戶的訂單還是送錯了地址。
2. 數據完整性的喪失
公司戰略轉移，準備撤出某地區。系統操作人員順手把該地區的配置信息在系統中進行刪除，系統提示刪除成功。隨后問題就來了，客服人員發現該地區的歷史訂單頁面一打開就出錯。
3. 性能的喪失
一個庫存管理系統，倉庫管理員使用該系統記錄每一筆進出貨情況，并能查看當前各貨物的庫存情況。在系統運行幾個月后，倉庫管理員發現打開當前庫存頁面變得非常慢，而且整個趨勢是越來越慢。
上面這些場景都是由于數據庫設計不當造成的，根源包括：設計時引入了冗余字段，沒有設計合理的約束，對性能沒有進行充足設計等，上面的例子也只是滄海一粟。
#p#
數據庫平臺無關性
我在這個系列博客里討論的數據庫設計不針對任何一個關系數據庫產品。無論你使用的是Oracle，SQL Server，Sybase，亦或是開源數據庫如：MySQL，SQLite等，都可以用來實踐我們這里討論的設計方法和設計理念，設計是這個系列博文的核心和靈魂。
注：在文中我會選用一個數據庫產品來進行演示，大家可以選用自己熟悉的數據庫產品來實驗。本文最后會給出一些免費數據庫產品的鏈接，大家可以下載學習。
一起學習共同進步
無論你是數據庫設計師，應用架構師，軟件工程師，數據庫管理員（DBA），軟件項目經理，軟件測試工程師等項目組成員，都能從該系列博文中有所收獲。大家一起討論，共同進步。
內容涉及領域
我對這一系列博文現在的設想是涉及數據庫設計的整個過程。從需求分析開始，到數據庫建模（概念數據建模），進行范式化，直至轉化為SQL語句。
#p#
在我們一頭扎進數據庫設計之前，我們先了解一下除了關系型數據庫之外的數據存儲方式。
平面文件（Flat File）
包括以.txt和.ini結尾的文件。
eg: 一個.ini文件的內容：
- [WebSites]
- MyBlog=http://www.cnblogs.com/DBFocus
- [Directorys]
- Image=E:\DBFocus Project\Img
- Text=E:\DBFocus Project\Documents
- Data=E:\DBFocus Project\DB
優點：
文件的存儲形式非常簡單，普通的編輯器都能對其進行打開、修改
缺點：
無法支持復雜的查詢
沒有任何驗證功能
對平面文件中間的內容進行插入、刪除操作其實是重新生成了一個新文件
適用場景：
存放小量，修改不頻繁的數據，如應用配置信息
Windows注冊表
錯誤的修改Windows注冊表會引起系統的紊亂，故不建議把很多數據存放在注冊表中。
Windows注冊表為樹形結構，存放著一些系統配置信息和應用配置信息。
通過把不同的配置存放在注冊表的不同分支上，使得應用程序公共配置信息與用戶個人配置信息分離。
eg：某文檔版本管理系統，能通過配置與本主機上安裝的文件比較器建立關聯進行文檔比較。這是一個公共配置信息，文件比較器路徑可以存放在注冊表的HKEY_LOCAL_MACHINE\SOFTWARE分支下。
同時該文檔版本管理系統能記錄用戶最近打開的10個文檔路徑。這是用戶個人配置信息，對于不同的Windows用戶最近打開的10個文檔可以不同，這些配置信息可存放在注冊表的HKEY_CURRENT_USER\Software分支下。
Excel表單（Spreadsheets）
優點：
Excel 非常普及，用戶對于Spreadsheet的表現形式非常熟悉
可以進行簡單統計，方便出各種圖表
缺點：
不適用于許多Spreadsheet之間關系復雜的情況
無法應對復雜查詢
數據驗證功能弱
適用場景：
數據量不是非常大的辦公自動化環境
XML
XML是一種半結構化的數據。相比于超文本標記語言（HTML），其標簽是可以自行定義的，即可擴展的。
eg：一個XML文件內容
-----------------------------------------------------
- <?xml version=”1.0” encoding=”UTF-8” ?>
- <ClassSchedule>
- <Class Name=“Psychology” Room=”Field 3”>
- <Instructor>Richard Storm</Instructor>
- <Students>
- <Student>
- <FirstName>Ben</FirstName>
- <LastName>Breaker</LastName>
- </Student>
- <Student>
- <FirstName>Carol</FirstName>
- <LastName>Enflame</LastName>
- <NickName>Candy</NichName>
- </Students>
- </Class>
- </ClassSchedule>
-----------------------------------------------------
XML文件有幾個特點。
首先，XML標簽要求嚴格對應，且不能出現交錯的現象。
其次，XML文件必須有一個根節點，該節點包含所有其他元素。
第三，同級別的不同節點內不必包含相同的元素，如上例中第二個學生Carol有一個特別的節點NickName。這個特性使得在某些場景中XML比關系數據庫更能應對變化。
優點：
- 自然的層次型結構
- 文本內容通過標簽是自解釋的
- 通過XSD（XML Schema語言）可以驗證XML的結構
- 有許多輔助型技術如：XPath, XQuery, XSL, XSLT等
- 一些商業數據庫（如Oracle，SQL Server）已支持XML數據的存儲與操作
缺點：
- 數據的冗余信息較多
- 無法支持復雜的查詢
- 驗證功能有限
- 對XML中間的內容進行插入、刪除操作其實是重新生成一個新文件
適用場景：
適合存放數據量不大，具有層次型結構的數據，如樹形配置信息
NoSQL數據庫
非關系型數據庫我接觸的不是很多，除了給出一些產品名稱之外不做很多展開。園子里已有一些文章，本文最后也給出了鏈接供大家學習、研究。
1. Key-Value數據庫
Redis, Tokyo Cabinet, Flare
2. 面向文檔的數據庫
MongoDB, CouchDB
3. 面向分布式計算的數據庫
Cassandra, Voldemort
這幾年NoSQL非常熱。我認為NoSQL并不是“銀彈”，在某些SNS應用場景中NoSQL顯示了其優越性，但在如金融行業等對數據的一致性、完整性、可用性、事務性高要求的場景下，現在的NoSQL就未必適用。我們應充分分析應用的需求，非常謹慎地選擇技術和產品。
#p#
主要內容回顧
1.數據庫設計對于軟件項目成功的關鍵作用
2.本課程與數據庫產品無關，核心是設計的理念和方法
3.各種數據存儲所適用的場景
參考資料
1. Oracle Database 10g Express Edition
2. SQL Server 2008 R2 Express – Overview
3. SQLite Home Page
4. NoSQL數據庫筆談
原文鏈接：http://www.cnblogs.com/DBFocus/archive/2011/03/27/1996655.html
【編輯推薦】
