我曾经开发过一个图像处理应用程序。我们将上传的图像存储在类似于/images/[今天的日期]/[id号]的目录中。但是我们还从图像中提取了元数据(exif数据)，并将其连同时间戳等一起存储在数据库中。

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

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

将图像存储在文件系统中的另一个好处是，您不需要做任何特殊的事情来让客户端缓存它们……

.．.当然，除非图像不能通过文档根访问(例如身份验证障碍)，在这种情况下，你需要检查你的代码正在发送的缓存控制头。

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

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

正如其他人所说，SQL 2008提供了一个Filestream类型，允许您将文件名或标识符作为指针存储在db中，并自动将图像存储在您的文件系统中，这是一个很好的场景。

如果您使用的是较旧的数据库，那么我会说，如果您将其存储为blob数据，那么您将无法通过搜索特性的方式从数据库中获得任何内容，因此最好将地址存储在文件系统上，并以这种方式存储图像。

这样还可以节省文件系统上的空间，因为您只会在文件系统上节省确切数量的空间，甚至是压缩的空间。

此外，您可以决定保存一些结构或元素，允许您在文件系统中浏览原始图像而不需要任何db访问，或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置，但保留结构，当尝试增加存储空间时，也不需要尝试将图像从db中取出。

也许，它也会允许你抛出一些缓存元素，基于常用的图像url到你的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)。