我們該如何設計數(shù)據(jù)庫（一）
數(shù)據(jù)庫該如何設計，一直以來都是一個仁者見仁智者見智的問題。
對于某一種數(shù)據(jù)庫設計，并不能簡單的用好與不好來區(qū)分。或許真的應了那句話，沒有最好，只有最適合。討論某種數(shù)據(jù)庫設計的時候，應該在某種特定的需求環(huán)境下討論。
下面來討論一下在項目中經(jīng)常碰到的用戶的聯(lián)系方式儲存的問題。
我在這里套用之前網(wǎng)絡上流行“普通——文藝——二逼”的分類方式來描述我下文中提及的三種數(shù)據(jù)庫設計思路，并且通過查詢數(shù)據(jù)（對數(shù)據(jù)增刪改，三種設計要付出的代碼成本都差不多）和數(shù)據(jù)庫面臨需求變動兩個方面來思考這三種設計各有怎樣的優(yōu)劣。
普通青年：
或許我們都這樣設計過數(shù)據(jù)庫
學生表 tb_Student:
| Name | varchar(100) | 名字 |
| Telphone | varchar(200) | 聯(lián)系電話 |
| varchar(200) | 你懂的 | |
| Fax | varchar(200) | 傳真 |
這應該是最容易想到的一種思路，簡單、明了。
比如說我要查詢某個人的聯(lián)系方式，那么我只用一條語句就能實現(xiàn)：
- select Name,Telphone,Email,Fax from 表 where 條件
在查詢的時候，這種數(shù)據(jù)庫設計十分清晰，沒有任何思維的難度，沒有任何邏輯的挑戰(zhàn)。但是當面臨需求變動的時候，那將會是一場災難。
比如現(xiàn)在要新增一類用戶：校長。那么我們要如何處理？
答案是：再加一張表 tb_Headmaster。
事實上，再加一張表其實修改并不大，因為我們完全不需要修改學生表的存儲邏輯，換句話說，這種設計是遵循了開閉原則的
但如果學生要添加一種聯(lián)系方式HomePhone的時候，災難發(fā)生了
怎么辦？
在tb_Student中加一列HomePhone？這意味著至少要修改整個Model層（或者說DAL層），這種改動是十分巨大的，而且容易造成錯誤。
或者再建一張表tb_Student2，來儲存HomePhone，然后以ID來關(guān)聯(lián)兩張表？按改動規(guī)模來說，這種改動相對簡單而且不容易出錯，但是在今后的維護中會增加邏輯成本。當你一而再再而三的以這樣的方式來應對需求變動的時候，你的程序?qū)⒆兊貌豢衫斫狻?/p>
文藝青年：
| UserRole | int | 對應用戶類型(None = 0, Student = 1, Teacher = 2, Headmaster = 4) |
| OwnerID | int | 對應用戶ID |
| ContactMethod | int | 聯(lián)系方式(None = 0, Email = 1, HomePhone = 8, WorkPhone = 16,MobilePhone = 32,Fax=64) |
| ContactInfo | varchar(255) | 聯(lián)系信息 |
這種是一個多對多關(guān)系。當我們要查詢某個用戶對應的聯(lián)系方式的時候，那是一場邏輯上的浩劫：
- select ContactInfo from 表 where UserRole=某種用戶類型 and OwnerID=某用戶ID
這種寫法是一次性取出某個用戶所有的聯(lián)系方式，包括Email,HomePhone,WorkPhone等，之后我們可以在程序中判斷ContactMethod的類型，將具體的聯(lián)系方式加以區(qū)分。你可以簡單的想到用switch-case的寫法，類似這樣：
- var contact = 上面的SQL語句取出來的用戶所有的聯(lián)系方式;
- foreach (var item in contact)
- {
- switch (item.ContactMethod)
- {
- case ContactMethod.WorkPhone:
- txtWorkPhone.Text = item.ContactInfo;break;
- case ContactMethod.Email:
- txtEmail.Text = item.ContactInfo;
- break;
- case ContactMethod.Fax:
- txtFax.Text = item.ContactInfo;
- break;
- case ContactMethod.OtherPhone:
- txtOtherPhone.Text = item.ContactInfo;
- break;
- case ContactMethod.MobilePhone:
- txtMobilePhone.Text = item.ContactInfo;
- break;
- }
- }
當然你也可以嘗試下面這種寫法，我個人認為這種寫法更優(yōu)雅
- var contact = 上面的SQL語句取出來的用戶所有的聯(lián)系方式;
- txtWorkPhone.Text = (from a in contact
- where a.ContactMethod == ContactMethod.Work_Phone
- select a.ContactInfo).ToString();
- //后面以此類推，你懂的
注意，請不要試圖使用類似下面這類語句來查詢某用戶的聯(lián)系方式：
- select ContactInfo from 表 where UserRole=某種用戶類型 and OwnerID=某用戶ID and ContactMethod=1 //取出某用戶的Email
- select ContactInfo from 表 where UserRole=某種用戶類型 and OwnerID=某用戶ID and ContactMethod=8 //取出某用戶的HomePhone
相信我，這種做法非常愚蠢：每當你要取出這個用戶的一種聯(lián)系方式，就要和數(shù)據(jù)庫建立一次連接，打開/關(guān)閉一次數(shù)據(jù)庫；這種做法代價是十分巨大的，即使有數(shù)據(jù)庫連接池，即使有數(shù)據(jù)庫緩存，都應該避免這種愚蠢的做法.
唔，用了那么多的代碼，終于查出了某個用戶的聯(lián)系信息了。反正我個人覺得這種設計方式在查詢的時候，是邏輯上的浩劫。什么？你說你很享受？好吧，看來是我腦容量不夠……
不過當我們面臨需求變動的時候，那就非常愉快了。
什么，要加一類用戶？簡單，UserRole加一個枚舉就好了。
什么，要加一種聯(lián)系方式？ContactMethod加一個枚舉就OK。
使用了這種表設計的時候，相信你會微笑著面對需求變動的
二逼青年
昨天和同事也探討了下這個問題，按他的說法就是：哪個表要聯(lián)系方式，我就扔個字段進去，存json
| Contact | varchar(8000) | 用于儲存json |
舉例來說，有這么一個用戶：
| ID：1 | Name：張三 | Telphone：1234 | Email:123@123.com | Fax：5678 |
那么數(shù)據(jù)庫中就這樣存：
[{"ID":1,"Name":"張三","Telphone":"1234","Email":"123@123.com","Fax":"5678"}]
當我聽到這種設計思路的時候，虎軀微微一震：靠，這都行。按這種設計，我整張表都放進一個json里面一股腦的存進去就算了。不過震驚之后仔細想一想，其實這種設計也是有可取之處
首先，從查詢來說，和普通青年一樣，只需一句SQL：
- select Contact from 表 where 條件
查詢之后，就可以通過json處理函數(shù)將想要的數(shù)據(jù)取出來，在此就不贅述了。
那么當面臨需求變動的時候會發(fā)生什么：
加一類用戶的時候，要添加一張表。也是符合開閉原則，原有代碼沒有改動。
加一種聯(lián)系方式，只用存json的時候多存一點東西。
不過這種設計如果要更新某條數(shù)據(jù)的話要稍微麻煩一點：先查詢一條數(shù)據(jù)，重組json之后再Update。
寫了那么多，希望已經(jīng)將想要表達的問題表達清楚了。不足之處望海涵，也歡迎留言斧正。
PS：真的是一個規(guī)律，一個月才能寫出一篇博客……
再PS：就快能回家了，高興，開心。
原文鏈接：http://www.cnblogs.com/CrazyJinn/archive/2012/04/27/2457409.html
【編輯推薦】
