我将采用文件系统方法。不需要创建或维护带有映像的DB，从长远来看，这将为您节省一些主要的麻烦。

我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。

这里有几个问题:

database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem

I'm not sure how much of a "real world" example this is, but I currently have an application out there that stores details for a trading card game, including the images for the cards. Granted the record count for the database is only 2851 records to date, but given the fact that certain cards have are released multiple times and have alternate artwork, it was actually more efficient sizewise to scan the "primary square" of the artwork and then dynamically generate the border and miscellaneous effects for the card when requested.

这个图像库的最初创建者创建了一个数据访问类，它根据请求呈现图像，并且对于查看和单独的卡片来说，它的速度非常快。

This also eases deployment/updates when new cards are released, instead of zipping up an entire folder of images and sending those down the pipe and ensuring the proper folder structure is created, I simply update the database and have the user download it again. This currently sizes up to 56MB, which isn't great, but I'm working on an incremental update feature for future releases. In addition, there is a "no images" version of the application that allows those over dial-up to get the application without the download delay.

到目前为止，这个解决方案工作得很好，因为应用程序本身被定位为桌面上的单个实例。有一个网站将所有这些数据存档，以供在线访问，但我绝不会使用相同的解决方案。我同意文件访问更可取，因为它可以更好地适应图像请求的频率和数量。

希望这不是太多的废话，但我看到了这个主题，并想从一个相对成功的中小型应用程序中提供一些我的见解。

正如有人已经提到的，“视情况而定”。如果数据库中的存储被认为是文件系统的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)。

和大多数问题一样，这并不像听起来那么简单。在某些情况下，将图像存储在数据库中是有意义的。

存储的图像 动态变化，比如发票和你想要的 因为它是在1月1日 2007年? 政府希望你保持6年的历史 存储在数据库中的映像不需要不同的备份策略。存储在文件系统上的映像可以 如果图像在数据库中，则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。这需要一个非常坚定的管理员去窥探数据库提取图像

另一方面也有相关的问题

需要额外的代码来提取 然后播放图像 延迟可能是 比直接文件访问慢 数据库服务器负载过重

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