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

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

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

我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中，并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:

通过更新全局配置，将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具，如imagemagick。 在web应用程序中，您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。

我更喜欢将图像路径存储在DB中，并将图像存储在文件系统中(在服务器之间使用rsync以保持所有内容的合理最新)。

然而，我所做的一些内容管理系统的工作需要在CMS中使用图像，原因有几个——可见性控制(因此资产被保留到新闻稿发布之前)、版本控制、重新格式化(一些CMS将动态调整缩略图的大小)以及将图像链接到所见即所得页面的易用性。

因此，我的经验法则是始终将应用程序的内容保存在文件系统中，除非它是CMS驱动的。

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

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

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

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

在以前的一个项目中，我将图像存储在文件系统上，这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。

在我最新的项目中，我将图像存储在数据库中，并将它们缓存到文件系统中，它工作得非常好。到目前为止我还没有遇到任何问题。