喜欢或投票推荐

我正在制作一个小程序，用户可以在其中编写帖子或撰写博客。在这些帖子上，其他用户可以像在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

这样，我必须为喜欢和不喜欢创建两个单独的表，以获取帖子的喜欢。这样，表即Likes＆Dislikes将被大量填充。这可能会使表沉重，处理速度变慢。

因此，我想知道哪种更好和更标准的方法来完成此任务？

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

具有串联用户ID（第一版）的数据库不是第一标准格式。

请参阅https://en.wikipedia.org/wiki/Database_normalization，以了解通常认为标准化的原因和方式。

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

回复：数据库变得沉重

如果您的帖子有4百万个赞，则在数据库设计1中，您将有一行带有“喜欢”列的行，该列的宽度至少为400万个字符（因为您需要使用逗号作为分隔符）。然后，您将必须对四百万个数字宽的字符串执行字符串操作。这是非常糟糕且缓慢的。

另一方面，数据库被设计为处理数百万行。我们的数据库有几亿行，并且count（）-运算非常快。非常快。所以不，这不会成为性能瓶颈。

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

例如，告诉我这2条语句的作用：

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

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

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

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

表的大小将随着时间的推移而增长。但是其中只有两个实际列。赞/不喜欢的ID和值。postid和userid仅链接到它，并存储在user和post表中。