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

时间:2016-09-24 08:03:00

标签: mysql performance database-design architecture code-maintainability

我目前正在开发一种产品,其中包含产品图片,用户个人资料图片,徽标等不同类型的图片。 我需要一个具有良好查询性能的数据库。

我有两个数据库设计。

选项1. - 将所有图像存储在包含id,title,url_full,url_thumb,status和timestamp字段的单个表中

优势

  1. 我可以使用单个ImageModel文件来插入删除/更新数据。因此,图像存储将没有多重逻辑。它只是一个单一的逻辑,“存储在一个表中”。因此,每当必须保存图像时,我都可以调用ImageModel的方法
  2. 缺点

    1. 如果有大量的产品图片和较少的用户图片,由于产品数量庞大,用户图像查询会变慢。
    2. 选项2. - 使用id,title,url_full,url_thumb,status和timestamp字段在不同的表中存储不同类型的图像

      优势

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

        缺点

        1. 必须为每种图像类型编写单独的模型文件/函数。
        2. 每当需要存储图像时,需要指定类型。
        3. 我的问题是,哪种方法更好。优缺点是一个真正的问题。如果还有其他优点/缺点,请列出。 或者,如果有任何其他神数据库设计,请建议。

          请根据实际情况回答,有很多产品和用户。

2 个答案:

答案 0 :(得分:4)

这是一个长篇评论,因此我决定将其作为答案发布。在不同的表中存储不同类型的图像对我来说听起来不错。首先,如果新的类别类别稍后出现,那么该设计将如何扩展呢?那么您是否能够应对添加任意数量的新图像表?此外,查询所有图像将需要一系列连接或联合,这可能是昂贵的。

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

  

一个部分中记录数量的增加不会影响其他

的查询速度

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

  

如果有大量产品图片和较少的用户图片,由于产品数量庞大,用户图像查询会变慢。

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

具有适当指数的单个图像表似乎好多了。

答案 1 :(得分:-1)

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

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

但是将缩略图与您查询的列放在同一个表中可能会对性能造成不利影响。所以我们需要查看查询和表模式(到目前为止)。