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

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

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

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

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

文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。

大海捞针:高效存储数十亿张照片

通常，我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库)，并将所有负载都放在其中。另一方面:它极大地简化了备份策略，特别是当你有多个web服务器，需要以某种方式保持数据同步时。

像大多数其他事情一样，这取决于预期的规模和预算。

数据数据库

文件的文件系统

我会选择两种解决方案，我的意思是……我将开发一个小组件(EJB)，它将映像存储在DB中，并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时，这个DB才会更新。然后，我还将该路径存储在业务DB中。

从应用程序的角度来看，我将始终使用文件系统(从业务DB检索路径)，通过这种方式，我们将修复备份问题，并避免可能的性能问题。

唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜，拜托!