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

10

我目前在开发一个产品,其中包含不同类型的图片,如产品图片、用户头像、标志等。

我需要一个查询性能良好的数据库。

我有两种数据库设计方案。

OPTION 1. - 在单个表中存储所有图像,包括id、title、url_full、url_thumb、status和timestamp字段

优点:

  1. 我可以使用单个ImageModel文件来插入、删除/更新数据。因此,对于图像存储,没有多个逻辑。只需要一个单一的逻辑,“存储在单个表中”。因此,每当需要保存图像时,我可以调用ImageModel的方法。

缺点:

  1. 如果有很多产品图片和较少的用户图片,则由于产品数量庞大,用户图片查询速度会变慢。

OPTION 2. - 在不同的表中存储不同类型的图像,包括id、title、url_full、url_thumb、status和timestamp字段

优点:

  1. 一个区域中记录数量的增加不会影响其他区域的查询速度。

缺点:

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

我的问题是,哪种方法更好。优点和缺点是真正的关注点吗?另外,如果有其他优点/缺点,请列出来。 或者,如果有其他好的数据库设计,请建议。

请根据实际情况回答,其中有大量产品和用户。


"良好的查询性能" -- 请向我们展示查询语句;如果没有它们,我们无法帮助您。 - Rick James
1
图片的典型尺寸是多少?如果我们说以千字节为单位,那么一个答案更好;如果以兆字节为单位,则另一个答案更好。 - Rick James
2个回答

9
这开始是一个很长的评论,所以我决定将其作为答案发布。将不同类型的图像存储在不同的表中听起来对我来说不是一个好主意。首先,如果出现新类型的类别,那么这种设计如何扩展?您是否能够处理添加任意数量的新图像表?此外,查询所有图像将需要一系列连接或联合,这可能代价高昂。
您提到了多图像表模式的以下优点:
记录数量增加不会影响其他查询速度
如果您在单个图像表上使用具有“类型”列索引的索引,则增加一个类型的记录数不一定会增加查询第二个类型图像的查询。这里是单个图像表的缺点:
如果产品图像很多而用户图像很少,则由于产品数量巨大,用户图像查询将变得缓慢。
增加记录确实会通常减慢查询速度。但是,在类型上拥有适当的索引应该大大减少这个问题。
具有适当索引的单个图像表似乎更好。

谢谢。实际上,我被团队中其他架构师的建议搞混了。希望这可能是最好的结构。 - Jinu Joseph Daniel
1
在某些情况下,将图像存储在单独的表中可能是有意义的,例如表格过于庞大,例如数百万条记录或更多。但即使如此,您只需分区单个表模型。 - Tim Biegeleisen
我们的应用程序目标是 200 万用户...最初大约会有 75000 个产品,随着时间的推移可能会扩大规模。 - Jinu Joseph Daniel
1
7.5万个产品对我来说一点也不可怕,甚至75万个也不是。只有当数量达到百万级别且性能下降时,才需要重新考虑事情。 - Tim Biegeleisen
你知道每增加一万条记录查询速度会降低多少百分比吗?而且这种下降是指数级的吗? - Jinu Joseph Daniel
这完全取决于表格、数据库、流量、用户数量等因素。 - Tim Biegeleisen

-1
你将以何种方式交付这些图片?如果是通过 <img src=http:...> ,那么只有一个答案:分开的文件。
是的,缩略图可以通过其他机制完成,例如转换为 base64 并包含在 img 标记中。如果页面上有很多缩略图,则可能是最佳选择。
但是,在与您查询的列相同的表中拥有缩略图可能会影响性能。因此,我们需要查看查询和表模式(目前为止)的情况。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接