如果这是基于web的应用程序，那么将图像存储在第三方存储交付网络(如Amazon的S3或Nirvanix平台)上可能会有优势。

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

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

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

如果您没有使用SQL Server 2008，并且有充分的理由将特定的映像文件放在数据库中，那么您可以采用“两者兼备”的方法，将文件系统用作临时缓存，并将数据库用作主存储库。

例如，您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上，并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。

您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。

如果你有一个小的，单用户的消费应用程序，那么我会说DB。我有一个DVD管理应用程序，使用文件系统(在程序文件中)，它是一个PIA备份。我希望他们每次都能把它们存储在数据库中，让我选择保存文件的位置。

对于一个更大的商业应用，我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上，以一种编码格式(以处理大量文件的FS问题)，基于县指定的仪器编号。这在另一个方面是有用的，因为图像可以在DB记录之前存在(由于他们的工作流程)。

和大多数事情一样:“这取决于你在做什么”

这取决于你要存储的图像数量和它们的大小。我曾经使用数据库存储图像，我的经验是相当不错的。

在我看来，使用数据库存储图像的优点是，

A.你不需要FS结构来保存你的图像 B.当存储更多的项时，数据库索引比FS树执行得更好 C.智能调优的数据库在缓存查询结果方面表现良好 D.备份很简单。如果您设置了复制，并且内容从用户附近的服务器传递，那么它也可以很好地工作。在这种情况下，不需要显式同步。

如果你的图像很小(比如< 64k)，并且你的db的存储引擎支持内联(记录中)blob，它可以进一步提高性能，因为不需要间接(实现了引用的局部性)。

当您处理少量大尺寸图像时，存储图像可能是一个坏主意。在db中存储图像的另一个问题是，像创建、修改日期这样的元数据必须由应用程序处理。

数据数据库

文件的文件系统