更新

另一方面，我计划将文件名和任何其他信息存储在SQL数据库中，并仅在用户实际要下载文件时查询磁盘。这就是我计划检索文件的方式：

FileStream stream = File.Open("C:\file.txt");
byte[] fileContent = new byte[stream.Length];
stream.Read(fileContent, 0, fileContent.Length;

将从数据库中检索任何文件信息。硬盘仅用于保存和获取文件。

更新2：

文件将保存为硬盘上的GUID + EXTENSION，而实际文件名存储在数据库中。

Answer 1

是的，您需要进一步细分文件以节省用于目录中文件枚举的时间，不过这种方法可以节省多少钱可能取决于您使用的操作系统。当您需要在文件夹中的数百个文件中请求单个文件时，Windows非常慢。我相信这是因为它会尝试读取所有文件的所有属性，如果它必须搜索它们。此外，对于此类应用程序，您可能需要担心文件版本，文件上载超时，感染病毒的文件，隐藏最终用户的真实文件路径，不支持的MIME类型等。

Answer 2

除了@cahitbox所说的，它还远不止于此。如果您期望有多个并发用户，则应该有多个磁盘，以便您可以同时检索多个文件（磁盘速度很慢）。

Answer 3

如果文件“metadata”存储在数据库中，则只需使用GUID及其扩展名命名文件即可。将它们返回给用户的最简单方法是将它们直接存储在Web应用程序中，因此如果安全性限制不是太紧，它们可通过简单的URL获取：

http://my.web.site/files/cbacd260-10ec-4377-bd19-25daa1fd0fe2.pdf

如果您真的想通过和HttpHandler提供文件，我会使用

Response.TransmitFile( Server.MapPath("path/to/files/cbacd260-10ec-4377-bd19-25daa1fd0fe2.pdf" );

此处的文档：http://msdn.microsoft.com/en-us/library/12s31dhy%28VS.80%29.aspx

预期的用户数量也非常重要。每天30个用户与30 000个不一样。文件容量也很重要：您谈论千兆字节，但管理300时不会管理30 GB。

对于文件的物理存储，尽量避免在同一目录中存储太多（我认为2500+）文件。但通常情况下，对于文件上传网站，您会在逻辑上对它们进行“分组”，因此您可以拥有一个子目录。

Answer 4

我认为您还需要考虑以下问题：

将向用户显示文件列表，或者用户将使用直接链接到文件
你需要做备份吗？
您打算使用数据库存储其他信息，还是仅使用文件系统？
您的应用程序是否有任何安全性或权限？
应用程序必须具备哪些性能（并发读取次数，并发写入次数，响应时间，上载/下载速度）？
您需要进行任何搜索吗？
您是否需要存储原始文件名？

开发文件存储Web应用程序

更新

更新2：

4 个答案: