引言

在開發Web應用系統中，用戶管理是一個核心的問題。管理用戶，必不可少要管理用戶的聯系方式。一般情況下，人們會建立一個專門的聯系方式表，包含電話、Email、QQ、MSN等聯系方式。不難發現，即便我們考慮得再周全，也無法羅列全部的聯系方式，如手機、座機、小靈通、大靈通、skype等。那么，如何才能使用戶能夠自由添加各種聯系方式而不會影響系統本身呢？讓我們來探討這個問題的解決。

一、直接在用戶表中增加聯系方式字段

我們最先在管理用戶的時候，會直接在用戶表后面添加聯系方式，如下表：

用戶名	單位	phone	email
張三	A公司	01012345678	aa@163.com

（表1）

這在用戶張三只有一個電話和一個Email地址的情況下，沒有問題。但是，有一天，張三買了一個手機，并且把手機作為一種很重要的聯系方式。開發人員很直觀的想法就是在后面再加一個字段Mobile。

用戶名	單位	phone	email	Mobile
張三	A公司	01012345678	aa@163.com	13912345678

（表2）

顯而易見，這需要對用戶表進行修改。這會為上層的程序帶來麻煩。為了防止對用戶表的修改，單獨建立一個用戶聯系方式表是很自然的。

二、聯系方式表與用戶信息表分離

于是上面的用戶表改變成下面兩個表。

用戶信息表

用戶ID	用戶名	單位
1	張三	A公司
2	李四	B公司

（表3）

聯系方式表

ID	phone	Email	Mobile	用戶ID
1	01012345678	aa@163.com	13912345678	1
2	02033333333	bb@gmail.com	13688888888	2

（表4）

這樣一來，如果某一天又新增了一種聯系方式，比如即時聊天工具QQ，MSN，我們無需改動用戶信息表，只需要在聯系方式表中增加相應字段就可以了。

是不是這樣就已經令人滿意了呢？

三、聯系方式表擴展性問題

現在我們有一個新的用戶名號王五，他既沒有手機號，也沒有Email，他只想留下QQ號作為聯系方式。現在的表就變成這樣：

用戶信息表

用戶ID	用戶名	單位
1	張三	A公司
2	李四	B公司
3	王五	C公司

（表5）

聯系方式表

ID	phone	Email	Mobile	QQ	用戶ID
1	01012345678	aa@163.com	13912345678		1
2	02033333333	bb@gmail.com	13688888888		2
3				232678	3

（表6）

由于張三和李四輸入信息時并沒有QQ這一字段，所以張三、李四的聯系方式記錄的QQ字段的內容是空的。而王五的聯系方式只有QQ這一字段有內容，其它幾個字段都是空的。

現在，我們已經看出這種方式的問題了：

第一，         聯系方式表中會一些字段的內容是空的，這會造成數據空間的浪費。

第二，         每增加一種聯系方式，我們都需要在聯系方式表中增加字段。這會使系統的維護變得非常復雜，還可能導致上層應用程序包括界面進行相應的修改。

于是我們便期望有一種更好的方法，能夠解決聯系方式擴充的問題，即：用戶能夠根據自己的需要添加聯系方式，同時又不需要對數據庫結構進行修改。

四、根據要素來構建聯系方式表

好的，問題提出來了，我們就著手進行改進。先來進行一下理論的探討：

聯系方式是指聯系一個人的手段或途徑，聯系方式最核心的要素是：方式+值 。即采用什么樣的聯系方式，這種聯系方式的具體值是多少。如手機作為一種聯系方式，值就是手機號碼。QQ也可以作為一種聯系方式，QQ號碼就是聯系方式的值。

從邏輯上講，聯系方式表的結構應該由其要素構成。即聯系方式表的字段應該以方式和值作為最基本內容。

而我們上面建立的聯系方式表，將phone、Email、Mobile、QQ等作為表的字段。而phone、Email等都是聯系方式的內容，并不是聯系方式表的要素本身。這是導致聯系方式表不靈活的根本原因。

那么，現在我們就真正按照聯系方式表的要素來搭建結構，而將Phone、Email等作為內容。

現在的聯系方式表應該是這樣：

ID	聯系方式	值
1	Phone	13912345678
2	Email	aa@163.com

（表7）

這樣我們就可以隨意添加聯系方式到表中了。當然，由于聯系方式都是與用戶對應的，所以聯系方式表中還應該包含一個用戶ID字段，即：

ID	聯系方式	值	用戶ID
1	Phone	13912345678	1 (張三的用戶ID）
2	Email	aa@163.com	1
3	Phone	02033333333	2(李四的用戶ID)
4	Email	bb@gmail.com	2
5	QQ	232678	3（王五的用戶ID）

（表8）

這樣，用戶信息表與聯系方式表就構成了一對多的關系。當然，這需要一種聯系方式不是由兩個人同時擁有，這也是與現實比較相符的。

五、讓表結構更加優雅

前面的問題已經解決，我們是不是應該去喝慶功酒去了呢？

且慢，仔細看看最后的聯系方式表（表8），有沒有發現什么問題？在聯系方式字段中，我們看到了兩個Phone，兩個Email。如果用戶更多，看到的Phone和Email可能還會更多。

在錄入數據的時候，會不會出現兩個Phone不一致的情況，如一個首字母大寫，一個首字母小寫？當然，你會回答，可以在錄入數據時一律進行大小寫轉換。

好吧，那個問題就此打住。我還有另一個問題：如果我想把Phone改成SitePhone，應該怎么辦？做一次遍歷，然后進行替換？

更好的方式：將聯系方式這個字段單獨取出來，建立另一個表，不但能解決剛才提出的這個問題，而且會收到更好的效果，請看：

ID	聯系方式
1	Phone
2	Email
3	QQ

（表9）

ID	聯系方式ID	值	用戶ID
1	1	13912345678	1 (張三的用戶ID）
2	2	aa@163.com	1
3	1	02033333333	2(李四的用戶ID)
4	2	bb@gmail.com	2
5	3	232678	3（王五的用戶ID）

（表10）

這樣做有什么好處呢？第一，聯系方式Phone、Email、QQ等在數據庫中只出現了一次，便于對這些聯系方式進行修改，也有利于保持數據的一致性。第二、可以對每種聯系方式附加一些屬性，如聯系方式的用戶數，這種統計數字可以用來分析用戶群體使用聯系方式的特征，從而改進商業策略。

好了，最后我們把建立的最終表呈現在下面吧：

1、用戶信息表

用戶ID	用戶名	單位
1	張三	A公司
2	李四	B公司
3	王五	C公司

（表11）

2、聯系方式表

ID	聯系方式	數量
1	Phone	2
2	Email	2
3	QQ	1

（表12）

3、用戶聯系信息管理表

ID	聯系方式ID	值	用戶ID
1	1	13912345678	1
2	2	aa@163.com	1
3	1	02033333333	2
4	2	bb@gmail.com	2
5	3	232678	3

（表13）

六、題外話

就設計用戶聯系方式表這一簡單的話題，我們一路走來。筆者認為，由表及里地思考對于我們設計可擴展的、易于維護的數據庫系統非常有好處，可以為后續的管理、維護以及升級帶來不少便利，省下不少精力和時間。我們的這種思考可以舉一反三應用到選課數據庫設計、用戶權限管理數據庫設計等方面。

當然，我們可以再上升到理論的層次：前面所做的工作事實上是對數據庫設計的正規化形式的體現。如果對數據庫進行正規化設計，請參閱我的另一篇筆記：http://blog.csdn.net/z365days/archive/2007/10/25/1842608.aspx