9

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

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

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

优点

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

缺点

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

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

优点

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

缺点

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

我的问题是，这是更好的方法。优点和缺点是否真正值得关注。如果还有其他优点/缺点，请列出。或者如果有其他神db设计，请提出。

请根据产品和用户较多的实际场景进行回答。

4

2 回答 2

8

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

您提到了多图像表模式的以下优势：

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

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

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

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

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

于 2016-09-24T08:10:23.977 回答
-1

你将如何传递图像？如果是通过，<img src=http:...>那么只有一个答案：单独的文件。

是的，缩略图可以通过其他机制完成，例如转换为 base64 并包含在img标签中。如果页面上有很多缩略图，这可能是最好的。

但是，将缩略图与您查询的列放在同一个表中可能不利于性能。所以我们需要查看查询和表模式（目前为止）。

于 2016-09-26T23:43:54.447 回答