我们该如何设计数据库(一)
数据库该如何设计,一直以来都是一个仁者见仁智者见智的问题。
对于某一种数据库设计,并不能简单的用好与不好来区分。或许真的应了那句话,没有最好,只有最适合。讨论某种数据库设计的时候,应该在某种特定的需求环境下讨论。
?
?
下面来讨论一下在项目中经常碰到的用户的联系方式储存的问题。
我在这里套用之前网络上流行“普通——文艺——二逼”的分类方式来描述我下文中提及的三种数据库设计思路,并且通过查询数据(对数据增删改,三种设计要付出的代码成本都差不多)和数据库面临需求变动两个方面来思考这三种设计各有怎样的优劣。
?
普通青年:
或许我们都这样设计过数据库
学生表 tb_Student:
Namevarchar(100)名字Telphonevarchar(200)联系电话Emailvarchar(200)你懂的Faxvarchar(200)传真这应该是最容易想到的一种思路,简单、明了。
比如说我要查询某个人的联系方式,那么我只用一条语句就能实现:
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; case ContactMethod.OtherPhone: txtOtherPhone.Text = item.ContactInfo; break; case ContactMethod.MobilePhone: txtMobilePhone.Text = item.ContactInfo; break; } }
当然你也可以尝试下面这种写法,我个人认为这种写法更优雅
var contact = 上面的SQL语句取出来的用户所有的联系方式; txtWorkPhone.Text = (from a in contact where a.ContactMethod == ContactMethod.Work_Phone select a.ContactInfo).ToString();//后面以此类推,你懂的
?
注意,请不要试图使用类似下面这类语句来查询某用户的联系方式:
select ContactInfo from 表 where UserRole=某种用户类型 and OwnerID=某用户ID and ContactMethod=1 //取出某用户的Emailselect ContactInfo from 表 where UserRole=某种用户类型 and OwnerID=某用户ID and ContactMethod=8 //取出某用户的HomePhone
相信我,这种做法非常愚蠢:每当你要取出这个用户的一种联系方式,就要和数据库建立一次连接,打开/关闭一次数据库;这种做法代价是十分巨大的,即使有数据库连接池,即使有数据库缓存,都应该避免这种愚蠢的做法
?
唔,用了那么多的代码,终于查出了某个用户的联系信息了。反正我个人觉得这种设计方式在查询的时候,是逻辑上的浩劫。什么?你说你很享受?好吧,看来是我脑容量不够……
不过当我们面临需求变动的时候,那就非常愉快了。
什么,要加一类用户?简单,UserRole加一个枚举就好了。
什么,要加一种联系方式?ContactMethod加一个枚举就OK。
使用了这种表设计的时候,相信你会微笑着面对需求变动的
?
?
二逼青年
昨天和同事也探讨了下这个问题,按他的说法就是:哪个表要联系方式,我就扔个字段进去,存json
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
?
?
1 楼 cloudmail 2012-04-28 如果只用到name来查询的话,支持2b做法