在数据库中存储图像 - 是还是不是？

我最近创建了一个PHP/MySQL应用程序，将PDF/Word文件存储在MySQL表中（每个文件大小最多为40MB）。
优点：
- 上传的文件与其他内容一起复制到备份服务器，不需要单独的备份策略（让人放心）。 - 设置Web服务器稍微简单一些，因为我不需要有一个uploads/文件夹并告诉所有应用程序它在哪里。 - 我可以使用事务进行编辑以提高数据完整性 - 我不必担心孤立和丢失的文件。
缺点：
- 因为一个表中有500MB的文件数据，mysqldump现在需要很长时间。 - 总体上与文件系统相比不是非常内存/CPU效率高。
我认为我的实现是成功的，它满足备份要求并简化了项目的布局。对于使用该应用程序的20-30人而言，性能也还不错。

我不确定这是否是一个“真实世界”的例子，但我目前有一个应用程序存储交易卡牌游戏的详细信息，包括卡片的图像。尽管数据库的记录数量仅为2851条，但考虑到某些卡牌被多次发布并具有备选艺术品，事实上，在请求时扫描艺术品的“主要方块”，然后动态生成卡片的边框和其他效果更加高效。
这个图像库的原始创建者创建了一个数据访问类，根据请求渲染图像，并且对于查看和单个卡片来说速度相当快。
这也使得部署/更新变得更加容易，当新卡牌发布时，而不是压缩整个图像文件夹并将其发送到管道中并确保正确的文件夹结构已经创建，我只需更新数据库并让用户再次下载即可。目前这个大小为56MB，这不是很好，但我正在开发增量更新功能以供未来版本使用。此外，还有一个“无图像”版本的应用程序，允许那些通过拨号连接的用户在没有下载延迟的情况下获取应用程序。
自迄今为止，这个解决方案非常成功，因为该应用程序针对桌面上的单个实例。有一个网站存档了所有这些数据以供在线访问，但我绝不会使用相同的解决方案。我同意文件访问更可取，因为它可以更好地扩展到请求图像的频率和数量。
希望这不是太多的废话，但我看到这个主题，想提供一些来自相对成功的小/中型应用程序的见解。

SQL Server 2008提供了一个兼具两者优点的解决方案: filestream数据类型。像管理普通表一样进行管理，同时拥有文件系统的性能。

取决于您要存储的图像数量和大小。我过去曾使用数据库存储图像，我的经验非常好。
在我看来，使用数据库存储图像的优点是：
A. 您不需要FS结构来保存图像 B. 当需要存储更多的项目时，数据库索引比FS树执行得更好 C. 调整得当的数据库能够很好地缓存查询结果 D. 备份非常简单。如果您设置了复制并且内容由靠近用户的服务器提供，则它也可以正常工作。在这种情况下，不需要显式同步。
如果您的图像将很小（例如<64k），并且您的db的存储引擎支持行内（记录内）BLOBs，则进一步提高性能，因为不需要间接寻址（实现了引用的局部性）。
当您处理少量巨大的图像时，存储图像可能是一个坏主意。在db中存储图像的另一个问题是，必须由应用程序处理创建、修改日期等元数据。

在我的经验中，我需要同时处理两种情况：存储在数据库中的图像和在文件系统中以路径形式存储在数据库中的图像。
第一种解决方案，即将图像存储在数据库中，相对“更加清洁”，因为您的数据访问层只需处理数据库对象；但是，当您需要处理大量数据时，这种方式并不理想。
显然，当您处理二进制大对象时，数据库访问性能会下降，并且数据库维度会增长很多，导致性能损失...而通常数据库空间比文件系统空间要昂贵得多。
另一方面，将大型二进制对象存储在文件系统中会导致您必须考虑同时备份数据库和文件系统，这可能会成为某些系统的问题。
选择文件系统的另一个原因是当您必须与第三方访问共享图像数据（或声音、视频等）时：在这些天里，我正在开发一款Web应用程序，该应用程序使用必须从我的Web农场“外部”访问的图像，以一种检索二进制数据的数据库访问方法根本不可行。因此，有时还存在设计考虑因素，这将驱使您做出选择。
在做出这个选择时，请考虑是否需要在访问二进制对象时处理权限和身份验证：当数据存储在数据库中时，这些要求通常可以更轻松地解决。

在之前的项目中，我将图片存储在文件系统中，这导致了备份、复制和文件系统与数据库不同步等很多问题。

在我的最新项目中，我将图片存储在数据库中，并在文件系统上进行缓存，效果非常好。到目前为止，我还没有遇到任何问题。

我曾经参与开发一个图像处理应用程序。我们将上传的图像存储在类似于 /images/[今天的日期]/[id编号] 的目录中。但是，我们还从图像中提取元数据（exif数据），并将其与时间戳等一起存储在数据库中。

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产收藏的项目，任何想要直接将资产存储在数据库中的尝试都会导致长期的痛苦和挫败。

我唯一真正能想到的存储在数据库中的"优点"是方便单个图像资产的使用。如果没有可以使用的文件路径，所有的图像都直接从数据库中流出，用户就不会发现他们无法访问的文件。

然而，这似乎可以通过一个中介脚本从网络无法访问的文件存储库中获取数据来更好地解决。因此，数据库存储并不是真正必要的。

街头传言，除非你是数据库供应商试图证明你的数据库可以做到这一点（比如，微软吹嘘Terraserver将亿万张图片存储在SQL Server中），否则这不是一个很好的主意。当用文件服务器存储图像和在数据库中存储路径变得更加容易时，为什么还要麻烦呢？Blob字段有点像SUV的越野能力——大多数人不使用它们，那些使用它们的人通常会遇到麻烦，然后还有那些只是出于乐趣而使用它们的人。

将图像存储在数据库中仍意味着图像数据最终会出现在文件系统中，但被隐藏起来，因此您无法直接访问它。

优点：

• 数据库完整性
• 易于管理，因为添加或删除图像时无需担心保持文件系统同步

缺点：

• 性能惩罚--数据库查找通常比文件系统查找慢
• 无法直接编辑图像（裁剪、调整大小）

这两种方法都很常见且被使用。请看一下它们的优缺点。无论哪种方式，您都必须考虑如何克服缺点。将其存储在数据库中通常意味着调整数据库参数并实现某种缓存。使用文件系统需要您找到一些方法来保持文件系统+数据库同步。