将文件存储在数据库中而不是文件系统中？

通常，将文件存储在数据库中（特别是mssql）而不是文件系统会对性能造成多大的影响？除了应用程序可移植性之外，我无法提出将我的文件作为varbinaries存储在SQL Server中的原因。

看看这个答案：

在DB中存储图像-是或否？

本质上，空间和性能方面的影响可能很大，具体取决于用户数量。另外，请记住，Web服务器很便宜，您可以轻松添加更多服务器来平衡负载，而数据库通常是Web体系结构中最昂贵，最难扩展的部分。

有一些相反的示例（例如Microsoft Sharepoint），但是通常在数据库中存储文件不是一个好主意。

除非您可能编写桌面应用程序和/或大致了解您将拥有多少用户，但是在像公共网站这样的随机且不可预期的情况下，您可能要为在数据库中存储文件付出高昂的代价。

如果您可以迁移到SQL Server 2008，则可以利用FILESTREAM支持，这将为您提供最好的两者-文件存储在文件系统中，但是数据库集成比仅将文件路径存储在varchar字段中要好得多。您的查询可以返回标准的.NET文件流，这使集成更加简单。

FILESTREAM存储入门

我会说，这取决于您的情况。例如，我在当地政府工作，我们有很多照片，例如面部照片等。我们的用户数量不多，但是我们需要具有良好的安全性和数据审核功能。数据库对我们来说是一个更好的解决方案，因为它使此操作变得更容易，而且我们不会遇到扩展问题。

这里有什么问题？

现代的DBMS SQL2008具有多种处理BLOB的方式，而不仅仅是将它们固定在表中。当然有利弊，您可能需要更深入地考虑。

这是一篇有趣的论文，作者是已故的吉姆·格雷（？）

到BLOB或不到BLOB：数据库或文件系统中的大对象存储

以我自己的经验，将文件存储为文件总是更好。原因是文件系统针对文件存储进行了优化，而数据库则没有。当然，也有一些例外（例如，备受赞誉的下一代MS文件系统应该建立在SQL Server之上），但是总的来说，这是我的规则。

虽然性能是一个问题，但我认为现代数据库设计已使小文件的问题减少了。

除了性能，它还取决于数据的紧密耦合程度。如果该文件包含与数据库字段密切相关的数据，则该文件在概念上与它紧密相关，并且可以存储在Blob中。如果它包含可能与多个记录相关或在数据库上下文之外有某些用途的信息，则它属于外部。例如，网页上的图像是从与链接到该页面的页面分开的请求中提取的，因此它可能属于外部（取决于特定的设计和安全考虑）。

我们的妥协（我不保证这是最好的）是将较小的XML文件存储在数据库中，但将图像和其他文件存储在数据库中。

我们决定将varbinary存储为http://www.freshlogicstudios.com/Products/Folders/中途出现性能问题。我可以说我们对它的效果感到惊讶。

我同意@ZombieSheep。只是一件事-我通常不认为数据库实际上需要可移植，因为您错过了DBMS供应商提供的所有功能。我认为迁移到另一个数据库将是人们要考虑的最后一件事。就是我的$ .02

必须将Blob（图像）解析为字节数组，然后以适当的文件名将其写入磁盘，然后读取该文件的开销，足以使您不愿意再执行此操作，尤其是在文件相当大。

不要含糊其词，但我认为您要存储的“文件”类型是最大的决定因素之一。如果您实质上是在讨论可以存储为文件的大文本字段，那么我的首选是数据库存储。