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

我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中，并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:

通过更新全局配置，将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具，如imagemagick。 在web应用程序中，您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。

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

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

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

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

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

优点:

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

缺点:

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

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

不，因为页面分割。实际上，您定义的行可以是1KB - n MB，因此数据库的页面中会有大量空白，这对性能不利。