通过网络将二进制数据从数据库中取出会导致巨大的延迟问题，并且伸缩性不好。

将路径存储在数据库中，让你的web服务器承担负载——这就是它的设计目的!

文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。

大海捞针:高效存储数十亿张照片

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

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.

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

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

这里的诀窍是不要成为一个狂热分子。

这里需要注意的一点是，在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?

No.

事实上，许多数据库都胜过许多文件系统，即使我们只讨论原始速度。

正确的做法是为您的精确场景做出正确的决定，要做到这一点，您需要一些数字和一些用例估计。

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目，任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是，将它们存储在数据库中，可以方便地保存单个图像资产。如果没有可用的文件路径，并且所有图像都直接从DB中流出，那么用户就不会有发现他们不应该访问的文件的危险。

不过，这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此，DB存储并不是真正必要的。