引言
在開發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
posted on 2007-10-30 10:26
CPP&&設計模式小屋 閱讀(823)
評論(2) 編輯 收藏 引用 所屬分類:
數據庫