一对多关系的应用，这样做合理么？

[lingyun410]

============================结构A

用户表
>>>结构
姓名 角色ID串
>>>记录
1 Cloud.L ,2,4,
2 CNode ,1,2,3,
角色表
>>>结构
角色
>>>记录
1 学生
2 孩子
3 家长
4 员工

============================结构B
用户表
>>>结构
姓名
>>>记录
1 Cloud.L
2 CNode
角色表
>>>结构
角色
>>>记录
1 学生
2 孩子
3 家长
4 员工
关系表
>>>>结构
用户ID 角色ID
>>>>记录
1 2
1 4
2 1
2 2
2 3
对于这种数据关系应该如何来做结构？我目前是上面的做法，但有人告诉我应该把用户表中的这些角色放到一个单独的表中，采用结构B的记录方式来一一记录数据，其实我以前也有考虑这种方法，但是觉得数据记录会产生很多。使用结构A的在输出记录ID的时候需要分离ID串，再存储的时候需要组合后再存储。

不知道像腾讯的那种好友关系是如何建立的结构，我觉得这些道理都差不多，怎样才算是一个高效方便的存储方式呢？

[永生天地]

我会选 B 查询，更新等操作方便

[天-笑]

用户表 只需要记录用户的基本信息即可
角色表 只需要记录定义的角色即可
增加 用户与角色的对应关系表，可以解决一对多，多对对的关系
如果对应关系改变，只需要维护用户与角色的对应关系表 即可

现在的硬盘都很大了，有冗余数据怕什么，再说了这些对应关系能占多少存储空间？

[lingyun410]

[Quote=引用 1 楼 xys_777 的回复:]
我会选 B 查询，更新等操作方便
[/Quote]
也就是说数据记录在关系表中产生很多不重要是吧。

[hao1hao2hao3]

分三个表。

用户表 用户角色关联表 角色表



用户表和角色表维护基础数据即可，所有的关系都存储在用户角色关联表中。

[王向飞]

B方案更好，便于数据库增删查改，
便于开发维护。

A方案不可取，

[Ellen_Tang]

结构B 好点。

[fengyun142415]

结构B好，易维护。

[spiritofdragon]

肯定是B，我以前也用过A。更新操作方不方便我觉得都不是最先考虑的，毕竟是一次性写代码就搞定了。但以后要用A模式查询角色关系，那才麻烦...

[笨沙发]

还是根据需求不同在具体分析用那种方案合理

[lingyun410]

恩，楼上说的对。
A方案我在百媚网这个项目中使用了，但是有一定的局限性。现在觉得A方案倒不是更新、删除操作的麻烦。麻烦的是在不同的关系位置需要不同的关系属性。

而B方案中的一对多的关系正好可以很好的解决一下这个问题。可以将针对于当前记录的所有标识角色再赋于当前节点关系时的唯一标识属性。