关于新浪微薄好友分组设计

[yananguo_1985]

最近新浪微薄很流行，对其中的一些数据库设计希望大家可以探讨下。

微薄好友设计：
新浪微薄好友可以创建分组，好友可以属于我设置的几个分组中。

一般我们设计好友都是UserId（用户ID）、FriendId（朋友ID）、CreatedDateTime（创建时间）、
Status（好友之间的状态）、GroupId （分组编号）

表设计一般为：
UserId,FriendId,CreatedDateTime,GroupId，Status，之类的，一般一个好友只属于一个分组中。

但在新浪微薄中好友分组一个好友可以属于几个分组中，即GroupId可能为(2,5,6,7,9),即几个分组组成的字符串表示。

如果这样设计，在查询好友分组的时候就需要拆分GroupId，从而带来一定性能问题。

1、

UserId,FriendId,GroupId
1 1 2,5,6,7,9

2、
UserId,FriendId,GroupId
1 1 2
1 1 5
1 1 6
1 1 7
1 1 9

2种方式都有一定的缺陷：
第一种设计如果根据查询某个人的某个分组的好友，则需要拆分GroupId字段

第二种方式设计查询某个分组里的好友很方便，但会使好友数据量倍增。


希望大家能够讨论下。具体我可能有些没说清楚，有新浪微薄账号的可以去设置下好友这块。希望有高手能够根据新浪微薄的设计需求给出点意见，谢谢!

[叶子]

第二种比第一种好些。

[叶子]

有对应关系就用关系表

[快溜]

一个好友可以属于几个分组，那就需要生出一个编号，组号的关系表。

[AcHerat]

第二种方式设计查询某个分组里的好友很方便，但会使好友数据量倍增。

这应该不会增加多少数据量，增加是这一个表里的数据，其他的都可以通过关联关系来找到，也可以按好友的ID来绑定他的资料信息，在每个分组里显示、查看等！

[王向飞]

用第一种。第二种数据量太大，不适应微博。

[xyytuo]

[--小F--]

第一种设计如果根据查询某个人的某个分组的好友，则需要拆分GroupId字段
第一种设计拆分效率不高

第二种方式设计查询某个分组里的好友很方便，但会使好友数据量倍增。
数据量增加 但是可以通过优化查询和加索引来做..
总体说来第二种还是比较好

[yananguo_1985]

还有一种方式大家讨论下，利用我们常做的群组的方式：

创建分组表：T_Group
GroupId,GroupName,CreatorId,CreatedDateTime
GroupId主键,同时在CreatorId上建立索引

然后建立分组和好友关系表：T_Friend
GroupId,FriendId,CreatedDateTime,Status
GroupId,FriendId联合主键


1、查询我所有好友
SELECT B.FriendId
FROM T_Group A INNER JOIN T_Friend B
ON A.GroupId=B.GroupId
WHERE A.CreatorId=10000

2、查询某个分组的好友
SELECT FriendId
FROM T_Friend
WHERE GroupId=10000

3、查询我的分组

SELECT GroupId,NAME
FROM T_Group
WHERE CreatorId=10000

大家可以相互讨论下。