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

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

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目，任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是，将它们存储在数据库中，可以方便地保存单个图像资产。如果没有可用的文件路径，并且所有图像都直接从DB中流出，那么用户就不会有发现他们不应该访问的文件的危险。

不过，这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此，DB存储并不是真正必要的。

在我曾经工作过的一家公司，我们在Oracle 8i(当时是9i)数据库中存储了1.55亿张图像。7.5 tb的价值。

你的网络服务器(我假设你正在使用)是用来处理图像的，而数据库不是。因此，我会大力投反对票。

在数据库中只存储路径(可能还有文件信息)。

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

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

No.

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

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

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

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