我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。

这里有几个问题:

database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem

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

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

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

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

我们实现了一个文档成像系统，它将所有图像存储在SQL2005 blob字段中。目前有几百GB，我们看到了出色的响应时间和很少或没有性能下降。此外，fr法规遵从性，我们有一个中间件层，将新发布的文档归档到光学点唱机系统，该系统将它们公开为标准NTFS文件系统。

我们对结果非常满意，特别是在以下方面:

易于复制和备份 能够轻松实现文档版本控制系统

我是一个企业文档管理系统的首席开发人员，一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法是出于本页提到的许多原因，另外还有一个原因:存档。

我们的许多客户必须遵守行业特定的存档规则，例如存储到光盘或非专有格式的存储。此外，您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中，即使使用SQL Server 2008的文件流数据类型，你的存档选项也会变得非常狭窄。

通常，我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库)，并将所有负载都放在其中。另一方面:它极大地简化了备份策略，特别是当你有多个web服务器，需要以某种方式保持数据同步时。

像大多数其他事情一样，这取决于预期的规模和预算。