數(shù)據(jù)庫(kù)該如何設(shè)計(jì)，一直以來(lái)都是一個(gè)仁者見(jiàn)仁智者見(jiàn)智的問(wèn)題。

對(duì)于某一種數(shù)據(jù)庫(kù)設(shè)計(jì)，并不能簡(jiǎn)單的用好與不好來(lái)區(qū)分。或許真的應(yīng)了那句話(huà)，沒(méi)有最好，只有最適合。討論某種數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候，應(yīng)該在某種特定的需求環(huán)境下討論。

下面來(lái)討論一下在項(xiàng)目中經(jīng)常碰到的用戶(hù)的聯(lián)系方式儲(chǔ)存的問(wèn)題。

我在這里套用之前網(wǎng)絡(luò)上流行“普通——文藝——二逼”的分類(lèi)方式來(lái)描述我下文中提及的三種數(shù)據(jù)庫(kù)設(shè)計(jì)思路，并且通過(guò)查詢(xún)數(shù)據(jù)（對(duì)數(shù)據(jù)增刪改，三種設(shè)計(jì)要付出的代碼成本都差不多）和數(shù)據(jù)庫(kù)面臨需求變動(dòng)兩個(gè)方面來(lái)思考這三種設(shè)計(jì)各有怎樣的優(yōu)劣。

普通青年：

或許我們都這樣設(shè)計(jì)過(guò)數(shù)據(jù)庫(kù)

學(xué)生表 tb_Student:

Name	varchar(100)	名字
Telphone	varchar(200)	聯(lián)系電話(huà)
Email	varchar(200)	你懂的
Fax	varchar(200)	傳真

這應(yīng)該是最容易想到的一種思路，簡(jiǎn)單、明了。

比如說(shuō)我要查詢(xún)某個(gè)人的聯(lián)系方式，那么我只用一條語(yǔ)句就能實(shí)現(xiàn)：

select Name,Telphone,Email,Fax from 表 where 條件 

在查詢(xún)的時(shí)候，這種數(shù)據(jù)庫(kù)設(shè)計(jì)十分清晰，沒(méi)有任何思維的難度，沒(méi)有任何邏輯的挑戰(zhàn)。但是當(dāng)面臨需求變動(dòng)的時(shí)候，那將會(huì)是一場(chǎng)災(zāi)難。

比如現(xiàn)在要新增一類(lèi)用戶(hù)：校長(zhǎng)。那么我們要如何處理？

答案是：再加一張表 tb_Headmaster。

事實(shí)上，再加一張表其實(shí)修改并不大，因?yàn)槲覀兺耆恍枰薷膶W(xué)生表的存儲(chǔ)邏輯，換句話(huà)說(shuō)，這種設(shè)計(jì)是遵循了開(kāi)閉原則的

但如果學(xué)生要添加一種聯(lián)系方式HomePhone的時(shí)候，災(zāi)難發(fā)生了

怎么辦？

在tb_Student中加一列HomePhone？這意味著至少要修改整個(gè)Model層（或者說(shuō)DAL層），這種改動(dòng)是十分巨大的，而且容易造成錯(cuò)誤。

或者再建一張表tb_Student2，來(lái)儲(chǔ)存HomePhone，然后以ID來(lái)關(guān)聯(lián)兩張表？按改動(dòng)規(guī)模來(lái)說(shuō)，這種改動(dòng)相對(duì)簡(jiǎn)單而且不容易出錯(cuò)，但是在今后的維護(hù)中會(huì)增加邏輯成本。當(dāng)你一而再再而三的以這樣的方式來(lái)應(yīng)對(duì)需求變動(dòng)的時(shí)候，你的程序?qū)⒆兊貌豢衫斫狻?/p>

文藝青年：

UserRole	int	對(duì)應(yīng)用戶(hù)類(lèi)型(None = 0, Student = 1, Teacher = 2, Headmaster = 4)
OwnerID	int	對(duì)應(yīng)用戶(hù)ID
ContactMethod	int	聯(lián)系方式(None = 0, Email = 1, HomePhone = 8, WorkPhone = 16,MobilePhone = 32,Fax=64)
ContactInfo	varchar(255)	聯(lián)系信息

這種是一個(gè)多對(duì)多關(guān)系。當(dāng)我們要查詢(xún)某個(gè)用戶(hù)對(duì)應(yīng)的聯(lián)系方式的時(shí)候，那是一場(chǎng)邏輯上的浩劫：

select ContactInfo from 表 where UserRole=某種用戶(hù)類(lèi)型 and OwnerID=某用戶(hù)ID 

這種寫(xiě)法是一次性取出某個(gè)用戶(hù)所有的聯(lián)系方式，包括Email,HomePhone,WorkPhone等，之后我們可以在程序中判斷ContactMethod的類(lèi)型，將具體的聯(lián)系方式加以區(qū)分。你可以簡(jiǎn)單的想到用switch-case的寫(xiě)法，類(lèi)似這樣：

var contact = 上面的SQL語(yǔ)句取出來(lái)的用戶(hù)所有的聯(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;  
                }  
            } 

