尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储，那么最终编写的代码会更少，结果也会更好。

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

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

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

对于大量的小图像，数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时，由于文件系统的块大小，它们每个都消耗了8kb。空间增加了400% !

有关块大小的更多信息，请参阅这篇文章: iphone文件系统的块大小是多少?

您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。

如果你有一个小的，单用户的消费应用程序，那么我会说DB。我有一个DVD管理应用程序，使用文件系统(在程序文件中)，它是一个PIA备份。我希望他们每次都能把它们存储在数据库中，让我选择保存文件的位置。

对于一个更大的商业应用，我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上，以一种编码格式(以处理大量文件的FS问题)，基于县指定的仪器编号。这在另一个方面是有用的，因为图像可以在DB记录之前存在(由于他们的工作流程)。

和大多数事情一样:“这取决于你在做什么”

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

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

文件存储上的图像是最好的选择，并将元数据存储在数据库中作为补充。从web服务器的角度来看，提供东西的最快方法是直接指向它。如果它在数据库中——比如Sharepoint——你就有ADO的开销。用网把它拉出来，流出来，等等。

Documentum -虽然臃肿和复杂-有它的权利，文件是在共享和可供您决定如何存储它们-磁盘上的服务器，SAN, NAS，无论什么。Documentum的策略是根据数据库中的主键对文件夹和文件名进行编码，从而将文件存储为树状结构。DB成为了解什么文件是什么文件和加强安全性的资源。对于大容量系统，这种方法是一种很好的方法。

在处理元数据时也要考虑这一点:如果您需要更新元数据语料库的属性，DB是您的朋友，因为您可以使用SQL快速执行更新。使用其他标记系统，您手头没有简单的数据操作工具