不经常编辑的小静态图像(不超过几兆)应该存储在数据库中。这种方法有几个好处，包括更容易移植(图像与数据库一起传输)，更容易备份/恢复(图像与数据库一起备份)和更好的可伸缩性(一个包含数千个小缩略图文件的文件系统文件夹对我来说听起来像是可伸缩性的噩梦)。

从数据库提供图像很简单，只需实现一个http处理程序，将从DB服务器返回的字节数组作为二进制流提供服务。

我最近创建了一个PHP/MySQL应用程序，用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。

优点:

上传的文件复制到备份服务器连同其他一切，不需要单独的备份策略(安心)。 设置web服务器稍微简单一些，因为我不需要有一个上传/文件夹，并告诉我所有的应用程序它在哪里。 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件

缺点:

mysqldump现在需要很长时间，因为其中一个表中有500MB的文件数据。 总的来说，与文件系统相比，内存/cpu效率不是很高

我认为我的实现是成功的，它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说，性能还不错。

我将采用文件系统方法。正如其他一些人所指出的，大多数web服务器被构建为从文件路径发送图像。如果您不需要从数据库中写入或输出BLOB字段，那么您将获得更高的性能。当内容不变或希望限制数据库负载时，将图像存储在文件系统中可以更容易地设置静态页面。

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

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

我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的，在工作流结束时被删除。如果有任何形式的长期存储，我们肯定会选择存储文件路径。

还应该注意的是，我们在内部使用客户端/服务器应用程序，因此不需要担心web界面。

根据我的经验，有时最简单的解决方案是根据主键来命名图像。因此，很容易找到属于特定记录的图像，反之亦然。但与此同时，你并没有在数据库中存储图像的任何信息。