数据库该如何设计，一直以来都是一个仁者见仁智者见智的问题。

对于某一种数据库设计，并不能简单的用好与不好来区分。或许真的应了那句话，没有最好，只有最适合。讨论某种数据库设计的时候，应该在某种特定的需求环境下讨论。

?

?

下面来讨论一下在项目中经常碰到的用户的联系方式储存的问题。

我在这里套用之前网络上流行“普通——文艺——二逼”的分类方式来描述我下文中提及的三种数据库设计思路，并且通过查询数据（对数据增删改，三种设计要付出的代码成本都差不多）和数据库面临需求变动两个方面来思考这三种设计各有怎样的优劣。

?

普通青年：

或许我们都这样设计过数据库

学生表 tb_Student:

这应该是最容易想到的一种思路，简单、明了。

比如说我要查询某个人的联系方式，那么我只用一条语句就能实现：

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

在查询的时候，这种数据库设计十分清晰，没有任何思维的难度，没有任何逻辑的挑战。但是当面临需求变动的时候，那将会是一场灾难。

比如现在要新增一类用户：校长。那么我们要如何处理？

答案是：再加一张表 tb_Headmaster。

事实上，再加一张表其实修改并不大，因为我们完全不需要修改学生表的存储逻辑，换句话说，这种设计是遵循了开闭原则的

但如果学生要添加一种联系方式HomePhone的时候，灾难发生了

怎么办？

在tb_Student中加一列HomePhone？这意味着至少 要修改整个Model层（或者说DAL层），这种改动是十分巨大的，而且容易造成错误。

或者再建一张表tb_Student2，来储存HomePhone，然后以ID来关联两张表？按改动规模来说，这种改动相对简单而且不容易出错，但是在今后的维护中会增加逻辑成本。当你一而再再而三的以这样的方式来应对需求变动的时候，你的程序将变得不可理解。

?

?

文艺青年：

这种是一个多对多关系。当我们要查询某个用户对应的联系方式的时候，那是一场逻辑上的浩劫：

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