怎么设计数据库（一）

如何设计数据库（一）

数据库该如何设计，一直以来都是一个仁者见仁智者见智的问题。对于某一种数据库设计，并不能简单的用好与不好来区分。或许真的应了那句话，没有最好，只有最适合。讨论某种数据库设计的时候，应该在某种特定的需求环境下讨论。下面来讨论一下在项目中经常碰到的用户的联系方式储存的问题。我在这里套用之前网络上流行“普通——文艺——二逼”的分类方式来描述我下文中提及的三种数据库设计思路，并且通过查询数据（对数据增删改，三种设计要付出的代码成本都差不多）和数据库面临需求变动两个方面来思考这三种设计各有怎样的优劣。普通青年：或许我们都这样设计过数据库学生表 tb_Student:Namevarchar(100)名字Telphonevarchar(200)联系电话Emailvarchar(200)你懂的Faxvarchar(200)传真
这应该是最容易想到的一种思路，简单、明了。比如说我要查询某个人的联系方式，那么我只用一条语句就能实现：

UserRoleint对应用户类型(None = 0, Student = 1, Teacher = 2, Headmaster = 4)OwnerIDint对应用户IDContactMethodint联系方式(None = 0, Email = 1, HomePhone = 8, WorkPhone = 16,MobilePhone = 32,Fax=64)ContactInfovarchar(255)联系信息
这种是一个多对多关系。当我们要查询某个用户对应的联系方式的时候，那是一场逻辑上的浩劫：
Contactvarchar(8000)用于储存json
举例来说，有这么一个用户：
ID：1Name：张三Telphone：1234Email:123@123.comFax：5678
那么数据库中就这样存：
[{"ID":1,"Name":"张三","Telphone":"1234","Email":"123@123.com","Fax":"5678"}]
当我听到这种设计思路的时候，虎躯微微一震：靠，这都行。按这种设计，我整张表都放进一个json里面一股脑的存进去就算了。不过震惊之后仔细想一想，其实这种设计也是有可取之处
首先，从查询来说，和普通青年一样，只需一句SQL：
select Contact from 表 where 条件 
查询之后，就可以通过json处理函数将想要的数据取出来，在此就不赘述了。
那么当面临需求变动的时候会发生什么：
加一类用户的时候，要添加一张表。也是符合开闭原则，原有代码没有改动。
加一种联系方式，只用存json的时候多存一点东西。
不过这种设计如果要更新某条数据的话要稍微麻烦一点：先查询一条数据，重组json之后再Update。
写了那么多，希望已经将想要表达的问题表达清楚了