在以前的一个项目中，我将图像存储在文件系统上，这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。

在我最新的项目中，我将图像存储在数据库中，并将它们缓存到文件系统中，它工作得非常好。到目前为止我还没有遇到任何问题。

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

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

正如有人已经提到的，“视情况而定”。如果数据库中的存储被认为是文件系统的1对1替代方案，那么它可能不是最佳选择。

但是，如果数据库后端将提供额外的值，而不仅仅是blob的序列化和存储，那么它可能是真正有意义的。

You may take a look at WKT Raster which is a project aiming at developing raster support in PostGIS which in turn serves as a geospatial extension for PostgreSQL database system. Idea behind the WKT Raster is not only to define a format for raster serialization and storage (using PostgreSQL system), but, what's much more important than storage, is to specify database-side efficient image processing accessible from SQL. Long story short, the idea is to move the operational weight from client to database backend, so it take places as close to storage itself as possible. The WKT Raster, as PostGIS, is dedicate to applications of specific domain, GIS.

要获得更完整的概述，请查看该系统的网站和演示文稿(PDF)。

在以前的一个项目中，我将图像存储在文件系统上，这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。

在我最新的项目中，我将图像存储在数据库中，并将它们缓存到文件系统中，它工作得非常好。到目前为止我还没有遇到任何问题。

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

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

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

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