“点赞” 数据库表设计

2015-03-20 12:07:09 2.5万阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

点赞功能设计点赞功能的设计每一次点赞,需要记录: (1)谁点的赞; (2)为那篇文章点的赞; (3)点赞时间 (4)是否已经取消点赞数据表设计点赞记录表列名数据类型说明 id N 数据表id user_id N 用户id vote_time 阅读详情

需求类似于微博，可以为主题点赞，但不能重复点赞。
目前的设计是有一个字段(varchar(max))，记录所有点过的用户id，类似于：311000|3110001|3110002
这样每次用户点赞就要根据这个字段判断是否已经赞过。
感觉这样设计不是很好，请问这样的表怎么设计比较好？
谢谢。

...全文

无人机飞控技术最详细解读已剪辑自: https://zhuanlan.zhihu.com/p/64519280[导读]被称作是“飞行器的大脑”的飞控到底是什么？以前，搞无人机的十个人有八个是航空、气动、机械出身，更多考虑的是如何让飞机稳定飞起来、飞得更快、飞得更高。如今，随着芯片、人工智能、大数据技术的发展，无人机开始了智能化、终端化、集群化的趋势，大批自动化、机械电子、信息工程、微电子的专业人材投入到了无人机研发大潮中，几年的时间让无人机从远离人们视野的军事应用飞入了寻常百姓家、让门外汉可以短暂的学习也能稳定可靠的飞行娱乐。不可阅读详情

skyandcode

应用实例 27,579 成员 68,540 内容

+ 关注 + 加入社区

切换为时间正序

罔殆 2018-07-30

打赏
举报

楼主要看看数据量来定，如果数据量不是很大的话，楼主的设计时没有问题的。考虑到客户的频繁点赞与取消，从系统性能的角度来考虑，可以考虑使用redis。

天问 2018-07-02

打赏
举报

引用 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

打赏
举报

云中客 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

打赏
举报

引用 5 楼 oraclecaicai 的回复:

[quote=引用 4 楼 ap0405140 的回复:] 建议增加点赞表, 字段列表: 用户id, 主题id, 点赞时间, 状态. 0-已取消赞 1-有效赞

就像楼上所说的这样，这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多，每一个用户赞过的每一条微博都会有一条记录，如果真的像新博微博业务量那么大的话，就要考虑做分库分表（即sharding）了。这种方案就复杂多了，我也没做过。你再根据你的业务情况考虑一下吧。[/quote] 好的。感谢你的回答。

weixin_50595510 2021-06-13

@skyandcode sdff

weixin_50595510 2021-06-13

@weixin_50595510 sdff

weixin_50595510 2021-06-13

@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）

“点赞” 数据库表设计

相关推荐