轉：我們應該怎樣設計資料庫

 

資料庫該如何設計，一直以來都是一個仁者見仁智者見智的問題。

對於某一種資料庫設計，並不能簡單的用好與不好來區分。或許真的應了那句話，沒有最好，只有最適合。討論某種資料庫設計的時候，應該在某種特定的需求環境下討論。

 

 

下面來討論一下在項目中經常碰到的使用者的連絡方式儲存的問題。

我在這裡套用之前網路上流行“普通——文藝——二逼”的分類方式來描述我下文中提及的三種資料庫設計思路，並且通過查詢資料（對資料增刪改，三種設計要付出的代碼成本都差不多）和資料庫面臨需求變動兩個方面來思考這三種設計各有怎樣的優劣。

 

普通青年：

或許我們都這樣設計過資料庫

學生表 tb_Student:

Name	varchar(100)	名字
Telphone	varchar(200)	聯絡電話
Email	varchar(200)	你懂的
Fax	varchar(200)	傳真

這應該是最容易想到的一種思路，簡單、明了。

比如說我要查詢某個人的連絡方式，那麼我只用一條語句就能實現：

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

在查詢的時候，這種資料庫設計十分清晰，沒有任何思維的難度，沒有任何邏輯的挑戰。但是當面臨需求變動的時候，那將會是一場災難。

比如現在要新增一類使用者：校長。那麼我們要如何處理？

答案是：再加一張表 tb_Headmaster。

事實上，再加一張表其實修改並不大，因為我們完全不需要修改學生表的儲存邏輯，換句話說，這種設計是遵循了開閉原則的

但如果學生要添加一種連絡方式HomePhone的時候，災難發生了

怎麼辦？

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

或者再建一張表tb_Student2，來儲存HomePhone，然後以ID來關聯兩張表？按改動規模來說，這種改動相對簡單而且不容易出錯，但是在今後的維護中會增加邏輯成本。當你一而再再而三的以這樣的方式來應對需求變動的時候，你的程式將變得不可理解。

 

 

文藝青年：

UserRole	int	對應使用者類型(None = 0, Student = 1, Teacher = 2, Headmaster = 4)
OwnerID	int	對應使用者ID
ContactMethod	int	連絡方式(None = 0, Email = 1, HomePhone = 8, WorkPhone = 16,MobilePhone = 32,Fax=64)
ContactInfo	varchar(255)	聯絡資訊

這種是一個多對多關係。當我們要查詢某個使用者對應的連絡方式的時候，那是一場邏輯上的浩劫：

select ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID

這種寫法是一次性取出某個使用者所有的連絡方式，包括Email,HomePhone,WorkPhone等，之後我們可以在程式中判斷ContactMethod的類型，將具體的連絡方式加以區分。你可以簡單的想到用switch-case的寫法，類似這樣：

            var contact = 上面的SQL語句取出來的使用者所有的連絡方式;            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;                }            }

當然你也可以嘗試下面這種寫法，我個人認為這種寫法更優雅

var contact = 上面的SQL語句取出來的使用者所有的連絡方式;            txtWorkPhone.Text = (from a in contact                     where a.ContactMethod == ContactMethod.Work_Phone                     select a.ContactInfo).ToString();
//後面以此類推，你懂的

 

注意，請不要試圖使用類似下面這類語句來查詢某使用者的連絡方式：

select ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID and ContactMethod=1    //取出某使用者的Emailselect ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID and ContactMethod=8    //取出某使用者的HomePhone

相信我，這種做法非常愚蠢：每當你要取出這個使用者的一種連絡方式，就要和資料庫建立一次串連，開啟/關閉一次資料庫；這種做法代價是十分巨大的，即使有資料庫連接池，即使有資料庫緩衝，都應該避免這種愚蠢的做法

 

唔，用了那麼多的代碼，終於查出了某個使用者的聯絡資訊了。反正我個人覺得這種設計方式在查詢的時候，是邏輯上的浩劫。什嗎？你說你很享受？好吧，看來是我腦容量不夠……

不過當我們面臨需求變動的時候，那就非常愉快了。

什麼，要加一類使用者？簡單，UserRole加一個枚舉就好了。

什麼，要加一種連絡方式？ContactMethod加一個枚舉就OK。

使用了這種表設計的時候，相信你會微笑著面對需求變動的

 

 

二逼青年

昨天和同事也探討了下這個問題，按他的說法就是：哪個表要連絡方式，我就扔個欄位進去，存json

Contact

varchar(8000)

用於儲存json

舉例來說，有這麼一個使用者：

ID：1

Name：張三

Telphone：1234

Email:123@123.com

Fax：5678

那麼資料庫中就這樣存：

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

當我聽到這種設計思路的時候，虎軀微微一震：靠，這都行。按這種設計，我整張表都放進一個json裡面一股腦的存進去就算了。不過震驚之後仔細想一想，其實這種設計也是有可取之處

首先，從查詢來說，和普通青年一樣，只需一句SQL:

select Contact from 表 where 條件

查詢之後，就可以通過json處理函數將想要的資料取出來，在此就不贅述了

 

那麼當面臨需求變動的時候會發生什麼：

加一類使用者的時候，要添加一張表。也是符合開閉原則，原有代碼沒有改動

加一種連絡方式，只用存json的時候多存一點東西

 

不過這種設計如果要更新某條資料的話要稍微麻煩一點：先查詢一條資料，重組json之後再Update

 

 

寫了那麼多，希望已經將想要表達的問題表達清楚了。不足之處望海涵，也歡迎留言斧正

第三種方法很新穎，也很有創意。

