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

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

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

DB中的文件路径绝对是可行的方法——我从拥有TB图像的客户那里听到了一个又一个故事，试图在DB中存储大量图像都是一场噩梦——单是性能损失就太大了。

没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统，甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?

如果你的文件系统中有你的图像，当你写一个新版本甚至删除文件时，有人正在读取文件-会发生什么?

我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。

我个人会将大数据存储在数据库之外。

优点:存储所有东西在一个请，容易访问数据文件，容易备份 缺点:降低数据库性能，很多页面分割，可能导致数据库损坏

如果你需要在文件系统中存储大量的图像，需要考虑以下几点:

备份和恢复。你如何保持图像同步。 文件系统的性能。这取决于您正在做的事情和文件系统，但您可能希望实现一个散列机制，这样您就不会有一个包含数十亿个文件的目录。 复制。您是否需要在多个服务器之间保持文件同步?

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

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

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