我将使用文件系统方法，主要是因为它具有更好的灵活性。考虑一下，如果图像的数量变得很大，一个数据库可能无法处理它。对于文件系统，您可以简单地添加更多的文件服务器，假设您正在使用NFS或kind。

文件系统方法的另一个优点是能够做一些奇特的事情，例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断，则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。

有一件事我还没有看到任何人提到，但绝对值得注意的是，在大多数文件系统中也存在与存储大量图像相关的问题。例如，如果您采用上面提到的方法，以主键命名每个图像文件，在大多数文件系统上，如果您试图将所有图像放在一个大目录中，一旦您达到了非常大的图像数量(例如数十万或数百万)，您将遇到问题。

常见的解决方案是将它们散列到平衡的子目录树中。

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

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

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

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

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

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

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

尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储，那么最终编写的代码会更少，结果也会更好。