Question

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

Answer 1

有两种方法：

您可以使用多对多关系，即使用名称为'user_likes'的单独表格，它将包含user_id和like_id列，它们都是主键（它使像like_object这样的用户只有一次）
hightraffic网站使用的另一种方式：用户表中的每个用户记录都有列：喜欢的只是序列化数组或json，无论如何。在更新此列之前，您的应用程序将检索此数据并查找特定的like_object_id（如果它不存在） - 您更新数据库。请注意，在这种情况下，所有关心应用程序中的数据一致性（例如，like_object_id存在于某些用户记录中，但不存在于like_object表中）应该在应用程序代码中实现，而不是数据库。

P.S。对不起我的英语，但我尽力解释。

Answer 2

如果我将“文本ID”和“用户ID”存储在其他表中，并计算所有需要“文本ID”的记录，则我表中的记录过多。

您怎么知道太多的记录？

我支持的某些MySQL表有数十亿行。如果他们需要的更多，则将数据拆分到多个MySQL服务器。一百万行对于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个字节，加上索引的大小。我用超过一百万行填充了一个InnoDB表，它使用了大约60MB。

mysql> show table status\G

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

如今，将数据库存储在TB级的存储中是很常见的，因此60MB的表似乎并不过分。

如何存储像Facebook的“喜欢”这样的数据

2 个答案: