【学习笔记】通信录的表设计

登录

最近，在学习SQL2008时，看到一个问题，“如何设计一个人和他的通信地址之间的表关系”。
其中，表达了多种的设计思想，我认为附件的图表设计比较理想，愿与大家共同学习。

MultiRow · MultiRow

数据库设计外行来学习！
这个表结构设计好在哪里呢？会不会有点过度设计呢？楼主在详细说说啊。

平底锅 · 平底锅

这个设计表面看来有点过渡设计，实际我们细细想来，主要有以下好处。
1）消除了联系人，电话号码和地址的多值依赖，可以有许多彼此独立的电话号码与地址关联。
2）Type类型可以任意定义（如：家庭，配偶等），不需要修改实体的结构，提高了扩充性。
3）有多人对应同一个地址或电话，如果要改变地址或电话，只需修改一个表的只即可。

上边的设计还要根据具体问题具体分析，也许在某个场合这个设计就是过于复杂。但从商业的角度来说，增加这种复杂性也许值得，他利用Type考虑了更多的特殊情况，增强了可扩充性。

WantSong · WantSong

>从商业的角度来说
个人建议，具体问题得具体分析。是不是过度设计，是不是设计不足，都得视具体的业务问题而定。
既然是通信录的表设计，那么如果我是跑业务的，我可能会纪录多个单位，这个单位下面可能有多个联系人，也可能我不关心联系人是谁而只关心单位的联系电话。以Person作为通讯录管理的主体不合适，同样Phone与Person的连接也就不太合适。
对于座机而言，我可能需要一个组（家庭）的概念，多个人共同拥有一部电话。从上图中，也可以实现这个业务，只是过于复杂，并且没有体现出Group这个实体，属于设计不足。
再比如说某人的电话是136xxxx0123，移动的号。他打来电话的来电显有几种可能性：1，136xxxx0123；2 86136xxxx0123；3，0123 （大户时）。我需要建立几个Phone实体呢？
>“Type类型可以任意定义（如：家庭，配偶等）”
家庭、配偶显然是在讲人与人之间的关系，但是上图中只有人与地址关系类型和人与电话关系类型，没有人与人的关系类型描述，如何定义呢。

人和地址的关系，显然是多对多的，一个人可能住在多个地方，多个人也可能住在同一个地方。这里用了3张表做多对多，是比较合理的。
从这个角度讲，标题换为“如何设计一个人和他的通信地址之间的表关系”会更适合些。当然，地址本身也可以是很复杂的，如果有业务要求的话。

		自动登录	找回密码
密码			立即注册

【学习笔记】通信录的表设计

本帖子中包含更多资源

3 个回复

活字格认证