當(dāng)然你也可以嘗試下面這種寫(xiě)法，我個(gè)人認(rèn)為這種寫(xiě)法更優(yōu)雅

var contact = 上面的SQL語(yǔ)句取出來(lái)的用戶(hù)所有的聯(lián)系方式;              
txtWorkPhone.Text = (from a in contact  
                     where a.ContactMethod == ContactMethod.Work_Phone  
                     select a.ContactInfo).ToString();  
//后面以此類(lèi)推，你懂的 

注意，請(qǐng)不要試圖使用類(lèi)似下面這類(lèi)語(yǔ)句來(lái)查詢(xún)某用戶(hù)的聯(lián)系方式：

select ContactInfo from 表 where UserRole=某種用戶(hù)類(lèi)型 and OwnerID=某用戶(hù)ID and ContactMethod=1    //取出某用戶(hù)的Email  
select ContactInfo from 表 where UserRole=某種用戶(hù)類(lèi)型 and OwnerID=某用戶(hù)ID and ContactMethod=8    //取出某用戶(hù)的HomePhone 

相信我，這種做法非常愚蠢：每當(dāng)你要取出這個(gè)用戶(hù)的一種聯(lián)系方式，就要和數(shù)據(jù)庫(kù)建立一次連接，打開(kāi)/關(guān)閉一次數(shù)據(jù)庫(kù)；這種做法代價(jià)是十分巨大的，即使有數(shù)據(jù)庫(kù)連接池，即使有數(shù)據(jù)庫(kù)緩存，都應(yīng)該避免這種愚蠢的做法.

唔，用了那么多的代碼，終于查出了某個(gè)用戶(hù)的聯(lián)系信息了。反正我個(gè)人覺(jué)得這種設(shè)計(jì)方式在查詢(xún)的時(shí)候，是邏輯上的浩劫。什么？你說(shuō)你很享受？好吧，看來(lái)是我腦容量不夠……

不過(guò)當(dāng)我們面臨需求變動(dòng)的時(shí)候，那就非常愉快了。

什么，要加一類(lèi)用戶(hù)？簡(jiǎn)單，UserRole加一個(gè)枚舉就好了。

什么，要加一種聯(lián)系方式？ContactMethod加一個(gè)枚舉就OK。

使用了這種表設(shè)計(jì)的時(shí)候，相信你會(huì)微笑著面對(duì)需求變動(dòng)的

二逼青年

昨天和同事也探討了下這個(gè)問(wèn)題，按他的說(shuō)法就是：哪個(gè)表要聯(lián)系方式，我就扔個(gè)字段進(jìn)去，存json

Contact

varchar(8000)

用于儲(chǔ)存json

舉例來(lái)說(shuō)，有這么一個(gè)用戶(hù)：

ID：1

Name：張三

Telphone：1234

Email:123@123.com

Fax：5678

那么數(shù)據(jù)庫(kù)中就這樣存：

[{"ID":1,"Name":"張三","Telphone":"1234","Email":"123@123.com","Fax":"5678"}]

當(dāng)我聽(tīng)到這種設(shè)計(jì)思路的時(shí)候，虎軀微微一震：靠，這都行。按這種設(shè)計(jì)，我整張表都放進(jìn)一個(gè)json里面一股腦的存進(jìn)去就算了。不過(guò)震驚之后仔細(xì)想一想，其實(shí)這種設(shè)計(jì)也是有可取之處
首先，從查詢(xún)來(lái)說(shuō)，和普通青年一樣，只需一句SQL：

select Contact from 表 where 條件 

查詢(xún)之后，就可以通過(guò)json處理函數(shù)將想要的數(shù)據(jù)取出來(lái)，在此就不贅述了。

那么當(dāng)面臨需求變動(dòng)的時(shí)候會(huì)發(fā)生什么：

加一類(lèi)用戶(hù)的時(shí)候，要添加一張表。也是符合開(kāi)閉原則，原有代碼沒(méi)有改動(dòng)。

加一種聯(lián)系方式，只用存json的時(shí)候多存一點(diǎn)東西。

不過(guò)這種設(shè)計(jì)如果要更新某條數(shù)據(jù)的話(huà)要稍微麻煩一點(diǎn)：先查詢(xún)一條數(shù)據(jù)，重組json之后再Update。

寫(xiě)了那么多，希望已經(jīng)將想要表達(dá)的問(wèn)題表達(dá)清楚了。不足之處望海涵，也歡迎留言斧正。

PS：真的是一個(gè)規(guī)律，一個(gè)月才能寫(xiě)出一篇博客……

再PS：就快能回家了，高興，開(kāi)心。

原文鏈接：http://www.cnblogs.com/CrazyJinn/archive/2012/04/27/2457409.html

【編輯推薦】

1. 20個(gè)數(shù)據(jù)庫(kù)設(shè)計(jì)最佳實(shí)踐
2. 讓數(shù)據(jù)庫(kù)變快的10個(gè)建議
3. 11個(gè)重要的數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)則