当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份，web服务器，甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中，那么您需要编写自己的代码来解决这些问题。

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目，任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是，将它们存储在数据库中，可以方便地保存单个图像资产。如果没有可用的文件路径，并且所有图像都直接从DB中流出，那么用户就不会有发现他们不应该访问的文件的危险。

不过，这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此，DB存储并不是真正必要的。

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

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

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

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

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

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

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

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

假设:应用程序是基于web的

我很惊讶没有人真正提到这一点……委托给其他专家->使用第三方映像/文件托管提供商。

将文件存储在付费的在线服务上，比如

Amazon S3 Moso云存储

另一个StackOverflow线程在这里讨论这个。

这篇文章解释了为什么你应该使用第三方托管提供商。

太值得了。它们能有效地储存。没有带宽从你的服务器上传到客户端请求等等。