通过网络将二进制数据从数据库中取出会导致巨大的延迟问题，并且伸缩性不好。

将路径存储在数据库中，让你的web服务器承担负载——这就是它的设计目的!

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目，任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是，将它们存储在数据库中，可以方便地保存单个图像资产。如果没有可用的文件路径，并且所有图像都直接从DB中流出，那么用户就不会有发现他们不应该访问的文件的危险。

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

我将采用文件系统方法。正如其他一些人所指出的，大多数web服务器被构建为从文件路径发送图像。如果您不需要从数据库中写入或输出BLOB字段，那么您将获得更高的性能。当内容不变或希望限制数据库负载时，将图像存储在文件系统中可以更容易地设置静态页面。

我们实现了一个文档成像系统，它将所有图像存储在SQL2005 blob字段中。目前有几百GB，我们看到了出色的响应时间和很少或没有性能下降。此外，fr法规遵从性，我们有一个中间件层，将新发布的文档归档到光学点唱机系统，该系统将它们公开为标准NTFS文件系统。

我们对结果非常满意，特别是在以下方面:

易于复制和备份 能够轻松实现文档版本控制系统

对于大量的小图像，数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时，由于文件系统的块大小，它们每个都消耗了8kb。空间增加了400% !

有关块大小的更多信息，请参阅这篇文章: iphone文件系统的块大小是多少?

根据我的经验，我必须管理两种情况:图像存储在数据库和图像文件系统的路径存储在db。

第一个解决方案，数据库中的图像，有点“干净”，因为你的数据访问层将只需要处理数据库对象;但这只在你必须处理小数字的时候有用。

显然，当您处理二进制大对象时，数据库访问性能正在下降，数据库维度将增长很多，再次导致性能损失…通常数据库空间比文件系统空间要昂贵得多。

另一方面，在文件系统中存储大型二进制对象将导致您的备份计划必须同时考虑数据库和文件系统，这对于某些系统可能是一个问题。

使用文件系统的另一个原因是当你必须与第三方访问共享你的图像数据(或声音、视频等)时:在这一天，我正在开发一个web应用程序，它使用的图像必须从“外部”我的网络农场访问，以这样一种方式访问数据库来检索二进制数据是根本不可能的。所以有时候也会有设计上的考虑促使你做出选择。

在做出这种选择时，还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时，这些必要条件通常可以以更简单的方式解决。