“点赞” 数据库表设计

skyandcode 2015-03-20 12:07:09
需求类似于微博,可以为主题点赞,但不能重复点赞。
目前的设计是有一个字段(varchar(max)),记录所有点过的用户id,类似于:311000|3110001|3110002
这样每次用户点赞就要根据这个字段判断是否已经赞过。
感觉这样设计不是很好,请问这样的表怎么设计比较好?
谢谢。
...全文
23977 24 打赏 收藏 转发到动态 举报
写回复
用AI写文章
24 条回复
切换为时间正序
请发表友善的回复…
发表回复
罔殆 2018-07-30
  • 打赏
  • 举报
回复
楼主要看看数据量来定,如果数据量不是很大的话,楼主的设计时没有问题的。考虑到客户的频繁点赞与取消,从系统性能的角度来考虑,可以考虑使用redis。
天问 2018-07-02
  • 打赏
  • 举报
回复 1
引用 19 楼 zxyabsent 的回复:
帖子的数量一般比用户数量多吧?
建立点赞表的时候,如果以帖子id为主键,后面会有一大串用户id,查起来又慢而且如楼上所说不支持并发
一般来说单个用户点赞的帖子数量不会太多吧?
以用户id为主键,记录点赞过的帖子,这种设计是不是好一些?
只有用户发生了点赞行为才会进入这个表,并且以一个用户的视角来看,
我登录进去,我点过赞的帖子渲染一下,而不是关心我在不在某一个帖子的点赞用户名单里
不知道楼上新浪微博是为什么要设计成帖子id为主键,后面跟用户id呢?
我也是菜鸟,所以想知道为什么哈! :)

这样是不好统计一个帖子有多少赞的吧。或许在帖子中增加一个点赞计数,这样点赞需要更新两个地方,一个用户的,一个帖子的。
guojh1111 2017-08-08
  • 打赏
  • 举报
回复
zxyabsent 2017-05-11
  • 打赏
  • 举报
回复
帖子的数量一般比用户数量多吧? 建立点赞表的时候,如果以帖子id为主键,后面会有一大串用户id,查起来又慢而且如楼上所说不支持并发 一般来说单个用户点赞的帖子数量不会太多吧? 以用户id为主键,记录点赞过的帖子,这种设计是不是好一些? 只有用户发生了点赞行为才会进入这个表,并且以一个用户的视角来看, 我登录进去,我点过赞的帖子渲染一下,而不是关心我在不在某一个帖子的点赞用户名单里 不知道楼上新浪微博是为什么要设计成帖子id为主键,后面跟用户id呢? 我也是菜鸟,所以想知道为什么哈! :)
qq_25146679 2016-12-18
  • 打赏
  • 举报
回复
5656565565555555699999
MJClown 2016-10-08
  • 打赏
  • 举报
回复
对于表结构,我多加了一个点赞表,不知道对不对 但是对于持久化我有个疑问,就是对于每个用户对于每个文章的点赞操作,我们应该按照以下哪种方式呢? 1. 对于每个操作(点赞、取消赞),立即执行数据库操作持久化数据,这样一来会不会增加数据库负担? 2. 对于每个操作,在服务器端开辟一篇内存,先将点赞、取消赞操作更新到内存中,然后采用定时任务更新到数据库中,但是这样一来会不会造成浪费内存空间的问题? 借楼问一下各位大神应该如何权衡,实际情况下怎么应用的,刚才看到上面大神提到了第二种方法,然后在楼下的回复中说到新浪DBA提到了内存空间过大反而导致效率降低的问题,所以现在有点纠结额
石头wang 2016-05-16
  • 打赏
  • 举报
回复
我想可能用mongodb来做会不会好点?
石头wang 2016-05-16
  • 打赏
  • 举报
回复
其实这个,就是一个大量数据的效率问题。 如果你的用户数,并不多的话, 可以采用“记录所有点过的用户id,类似于:311000|3110001|3110002 ” 这个方式 ,用着很方便,但是用户量一上来,就慢的要命。 建议使用,单独的点赞表机制,每天的微博有单独的分区,点赞表也按这个分区,每次查询时,就可以知道从哪个分区表去查,速度能快不少。 其实这个不好,真的很差劲的设计.字段311000|3110001|3110002是保存在同一条记录里的,在点赞的时候需要锁着这条记录(数据库行锁),根本不可能并发很多人一起点赞.
letianjvshi 2015-12-29
  • 打赏
  • 举报
回复
用位图怎么样
jinxZz0 2015-09-16
  • 打赏
  • 举报
回复
请问hibernate怎么设计
harryliuy 2015-08-14
  • 打赏
  • 举报
