根据我的经验，我必须管理两种情况:图像存储在数据库和图像文件系统的路径存储在db。

第一个解决方案，数据库中的图像，有点“干净”，因为你的数据访问层将只需要处理数据库对象;但这只在你必须处理小数字的时候有用。

显然，当您处理二进制大对象时，数据库访问性能正在下降，数据库维度将增长很多，再次导致性能损失…通常数据库空间比文件系统空间要昂贵得多。

另一方面，在文件系统中存储大型二进制对象将导致您的备份计划必须同时考虑数据库和文件系统，这对于某些系统可能是一个问题。

使用文件系统的另一个原因是当你必须与第三方访问共享你的图像数据(或声音、视频等)时:在这一天，我正在开发一个web应用程序，它使用的图像必须从“外部”我的网络农场访问，以这样一种方式访问数据库来检索二进制数据是根本不可能的。所以有时候也会有设计上的考虑促使你做出选择。

在做出这种选择时，还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时，这些必要条件通常可以以更简单的方式解决。

我更喜欢将图像路径存储在DB中，并将图像存储在文件系统中(在服务器之间使用rsync以保持所有内容的合理最新)。

然而，我所做的一些内容管理系统的工作需要在CMS中使用图像，原因有几个——可见性控制(因此资产被保留到新闻稿发布之前)、版本控制、重新格式化(一些CMS将动态调整缩略图的大小)以及将图像链接到所见即所得页面的易用性。

因此，我的经验法则是始终将应用程序的内容保存在文件系统中，除非它是CMS驱动的。

没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统，甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?

如果你的文件系统中有你的图像，当你写一个新版本甚至删除文件时，有人正在读取文件-会发生什么?

我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。

如果您没有使用SQL Server 2008，并且有充分的理由将特定的映像文件放在数据库中，那么您可以采用“两者兼备”的方法，将文件系统用作临时缓存，并将数据库用作主存储库。

例如，您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上，并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。

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

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

No.

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

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

关于这个话题，这里有一份有趣的白皮书。

是否使用BLOB:数据库或文件系统中的大型对象存储

答案是“视情况而定。”当然，这取决于数据库服务器及其blob存储方法。它还取决于存储在blob中的数据类型，以及如何访问这些数据。

使用数据库作为存储机制，可以有效地存储和传递较小的文件。较大的文件可能最好使用文件系统存储，特别是如果它们将经常被修改/更新。(blob碎片在性能方面成为一个问题。)

Here's an additional point to keep in mind. One of the reasons supporting the use of a database to store the blobs is ACID compliance. However, the approach that the testers used in the white paper, (Bulk Logged option of SQL Server,) which doubled SQL Server throughput, effectively changed the 'D' in ACID to a 'd,' as the blob data was not logged with the initial writes for the transaction. Therefore, if full ACID compliance is an important requirement for your system, halve the SQL Server throughput figures for database writes when comparing file I/O to database blob I/O.