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

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

有一件事我还没有看到任何人提到，但绝对值得注意的是，在大多数文件系统中也存在与存储大量图像相关的问题。例如，如果您采用上面提到的方法，以主键命名每个图像文件，在大多数文件系统上，如果您试图将所有图像放在一个大目录中，一旦您达到了非常大的图像数量(例如数十万或数百万)，您将遇到问题。

常见的解决方案是将它们散列到平衡的子目录树中。

SQL Server 2008提供了一个两者兼备的解决方案:文件流数据类型。

像管理普通表一样管理它，并具有文件系统的性能。

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

是否使用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.

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

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

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

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

也许，它也会允许你抛出一些缓存元素，基于常用的图像url到你的web引擎/程序，所以你也把自己保存在那里。

我将使用文件系统方法，主要是因为它具有更好的灵活性。考虑一下，如果图像的数量变得很大，一个数据库可能无法处理它。对于文件系统，您可以简单地添加更多的文件服务器，假设您正在使用NFS或kind。

文件系统方法的另一个优点是能够做一些奇特的事情，例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断，则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。