扫码关注官方订阅号
84669人学习
65727人学习
82984人学习
467778人学习
498837人学习
471966人学习
256484人学习
152542人学习
224170人学习
139536人学习
81804人学习
85022人学习
11944人学习
20001人学习
60816人学习
5487人学习
15007人学习
2150人学习
6980人学习
194925人学习
359900人学习
1142人学习
19058人学习
3206人学习
180550人学习
48569人学习
17603人学习
40936人学习
1049人学习
750人学习
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表的多对多关联。
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
扫描下载App
Copyright 2014-2024 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
精品班
技术支持
技术咨询
学习群
会员优惠
返回顶部
应该还有一个分组字段
其实没有必要把事情想得太复杂了,按照需求慢慢递进就可以了。
这是我做关注功能的表结构,可以参考一下。
非关系型数据库
我这边做设计的时候,是考虑了群组的功能的,所以将两个人的好友关系也转换为了群组
整个应该会出现三张表
一个是用户表
一个是群组表
一个是用户-群组对应关系表
通过三张表来确定的
据我所知,微博的关注就是这么设计的
之前看过一个面试题,就是表设计问题,好友关系表如何设计,在用户表用一个字段以逗号分隔存储还是双表关联存储的,貌似两种都可行
这样够用就可以了
不过查询起来也是个问题 redis不是很适合干这个事情嘛
或许可以再加一个是否双向好友的标志字段
应该是多对多关系。
1个用户可以有多个好友。
也可以被多个用户加为好友。
多对多关系,在关系型数据库里面,一般使用中间表来实现。
这时候中间表一般只存用户ID和好友ID。但是便于业务实现,可以在中间表加上是否验证通过、好友分组ID、排序编号等、
这个多对多中间表和一般多对多不同的地方在于,这个的关联表是自身。也就是user表对user表的多对多关联。