回复
学习了。 学习了。新浪微博这么做肯定有他的道理。
凌小星 2015-05-07
  • 打赏
  • 举报
回复
你好世界
卖水果的net 2015-03-23
  • 打赏
  • 举报
回复
其实这个,就是一个大量数据的效率问题。 如果你的用户数,并不多的话, 可以采用“记录所有点过的用户id,类似于:311000|3110001|3110002 ” 这个方式 ,用着很方便,但是用户量一上来,就慢的要命。 建议使用,单独的点赞表机制,每天的微博有单独的分区,点赞表也按这个分区,每次查询时,就可以知道从哪个分区表去查,速度能快不少。
云中客 2015-03-23
  • 打赏
  • 举报
回复
同意楼上所说,要依你的实际情况来定,别人的方法不一定适合你的
唐诗三百首 2015-03-22
  • 打赏
  • 举报
回复
建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞
skyandcode 2015-03-22
  • 打赏
  • 举报
回复
引用 2 楼 oraclecaicai 的回复:
今天刚好碰到了新浪微博的DBA,向他请教了这个问题。把点赞用户的ID都塞到一个LOB字段中,最大的问题还是不便于检索和更新。比如,一个用户打开一条微博,会显示出他有没有点过赞,这就要扫描LOB字段的内容,而字段内容是无序的,远没有索引高效;点赞之后,如果取消或者重点,需要把整个字段读出来进行修改,这无形中读写了很多不相关的内容。当然,你可以在用户表中增加一个类似字段,包含用户点过赞的所有微博的ID,这个字段的长度会相对小得多,但对于长期使用的用户,依然存在上述问题。 我也跟他提了把数据加载到内存中操作的想法。他认为,这样的方式内存开销过大,即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存,如果业务量很大的话,会造成缓存的“赞”数据频繁换入换出,即turnover,性能根本无法保障。所以,是我有点想当然了。其实,问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。 按照他的说法,新浪采用的还是传统的关系表的方式。我也提了这样集中存储,是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading,有效地将数据分散在多个节点上。因为时间仓促,也没来得及详细问他们的数据库设计和架构方案。
很感谢你的认真回答。 将数据加载到内存中的方式确实有明显的缺点。 通过你的描述,我觉得可以增加一张“点赞表”,存储的是用户id和点赞过的主题id(还是一个字段拼接存储),这样扩展性比较好(现在暂时没有考虑现实用户点赞过的主题,但以后可能有)。但就如你所说,这样对于长期使用的用户还是会出现同样的问题。如果数据量大,肯定要分表处理。 不知道有没有更好的方案?
oraclecaicai 2015-03-22
  • 打赏
  • 举报
回复
引用 4 楼 ap0405140 的回复:
建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞
就像楼上所说的这样,这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多,每一个用户赞过的每一条微博都会有一条记录,如果真的像新博微博业务量那么大的话,就要考虑做分库分表(即sharding)了。这种方案就复杂多了,我也没做过。你再根据你的业务情况考虑一下吧。
skyandcode 2015-03-22
  • 打赏
  • 举报
回复 8
引用 5 楼 oraclecaicai 的回复:
[quote=引用 4 楼 ap0405140 的回复:] 建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞
就像楼上所说的这样,这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多,每一个用户赞过的每一条微博都会有一条记录,如果真的像新博微博业务量那么大的话,就要考虑做分库分表(即sharding)了。这种方案就复杂多了,我也没做过。你再根据你的业务情况考虑一下吧。[/quote] 好的。感谢你的回答。
weixin_50595510 2021-06-13
  • 举报
回复
@skyandcode sdff
weixin_50595510 2021-06-13
  • 举报
回复 1
@weixin_50595510 sdff
weixin_50595510 2021-06-13
  • 举报
回复 1
@weixin_50595510 fsdf
skyandcode 2015-03-22
  • 打赏
  • 举报
回复
引用 4 楼 ap0405140 的回复:
建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞
嗯。这是一种方案。
oraclecaicai 2015-03-21
  • 打赏
  • 举报
