主页 / dba / 问题 / 129785
Accepted
Harshit
Asked: 2016-02-20 02:54:56 +0800 CST

为帖子点赞或投票

  • 772

我正在制作一个小程序，用户可以在其中发帖或写博客。在这些帖子上，其他用户可以像在 facebook 中一样喜欢或不喜欢该帖子，或者像在 stackoverflow 中一样对帖子进行投票或否决。我想知道一种常用的良好数据库结构，并且该程序可以有效地使用该结构。我有两个选择

第一的

邮政：

id   head   message   datepost   likes   dislikes
1     ab    anchdg     DATE      1,2,3   7,55,44,3

上面的方式，id就是postid。在“喜欢”列中，1,2,3是喜欢或支持帖子或博客的用户 ID。7,55,44,3是不喜欢或不喜欢帖子或博客的用户的 ID。

第二

邮政：

id    head  message   datepost
1     ab    anchdg     DATE

喜欢：

id    postid    userid
1       1         1
2       2         2

不喜欢：

id    postid    userid
1       1         7
2       1         55

这样，我必须为喜欢和不喜欢创建两个单独的表才能获得帖子的喜欢。这样，表格ie Likes&Dislikes将被大量填满。这可能会使表变得沉重和处理缓慢。

那么，我想知道哪种方法是完成这项任务的更好和标准的方法？

mysql database-design

2 个回答

  1. Best Answer

    您面临的问题被称为数据库的“范式”，尤其是第一个范式。https://en.wikipedia.org/wiki/First_normal_form。

    具有串联用户 ID（第一个版本）的数据库不是第一个正常形式。

    请参阅https://en.wikipedia.org/wiki/Database_normalization，了解为什么以及如何通常认为规范化是好的。

    在您的第一个示例中，“用户 4 不再喜欢该帖子”的查询变得复杂。它将必须进行字符串操作，这将不得不考虑副作用和极端情况（用户是唯一的“喜欢”用户，用户是最后一个喜欢的用户，用户在喜欢的用户字符串的中间）。我会觉得这很糟糕。不要这样做。使用标准化设计。

    回复：数据库变得很重

    如果您的帖子有 400 万个赞，那么在数据库设计 1 中，您将有一行包含至少 400 万个字符宽的“赞”列（因为您需要逗号作为分隔符）。然后，您必须对四百万位宽的字符串执行字符串操作。这是非常低效且缓慢的。

    另一方面，数据库旨在处理数百万行。我们有数亿行的数据库，并且 count() 操作很快。极快。所以不，这不会是性能瓶颈。

    下一个问题是可读性和可维护性。

    例如，告诉我这两个语句的作用：

    select count(*)
from posts
inner join likes on posts.postid = likes.postid
where postid = 7

select len(likes) - len(replace(likes, ',', ''))
from posts
where postid = 7
    • 22

  2. 第二种方法要好得多，因为您可以轻松添加或删除喜欢/不喜欢的内容。

    但是您应该通过使用一个表来表示喜欢或不喜欢来修改您的第二个解决方案。
    喜欢/不喜欢表的列应该是 id、postid、userid 和另一个表示喜欢或不喜欢的值，例如 1 表示不喜欢，-1 表示喜欢。

    将 post_id 和 user_id 设置为复合主键，它工作正常。

    表的大小会随着时间的推移而增长。但你只有两个真正的列。喜欢/不喜欢的 id 和值。postid 和 userid 仅链接到它并存储在您的 user 和 post 表中。

    • 10

相关问题