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

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

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

我将采用文件系统方法。不需要创建或维护带有映像的DB，从长远来看，这将为您节省一些主要的麻烦。

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

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

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

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

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

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

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

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

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

和大多数问题一样，这并不像听起来那么简单。在某些情况下，将图像存储在数据库中是有意义的。

存储的图像 动态变化，比如发票和你想要的 因为它是在1月1日 2007年? 政府希望你保持6年的历史 存储在数据库中的映像不需要不同的备份策略。存储在文件系统上的映像可以 如果图像在数据库中，则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。这需要一个非常坚定的管理员去窥探数据库提取图像

另一方面也有相关的问题

需要额外的代码来提取 然后播放图像 延迟可能是 比直接文件访问慢 数据库服务器负载过重