回复
今天刚好碰到了新浪微博的DBA,向他请教了这个问题。把点赞用户的ID都塞到一个LOB字段中,最大的问题还是不便于检索和更新。比如,一个用户打开一条微博,会显示出他有没有点过赞,这就要扫描LOB字段的内容,而字段内容是无序的,远没有索引高效;点赞之后,如果取消或者重点,需要把整个字段读出来进行修改,这无形中读写了很多不相关的内容。当然,你可以在用户表中增加一个类似字段,包含用户点过赞的所有微博的ID,这个字段的长度会相对小得多,但对于长期使用的用户,依然存在上述问题。 我也跟他提了把数据加载到内存中操作的想法。他认为,这样的方式内存开销过大,即每条被访问的微博的“赞”数据都需要完整地读到内存中。就算通过一些机制管理占用的内存,如果业务量很大的话,会造成缓存的“赞”数据频繁换入换出,即turnover,性能根本无法保障。所以,是我有点想当然了。其实,问题的症结还是在于这样存储数据的方式不便于只对“部分”进行操作。 按照他的说法,新浪采用的还是传统的关系表的方式。我也提了这样集中存储,是否会因为表数据过大而造成低效。他说新浪采用的是对数据库做shading,有效地将数据分散在多个节点上。因为时间仓促,也没来得及详细问他们的数据库设计和架构方案。
加载更多回复(1)
交友网站数据库设计全文共5页,当前为第1页。交友网站数据库设计全文共5页,当前为第1页。数据库设计: 交友网站数据库设计全文共5页,当前为第1页。 交友网站数据库设计全文共5页,当前为第1页。 用户(Users):用于存放注册用户信息。 好友关系(Friends):用于记录好友信息。 照片(Pic):用于存放上传照片信息。 视频(Video):用于存放上传视频信息。 动态(Dynamic):用于存放用户发的动态。 动态点赞(Like):用于存放用户动态点赞情况。 动态评论(Comment):用于记录动态的评论信息。 ( 高端活动(Act): 用于存放发布活动信息。 参加活动(Join):用于存放用户是否参加活动。 用户(Users) 字段名 类型 说明 用户编号Uid ) nvarchar (20) 主键,自增 真实姓名Name nvarchar(80) 非空 昵称Nick nvarchar(80) 、 头像Portrait Image 手机Phone nvarchar (14) 非空 电子邮箱Email nvarchar(20) ` 密码Psw nvarchar(16) 非空 性别Sex nvarchar(2) 非空 出生日Birthday — Int 出生月份Birthmonth Int 出生年份Birthyear Int 交友网站数据库设计全文共5页,当前为第2页。交友网站数据库设计全文共5页,当前为第2页。— 交友网站数据库设计全文共5页,当前为第2页。 交友网站数据库设计全文共5页,当前为第2页。 省份Province nvarchar(20) 学校School nvarchar(20) 非空 专业Profession nvarchar(20) , 非空 入学年份Startyear int(6) 非空 身高Height double 体重weight / double 爱好Hobby nvarchar(30) 个人介绍Introduction nvarchar(150) ; 是否公开Open nvarchar(10) 公开,仅好友可见,不 最后访问时间Lasttime nvarchar(20) 好友关系(Friends) … 字段名 类型 说明 用户编号Uid nvarchar(20) 主键,外键 好友编号Fid nvarchar(20) … 主键,外键 照片(Pic) 字段名 类型 说明 照片编号Pid nvarchar (50) … 主键,自增 照片名称Name nvarchar(50) 上传用户编号Uid nvarchar(20) 外键 照 路径Path ; 交友网站数据库设计全文共5页,当前为第3页。交友网站数据库设计全文共5页,当前为第3页。nvarchar(40) 交友网站数据库设计全文共5页,当前为第3页。 交友网站数据库设计全文共5页,当前为第3页。 上传者IP地址Ip nvarchar(80) 上传时间Loadtime datetime 、 视频(Video) 字段名 类型 说明 视频编号Vid nvarchar(40) 主键,自增 : 视频名称Name nvarchar(20) 上传用户编号Uid nvarchar(20) 外键 视频路径Path nvarchar(40) ? 上传者IP地址Ip nvarchar(80) 上传时间Loadtime datetime ? 动态(Dynamic) 字段名 类型 说明 动态编号Did nvarchar(60) 主键,自增 } 用户编号Uid nvarchar(20) 外键 上传者IP地址 nvarchar(80) 上传时间Loadtime datetime { 动态点赞(Like) 字段名 类型 说明 动态编号Did nvarchar(12) 主键,外键 ^ 点赞用户编号Lid nvarchar(20) 主键,外键 交友网站数据库设计全文共5页,当前为第4页。交友网站数据库设计全文共5页,当前为第4页。 交友网站数据库设计全文共5页,当前为第4页。 交友网站数据库设计全文共5页,当前为第4页。 动态评论(Comment) 字段名 类型 说明 . 评论编号Cid nvarchar(100) 主键,自增 动态编号Did nvarchar(60) 外键 评论者编号Uid nvarchar(20) ( 外键 评论内容Content nvarchar(150) 评论者IP地址Ip nvarchar(80) 评论时间Time ` datetime 高端活动(Act) 字段名 类型 说明 活动编号Aid @ int(4) 主键,自增 活动名称 Name nvarchar(20) 发布时间Time datetime # 参加活动(

27,579

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