MySQL 数据库设计 - 存储图像 - 单个 table 或多个 table
MySQL Database design - Storing Images - Single table or multiple tables
我目前在一个产品中工作，其中有不同类型的图像，如产品图像、用户个人资料图片、徽标等。
我需要一个具有良好查询性能的数据库。
我想到了两个数据库设计。
选项 1. - 将所有图像存储在单个 table 中，其中包含 ID、标题、url_full、url_thumb、状态和时间戳字段
优势
- 我可以使用单个 ImageModel 文件来插入删除/更新数据。所以图像存储不会有多重逻辑。它只是一个单一的逻辑，"storing in a single table"。所以每当图像必须保存时，我可以调用 ImageModel
的方法
缺点
- 如果商品图片多而用户图片少，用户图片查询会因为商品数量多而变慢。
选项 2. - 在不同的 table 中存储不同类型的图像，其中包含 id、标题、url_full、url_thumb、状态和时间戳字段
优势
- 增加一个部分的记录数不会影响其他部分的查询速度
缺点
- 必须为每种图像类型编写单独的模型文件/函数。
- 每当必须存储图像时，都需要指定类型。
我的问题是，哪种方法更好。优点和缺点是真实的吗concern.Also如果还有其他优点/缺点，请列出。
或者还有其他神db设计，请指教
请根据产品和用户较多的实际场景回答
这开始是一个很长的评论，所以我决定 post 它作为一个答案。在不同的 table 中存储不同类型的图像对我来说是个坏主意。一方面，如果稍后出现新的类别，该设计将如何扩展？那么您是否能够应对添加任意数量的新图像 tables？此外，查询所有图像需要一系列连接或并集，这可能代价高昂。
您提到了多图像 table 架构的以下优势：
Increased number of records in one section won't affect the query speed of other
如果您在 type 列上使用带有索引的单个图像 table，则增加一种类型的记录数不一定会增加对第二种类型图像的查询。这是您提供的单个图像 table 的缺点：
If there are lot of product images and less user images, the user image querying will become slow due to the huge number of products.
的确，添加更多记录通常会减慢查询速度。但是，在类型上有一个适当的索引应该可以大大减少这个问题。
具有适当索引的单张图像 table 似乎要好得多。
你们将如何传送图像？如果是通过 <img src=http:...> 那么只有一个答案：单独的文件。
是的，缩略图可以通过其他机制完成，例如转换为 base64 并包含在 img 标记中。如果页面上有很多缩略图，这可能是最好的。
但是缩略图与您查询的列位于同一 table 中可能会影响性能。所以我们需要查看查询和 table 模式（目前为止）。
我目前在一个产品中工作，其中有不同类型的图像，如产品图像、用户个人资料图片、徽标等。 我需要一个具有良好查询性能的数据库。
我想到了两个数据库设计。
选项 1. - 将所有图像存储在单个 table 中，其中包含 ID、标题、url_full、url_thumb、状态和时间戳字段
优势
- 我可以使用单个 ImageModel 文件来插入删除/更新数据。所以图像存储不会有多重逻辑。它只是一个单一的逻辑，"storing in a single table"。所以每当图像必须保存时，我可以调用 ImageModel 的方法
缺点
- 如果商品图片多而用户图片少，用户图片查询会因为商品数量多而变慢。
选项 2. - 在不同的 table 中存储不同类型的图像，其中包含 id、标题、url_full、url_thumb、状态和时间戳字段
优势
- 增加一个部分的记录数不会影响其他部分的查询速度
缺点
- 必须为每种图像类型编写单独的模型文件/函数。
- 每当必须存储图像时，都需要指定类型。
我的问题是，哪种方法更好。优点和缺点是真实的吗concern.Also如果还有其他优点/缺点，请列出。 或者还有其他神db设计，请指教
请根据产品和用户较多的实际场景回答
这开始是一个很长的评论，所以我决定 post 它作为一个答案。在不同的 table 中存储不同类型的图像对我来说是个坏主意。一方面，如果稍后出现新的类别，该设计将如何扩展？那么您是否能够应对添加任意数量的新图像 tables？此外，查询所有图像需要一系列连接或并集，这可能代价高昂。
您提到了多图像 table 架构的以下优势：
Increased number of records in one section won't affect the query speed of other
如果您在 type 列上使用带有索引的单个图像 table，则增加一种类型的记录数不一定会增加对第二种类型图像的查询。这是您提供的单个图像 table 的缺点：
If there are lot of product images and less user images, the user image querying will become slow due to the huge number of products.
的确，添加更多记录通常会减慢查询速度。但是，在类型上有一个适当的索引应该可以大大减少这个问题。
具有适当索引的单张图像 table 似乎要好得多。
你们将如何传送图像？如果是通过 <img src=http:...> 那么只有一个答案：单独的文件。
是的，缩略图可以通过其他机制完成，例如转换为 base64 并包含在 img 标记中。如果页面上有很多缩略图，这可能是最好的。
但是缩略图与您查询的列位于同一 table 中可能会影响性能。所以我们需要查看查询和 table 模式（目前为止）。