mysql - 在数据库 : do I miss some drawbacks in this particular situation? 中存储二进制文件

Question

我知道这个主题在过去已被广泛讨论，并且我彻底分析了许多关于此事的有见地的答案 - 证实了我的想法，通常，将 blob 存储在数据库中是不好的做法。

现在让我们来看看以下场景:

• 有users，与images是一对多的关系；
• images 行将包含，除了 users 的 FK 和一些元数据(日期、标题...)之外，以下二进制文件(或文件路径指向以下二进制文件):
  • 缩略图(小得离谱的二进制文件)；
  • 全尺寸(实际上将被预处理，大约 400x600 和大约 35-45kb；
• 我永远也不需要 images 表中没有图像的任何数据(而且我知道哪里不应该使用 SELECT *)；
• 我想使用文件系统和内存缓存；
• 在最常见的情况下，我只需要拇指(仅在某些事件中动态获取全尺寸图像，在这些情况下，通过 ID 获取它们)。澄清:每次通话要么很多非常非常小的图片，要么一张仍然非常小的图片；
• 用户会想要更改他们的照片数据、删除它们、更改它们很多。

一切似乎都让我认为 DB 解决方案是最优的。

有没有我看不到的缺点(除了在没有缓存的情况下明显打开的数据库连接)？

Answer 1

此场景中的一个问题是进行备份，或者将“开发”或“测试”环境与生产环境同步(移动数据库转储会很痛苦)。如果它们在 fs 上，则集体编辑所有图像也更加简单(例如:为图像集体创建新尺寸)。

无论如何，我没有完全了解这种方法与“db 中的指针，fs 中的文件”方法相比的真正优势。也许是内存缓存？这些天，当我想到 blob 时，无论如何我都会想到 S3 :)