mysql - 如何将数据存储为 facebook 的“喜欢”

Question

我有存储在数据库中的对象，它是一些带有属性的文本。该文本有评级。我需要存储这个评级，并防止一个用户多次提高这个评级。如果我将“text id”和“user id”存储在其他表中并计算所有需要“text id”的记录，我的表中记录太多。

Answer 1

有两种方法：

1. 您可以使用多对多关系，即使用名称为“user_likes”的单独表，它将有user_id和like_id列，它们都是主键（它使用户可能只喜欢一次like_object）

2. 另一种方式 - 高流量网站使用：用户表中的每个用户记录都有列：喜欢这只是序列化数组或 json，等等。在更新此列之前，您的应用程序检索此数据并查找特定like_object_id是否不存在 - 您更新数据库。请注意，在这种情况下，所有关心应用程序中的数据一致性（例如，like_object_id 存在于某些用户记录中，但不存在于 like_object 表中）都应该在您的应用程序代码中实现，而不是在数据库中实现。

PS对不起我的英语，但我尽力解释。

Answer 2

我将喜欢的内容与帖子本身一起存储，但不确定其性能，因为我的网站都没有达到非常重的负载。

但我执行以下操作：

Post {
id int;
likes_count int; // likes count to quickly retrive it
likes string; // id of the users liked this post, comma separated
} 

当用户喜欢一个帖子时，（使用 ajax）：

1. UI 将直接更新并显示用户喜欢该帖子

2. ajax 将使用 post id 和 user id 向服务器发送请求，然后 post 数据将更新如下：

post.likes_count += 1;
post.likes += userId + ',' ;

当用户重新加载页面时，它会检查他的 id 是否在喜欢，然后帖子将显示为liked.

Answer 3

如果我将“text id”和“user id”存储在其他表中并计算所有需要“text id”的记录，我的表中记录太多。

你怎么知道什么是太多记录？

我支持的一些 MySQL 表有数十亿行。如果他们需要更多，他们会将数据拆分到多个 MySQL 服务器。100 万行对于 MySQL 数据库来说不是问题。

如果您想限制数据以便每个用户只能“喜欢”给定文本一次，则必须为每个用户单独存储数据。如果用户可以“不喜欢”他们以前喜欢的文本，这也是正确的。

CREATE TABLE likes (
  user_id BIGINT UNSIGNED NOT NULL,
  post_id BIGINT UNSIGNED NOT NULL,
  PRIMARY KEY (user_id, post_id),
  KEY (post_id, user_id)
);

此示例表使用其主键约束来确保每个用户只能喜欢给定帖子一次。通过添加第二个索引，这有助于优化对特定帖子的喜欢的查询。

每行只有 16 个字节，加上索引的大小。我用超过 100 万行填充了一个 InnoDB 表，它使用了大约 60MB。

mysql> show table status\G

           Name: likes
         Engine: InnoDB
           Rows: 1046760
    Data_length: 39419904
   Index_length: 23658496

如今，将数据库存储在 TB 大小的存储空间上很常见，因此 60MB 的表似乎并不算大。