在数据库中只存储映像的文件路径的问题是，不能再强制数据库的完整性。

如果文件路径所指向的实际映像变得不可用，则数据库会不知不觉地出现完整性错误。

考虑到图像是被寻找的实际数据，并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失)，而不必与某种文件系统(如果文件系统是独立访问的，图像可能会突然“消失”)，我倾向于将它们直接存储为BLOB或类似的文件系统。

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

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

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

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

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

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

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

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

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

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

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

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

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

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