84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
请问一下类似QQ的好友关系表是怎么设计的?难道只是简单的id,userId,friendId吗?
业精于勤,荒于嬉;行成于思,毁于随。
グループ化フィールドも必要です
其实没有必要把事情想得太复杂了,按照需求慢慢递进就可以了。
这是我做关注功能的表结构,可以参考一下。
UserRelationship: type: object properties: id: type: integer description: Id user_id: type: integer description: 用户Id target_user_id: type: integer description: 目标用户Id
非关系型数据库
我这边做设计的时候,是考虑了群组的功能的,所以将两个人的好友关系也转换为了群组
整个应该会出现三张表
一个是用户表一个是群组表一个是用户-群组对应关系表
通过三张表来确定的
据我所知,微博的关注就是这么设计的
之前看过一个面试题,就是表设计问题,好友关系表如何设计,在用户表用一个字段以逗号分隔存储还是双表关联存储的,貌似两种都可行
这样够用就可以了
不过查询起来也是个问题 redis不是很适合干这个事情嘛
或许可以再加一个是否双向好友的标志字段
应该是多对多关系。1个用户可以有多个好友。也可以被多个用户加为好友。多对多关系,在关系型数据库里面,一般使用中间表来实现。这时候中间表一般只存用户ID和好友ID。但是便于业务实现,可以在中间表加上是否验证通过、好友分组ID、排序编号等、这个多对多中间表和一般多对多不同的地方在于,这个的关联表是自身。也就是user表对user表的多对多关联。
グループ化フィールドも必要です
其实没有必要把事情想得太复杂了,按照需求慢慢递进就可以了。
这是我做关注功能的表结构,可以参考一下。
非关系型数据库
我这边做设计的时候,是考虑了群组的功能的,所以将两个人的好友关系也转换为了群组
整个应该会出现三张表
一个是用户表
一个是群组表
一个是用户-群组对应关系表
通过三张表来确定的
据我所知,微博的关注就是这么设计的
之前看过一个面试题,就是表设计问题,好友关系表如何设计,在用户表用一个字段以逗号分隔存储还是双表关联存储的,貌似两种都可行
这样够用就可以了
不过查询起来也是个问题 redis不是很适合干这个事情嘛
或许可以再加一个是否双向好友的标志字段
应该是多对多关系。
1个用户可以有多个好友。
也可以被多个用户加为好友。
多对多关系,在关系型数据库里面,一般使用中间表来实现。
这时候中间表一般只存用户ID和好友ID。但是便于业务实现,可以在中间表加上是否验证通过、好友分组ID、排序编号等、
这个多对多中间表和一般多对多不同的地方在于,这个的关联表是自身。也就是user表对user表的多对多关联。