这应该是最容易想到的一种思路，简单、明了。
比如说我要查询某个人的联系方式，那么我只用一条语句就能实现：
selectName,Telphone,Email,Faxfrom表where条件
在查询的时候，这种数据库设计十分清晰，没有任何思维的难度，没有任何逻辑的挑战。但是当面临需求变动的时候，那将会是一场灾难。
比如现在要新增一类用户：校长。那么我们要如何处理？
答案是：再加一张表 tb_Headmaster。
事实上，再加一张表其实修改并不大，因为我们完全不需要修改学生表的存储逻辑，换句话说，这种设计是遵循了开闭原则的
但如果学生要添加一种联系方式HomePhone的时候，灾难发生了
怎么办？
在tb_Student中加一列HomePhone？这意味着至少要修改整个Model层（或者说DAL层），这种改动是十分巨大的，而且容易造成错误。
或者再建一张表tb_Student2，来储存HomePhone，然后以ID来关联两张表？按改动规模来说，这种改动相对简单而且不容易出错，但是在今后的维护中会增加逻辑成本。当你一而再再而三的以这样的方式来应对需求变动的时候，你的程序将变得不可理解。
文艺青年：
这种是一个多对多关系。当我们要查询某个用户对应的联系方式的时候，那是一场逻辑上的浩劫： selectContactInfofrom表whereUserRole=某种用户类型andOwnerID=某用户ID
这种写法是一次性取出某个用户所有的联系方式，包括Email,HomePhone,WorkPhone等，之后我们可以在程序中判断ContactMethod的类型，将具体的联系方式加以区分。你可以简单的想到用switch-case的写法，类似这样：
varcontact=上面的SQL语句取出来的用户所有的联系方式; foreach(varitemincontact) { switch(item.ContactMethod) { caseContactMethod.WorkPhone: txtWorkPhone.Text=item.ContactInfo;break; caseContactMethod.Email: txtEmail.Text=item.ContactInfo; break; caseContactMethod.Fax: txtFax.Text=item.ContactInfo; break; caseContactMethod.OtherPhone: txtOtherPhone.Text=item.ContactInfo; break; caseContactMethod.MobilePhone: txtMobilePhone.Text=item.ContactInfo; break; } }
当然你也可以尝试下面这种写法，我个人认为这种写法更优雅
varcontact=上面的SQL语句取出来的用户所有的联系方式; txtWorkPhone.Text=(fromaincontact wherea.ContactMethod==ContactMethod.Work_Phone selecta.ContactInfo).ToString(); //后面以此类推，你懂的
注意，请不要试图使用类似下面这类语句来查询某用户的联系方式：
selectContactInfofrom表whereUserRole=某种用户类型andOwnerID=某用户IDandContactMethod=1//取出某用户的Email selectContactInfofrom表whereUserRole=某种用户类型andOwnerID=某用户IDandContactMethod=8//取出某用户的HomePhone
相信我，这种做法非常愚蠢：每当你要取出这个用户的一种联系方式，就要和数据库建立一次连接，打开/关闭一次数据库；这种做法代价是十分巨大的，即使有数据库连接池，即使有数据库缓存，都应该避免这种愚蠢的做法.
唔，用了那么多的代码，终于查出了某个用户的联系信息了。反正我个人觉得这种设计方式在查询的时候，是逻辑上的浩劫。什么？你说你很享受？好吧，看来是我脑容量不够……
不过当我们面临需求变动的时候，那就非常愉快了。
什么，要加一类用户？简单，UserRole加一个枚举就好了。
什么，要加一种联系方式？ContactMethod加一个枚举就OK。
使用了这种表设计的时候，相信你会微笑着面对需求变动的
二逼青年
昨天和同事也探讨了下这个问题，按他的说法就是：哪个表要联系方式，我就扔个字段进去，存json
举例来说，有这么一个用户：
那么数据库中就这样存：
[{"ID":1,"Name":"张三","Telphone":"1234","Email":"123@","Fax":"5678"}]
当我听到这种设计思路的时候，虎躯微微一震：靠，这都行。按这种设计，我整张表都放进一个json里面一股脑的存进去就算了。不过震惊之后仔细想一想，其实这种设计也是有可取之处
首先，从查询来说，和普通青年一样，只需一句SQL：
selectContactfrom表where条件
查询之后，就可以通过json处理函数将想要的数据取出来，在此就不赘述了。
那么当面临需求变动的时候会发生什么：
加一类用户的时候，要添加一张表。也是符合开闭原则，原有代码没有改动。
加一种联系方式，只用存json的时候多存一点东西。
不过这种设计如果要更新某条数据的话要稍微麻烦一点：先查询一条数据，重组json之后再Update。
写了那么多，希望已经将想要表达的问题表达清楚了。不足之处望海涵，也欢迎留言斧正。
原文链接：/CrazyJinn/archive//04/27/2457409.html
