【问题标题】:database-design: table of likes?数据库设计:喜欢表?
【发布时间】:2012-08-02 06:24:36
【问题描述】:

我想知道,
在许多网站上,都可以选择喜欢/不喜欢帖子。
当然,即使在这里,在stackoverflow。

所以,从技术上讲,这是一张大赞表?

user_id    post_id

user_id - 谁投票
post_id - 这是哪个帖子

就是这样吗?
大赞表?
没有更有效/更复杂的东西吗?

【问题讨论】:

  • 你认为这是一张大桌子的依据是什么?
  • 如果您需要保留有关谁喜欢/不喜欢帖子的信息,这是您需要存储的最小数据量。

标签: mysql database postgresql database-design


【解决方案1】:

我想我能理解你的担心。每次需要显示页面时都必须发出 COUNT()。

您当然必须拥有这个基本表,这将是 COUNT() 的基础,但您实际上并不需要对每次访问都进行 COUNT()。

创建一个总计表并在页面收到喜欢或不喜欢时更新它,使用触发器或调用存储过程来不时更新它。

我会说每种方法更适用于不同的网站个性,即更多阅读或更多写作,但您已经知道,当谈到喜欢或不喜欢时,没有什么是可以预见的。

【讨论】:

  • 所以实际上,假设我有一个可以被喜欢的 Post 表。它应该有一个字段“likes_counter”,它计算喜欢的数量,所以我不必使用 COUNT()。对吗?
  • 正确。使用您的目标表,向其中添加一列是一种在服务器中保存额外表的方法。如果允许您更改目标表的结构,那就太好了。如果没有,请创建一个单独的表,该表将包含两列:targetTableName、totalLikes。我想您可以完全访问数据库。我的考虑只是为了提醒人们注意不同的设计方案。
【解决方案2】:

在最基本的层面上,是的,就是这样。

但随后它开始扩展,试图回答以下问题:

  • 用户喜欢这篇文章的程度如何?
  • 他们什么时候喜欢这个帖子?
  • 他们是如何找到该帖子的?
  • 他们对帖子发表了评论吗?
  • 整个小组/社区对帖子的评价如何

然后您开始想要回答有关朋友和社区的更深入的问题。

【讨论】:

    猜你喜欢
    • 2012-08-27
    • 2020-05-30
    • 1970-01-01
    • 2010-12-25
    • 2014-10-01
    • 2012-07-24
    • 1970-01-01
    • 2018-10-04
    • 1970-01-01
    相关资源
    最近更新 更多