MySQL 数据库设计 - 存储图像 - 单表或多表

Question

我目前在一个产品中工作，其中有不同类型的图像，如产品图像、用户个人资料图片、徽标等。我需要一个具有良好查询性能的数据库。

我想到了两个数据库设计。

选项 1. - 将所有图像存储在一个带有 id、title、url_full、url_thumb、状态和时间戳字段的表中

好处

1. 我可以使用单个 ImageModel 文件插入删除/更新数据。所以不会有图像存储的多重逻辑。它只是一个逻辑，“存储在单个表中”。所以每当需要保存图像时，我可以调用 ImageModel 的方法

缺点

1. 如果产品图片多，用户图片少，由于产品数量庞大，用户图片查询会变慢。

选项 2. - 使用 id、title、url_full、url_thumb、status 和 timestamp 字段在不同的表中存储不同类型的图像

好处

1. 增加一个部分的记录数不会影响其他部分的查询速度

缺点

1. 必须为每种图像类型编写单独的模型文件/函数。
2. 每当必须存储图像时，都需要指定类型。

我的问题是，这是更好的方法。优点和缺点是否真正值得关注。此外，如果还有其他优点/缺点，请列出。或者如果有任何其他神数据库设计，请提出建议。

请根据产品多、用户多的实际场景来回答。

Answer 1

这开始是一个很长的评论，所以我决定将其发布为答案。在不同的表中存储不同类型的图像对我来说听起来是个坏主意。一方面，例如，如果稍后出现新类型的类别，那么该设计将如何扩展？那么您是否能够处理添加任意数量的新图像表？此外，查询所有图像需要一系列连接或联合，这可能代价高昂。

您提到了多图像表架构的以下优势：

增加一个部分的记录数不会影响其他部分的查询速度

如果您使用带有type列索引的单个图像表，那么增加一种类型的记录数不一定会增加对第二种类型图像的查询。这是您提供的单个图像表的缺点：

如果产品图片多，用户图片少，由于产品数量庞大，用户图片查询会变慢。

确实，添加更多记录通常会减慢查询速度。然而，在类型上有一个适当的索引应该会大大减少这个问题。

具有适当索引的单个图像表似乎要好得多。