如果这是基于web的应用程序，那么将图像存储在第三方存储交付网络(如Amazon的S3或Nirvanix平台)上可能会有优势。

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

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

DB中的文件路径绝对是可行的方法——我从拥有TB图像的客户那里听到了一个又一个故事，试图在DB中存储大量图像都是一场噩梦——单是性能损失就太大了。

在数据库中只存储映像的文件路径的问题是，不能再强制数据库的完整性。

如果文件路径所指向的实际映像变得不可用，则数据库会不知不觉地出现完整性错误。

考虑到图像是被寻找的实际数据，并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失)，而不必与某种文件系统(如果文件系统是独立访问的，图像可能会突然“消失”)，我倾向于将它们直接存储为BLOB或类似的文件系统。

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

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

当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份，web服务器，甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中，那么您需要编写自己的代码来解决这些问题。