Question

我正在开发一个新的网络应用程序，允许用户“保存”他们喜欢的图片。我有一张包含许多图片的大桌子和另一张包含用户信息的桌子。我的问题：如何保存每个用户“保存”的图片？我的意思是保存这些信息的正确方法是什么。我想用一个用户ID和图片ID创建一个新表，但我想它可能太乱了，以后将需要很长时间才能进行查询。

非常感谢你

Answer 1

我只介绍一个关联表，而不是每个用户一个。

我们引入第三个表，称之为“user_picture”或“picture_user”，或“saved_picture”，（它只是一个表名;但它应该对看模型的人有“意义”。）

该表将有两个外键：

user_id     REFERENCES user(id)
picture_id  REFERENCES picture(id)

这两列的组合可以作为PRIMARY KEY。

PRIMARY KEY (user_id, picture_id)

为用户获取已保存的图片：

SELECT p.*
  FROM picture p
  JOIN saved_picture s
    ON s.picture_id = p.id
  JOIN user u
    ON u.id = s.user_id
 WHERE u.username = 'foo'

如果有合适的索引，从大表中选择一小部分行应该仍然非常有效。

这种设计可以很容易地回答一些问题，例如“哪些图片是'最'保存的？”

SELECT s.picture_id
     , COUNT(1) AS save_count
  FROM saved_picture s
 GROUP BY s.picture_id
 ORDER BY COUNT(1) DESC

在非常大的桌子上，这可能会有一段时间，所以这就是拥有简单，短小的代理主键真正有用的地方。

将此与回答相同问题所需的查询（或查询）进行比较，如果每个用户都有单独的“保存”表;考虑需要查询的表的数量。

如果您开始向saved_picture表添加属性（例如date_saved），您可以考虑在表上添加代理主键，并在（user_id，picture_id）上使用UNIQUE约束。 / p>

Answer 2

你可以做任何你可以按照你提到的方式制作表格的东西，或者你可以为不同的用户创建不同的表格{这使你更容易显示每个用户保存的图像}

您可以对<user_id>_savedimages这样的表使用某些命名法例如，对于ID为21_savedimages的用户，您可以拥有一个表21，这样可以使任务更快，更简洁，但这反过来又会导致数据库中的大量表格。

您可以自行决定，具体取决于您拥有的用户数量，并且平均没有用户保存的图像。