我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中，并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:

通过更新全局配置，将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具，如imagemagick。 在web应用程序中，您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。

我会选择两种解决方案，我的意思是……我将开发一个小组件(EJB)，它将映像存储在DB中，并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时，这个DB才会更新。然后，我还将该路径存储在业务DB中。

从应用程序的角度来看，我将始终使用文件系统(从业务DB检索路径)，通过这种方式，我们将修复备份问题，并避免可能的性能问题。

唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜，拜托!

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

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

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

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

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

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

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

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

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

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

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

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