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

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

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

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

我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的，在工作流结束时被删除。如果有任何形式的长期存储，我们肯定会选择存储文件路径。

还应该注意的是，我们在内部使用客户端/服务器应用程序，因此不需要担心web界面。

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

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

No.

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

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

我们实现了一个文档成像系统，它将所有图像存储在SQL2005 blob字段中。目前有几百GB，我们看到了出色的响应时间和很少或没有性能下降。此外，fr法规遵从性，我们有一个中间件层，将新发布的文档归档到光学点唱机系统，该系统将它们公开为标准NTFS文件系统。

我们对结果非常满意，特别是在以下方面:

易于复制和备份 能够轻松实现文档版本控制系统

在必须保证引用完整性和ACID遵从性的地方，需要在数据库中存储图像。

你不能保证图像和存储在数据库中的关于该图像的元数据引用同一个文件。换句话说，不可能保证文件系统上的文件只与元数据在同一时间和同一事务中被修改。