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

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

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

将图像存储在文件系统中的另一个好处是，您不需要做任何特殊的事情来让客户端缓存它们……

.．.当然，除非图像不能通过文档根访问(例如身份验证障碍)，在这种情况下，你需要检查你的代码正在发送的缓存控制头。

在我当前的应用程序中，我两者都在做。当用户确定要附加到记录上的图像时，我使用ImageMagick将其调整为适合在屏幕上显示的大小(对于我的应用程序约为300x300)，并将其存储在数据库中以方便访问，但随后还将用户的原始文件复制到网络共享，以便它可用于需要更高分辨率的应用程序(如打印)。

(还有一些其他的因素:Navision将只显示BMP，所以当我调整它的大小时，我也转换为BMP存储，数据库被复制到远程站点，在那里能够显示图像是有用的。打印工作只在总部进行，所以我不需要复制原始文件。

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

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

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

不，因为页面分割。实际上，您定义的行可以是1KB - n MB，因此数据库的页面中会有大量空白，这对性能不利。

文件存储上的图像是最好的选择，并将元数据存储在数据库中作为补充。从web服务器的角度来看，提供东西的最快方法是直接指向它。如果它在数据库中——比如Sharepoint——你就有ADO的开销。用网把它拉出来，流出来，等等。

Documentum -虽然臃肿和复杂-有它的权利，文件是在共享和可供您决定如何存储它们-磁盘上的服务器，SAN, NAS，无论什么。Documentum的策略是根据数据库中的主键对文件夹和文件名进行编码，从而将文件存储为树状结构。DB成为了解什么文件是什么文件和加强安全性的资源。对于大容量系统，这种方法是一种很好的方法。

在处理元数据时也要考虑这一点:如果您需要更新元数据语料库的属性，DB是您的朋友，因为您可以使用SQL快速执行更新。使用其他标记系统，您手头没有简单的数据操作工具