資料庫該如何設計，一直以來都是一個仁者見仁智者見智的問題。

對於某一種資料庫設計，並不能簡單的用好與不好來區分。或許真的應了那句話，沒有最好，只有最適合。討論某種資料庫設計的時候，應該在某種特定的需求環境下討論。

 

 

下面來討論一下在項目中經常碰到的使用者的連絡方式儲存的問題。

我在這裡套用之前網路上流行“普通——文藝——二逼”的分類方式來描述我下文中提及的三種資料庫設計思路，並且通過查詢資料（對資料增刪改，三種設計要付出的代碼成本都差不多）和資料庫面臨需求變動兩個方面來思考這三種設計各有怎樣的優劣。

 

普通青年：

或許我們都這樣設計過資料庫

學生表 tb_Student:

Name	varchar(100)	名字
Telphone	varchar(200)	聯絡電話
Email	varchar(200)	你懂的
Fax	varchar(200)	傳真

這應該是最容易想到的一種思路，簡單、明了。

比如說我要查詢某個人的連絡方式，那麼我只用一條語句就能實現：

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

在查詢的時候，這種資料庫設計十分清晰，沒有任何思維的難度，沒有任何邏輯的挑戰。但是當面臨需求變動的時候，那將會是一場災難。

比如現在要新增一類使用者：校長。那麼我們要如何處理？

答案是：再加一張表 tb_Headmaster。

事實上，再加一張表其實修改並不大，因為我們完全不需要修改學生表的儲存邏輯，換句話說，這種設計是遵循了開閉原則的

但如果學生要添加一種連絡方式HomePhone的時候，災難發生了

怎麼辦？

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

或者再建一張表tb_Student2，來儲存HomePhone，然後以ID來關聯兩張表？按改動規模來說，這種改動相對簡單而且不容易出錯，但是在今後的維護中會增加邏輯成本。當你一而再再而三的以這樣的方式來應對需求變動的時候，你的程式將變得不可理解。

 

 

文藝青年：

UserRole	int	對應使用者類型(None = 0, Student = 1, Teacher = 2, Headmaster = 4)
OwnerID	int	對應使用者ID
ContactMethod	int	連絡方式(None = 0, Email = 1, HomePhone = 8, WorkPhone = 16,MobilePhone = 32,Fax=64)
ContactInfo	varchar(255)	聯絡資訊

這種是一個多對多關係。當我們要查詢某個使用者對應的連絡方式的時候，那是一場邏輯上的浩劫：

select ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID

這種寫法是一次性取出某個使用者所有的連絡方式，包括Email,HomePhone,WorkPhone等，之後我們可以在程式中判斷ContactMethod的類型，將具體的連絡方式加以區分。你可以簡單的想到用switch-case的寫法，類似這樣：

            var contact = 上面的SQL語句取出來的使用者所有的連絡方式;            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;                }            }

當然你也可以嘗試下面這種寫法，我個人認為這種寫法更優雅

var contact = 上面的SQL語句取出來的使用者所有的連絡方式;            txtWorkPhone.Text = (from a in contact                     where a.ContactMethod == ContactMethod.Work_Phone                     select a.ContactInfo).ToString();
//後面以此類推，你懂的

 

注意，請不要試圖使用類似下面這類語句來查詢某使用者的連絡方式：

select ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID and ContactMethod=1    //取出某使用者的Emailselect ContactInfo from 表 where UserRole=某種使用者類型 and OwnerID=某使用者ID and ContactMethod=8    //取出某使用者的HomePhone

相信我，這種做法非常愚蠢：每當你要取出這個使用者的一種連絡方式，就要和資料庫建立一次串連，開啟/關閉一次資料庫；這種做法代價是十分巨大的，即使有資料庫連接池，即使有資料庫緩衝，都應該避免這種愚蠢的做法

 

唔，用了那麼多的代碼，終於查出了某個使用者的聯絡資訊了。反正我個人覺得這種設計方式在查詢的時候，是邏輯上的浩劫。什嗎？你說你很享受？好吧，看來是我腦容量不夠……

不過當我們面臨需求變動的時候，那就非常愉快了。

什麼，要加一類使用者？簡單，UserRole加一個枚舉就好了。

什麼，要加一種連絡方式？ContactMethod加一個枚舉就OK。

使用了這種表設計的時候，相信你會微笑著面對需求變動的

 

 

二逼青年

昨天和同事也探討了下這個問題，按他的說法就是：哪個表要連絡方式，我就扔個欄位進去，存json

Contact

varchar(8000)

用於儲存json

舉例來說，有這麼一個使用者：

ID：1

Name：張三

Telphone：1234

Email:123@123.com

Fax：5678

那麼資料庫中就這樣存：

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

當我聽到這種設計思路的時候，虎軀微微一震：靠，這都行。按這種設計，我整張表都放進一個json裡面一股腦的存進去就算了。不過震驚之後仔細想一想，其實這種設計也是有可取之處

首先，從查詢來說，和普通青年一樣，只需一句SQL:

select Contact from 表 where 條件

查詢之後，就可以通過json處理函數將想要的資料取出來，在此就不贅述了

 

那麼當面臨需求變動的時候會發生什麼：

加一類使用者的時候，要添加一張表。也是符合開閉原則，原有代碼沒有改動

加一種連絡方式，只用存json的時候多存一點東西

 

不過這種設計如果要更新某條資料的話要稍微麻煩一點：先查詢一條資料，重組json之後再Update

 

 

寫了那麼多，希望已經將想要表達的問題表達清楚了。不足之處望海涵，也歡迎留言斧正

第三種方法很新穎，也很有創意。