除非增加的延迟真的让你受不了，否则我通常会选择选项1，除非你有不想将数据放在文件系统中的充分理由（例如关于安全性、容量等方面的担忧）。
或者也许像Max Schmeling建议的那样选择选项3，同时保存到文件系统和写入数据库。
磁盘空间很便宜，而且通常有备份下载数据很有用（例如测试更改数据库编写代码，作为下载数据内容的证据等）。
对于Jekke的回复，我想进行详细说明：
依赖文件系统会导致许多故障（您必须创建一个有效的文件名，确保文件系统不是满的，确保文件可以被您打开和写入但不被其他人打开和写入，那么并发使用怎么办等等）。
我认为将内容写入文件的唯一好处是，在对数据库执行任何操作之前，您将知道下载已成功完成。如果可以将内容保存在内存中，请尽量这样做。如果不能，并且您真的坚持不在下载中断的情况下访问数据库，至少使用.NET的内置支持来帮助您处理棘手的部分（例如IsolatedStorageFileStream）。
我会选择一个目前还没有被提到的选项（除了评论中可能提到的），它在我的有关blobstreams的博客文章主题中提到：建立一个处理流水线，负责下载和解释所需的文件。然后使用代码从这个复合流中读取解释记录，并根据您的功能要求在一个事务（每个文件/每个记录）内执行所需的插入/更新操作。
这种情况是Stream类优秀的应用场景。这意味着在处理过程中，您永远不会在磁盘或内存中同时拥有整个文件。正如您提到的，下载文件需要几分钟，它可能很大。您的系统能否承受完整文件的中间存储（可能超过一次：内存和磁盘）？即使多个文件同时处理？
Stream ，它会检查文件是否已经在您的“已下载文件”缓存中（在某个文件夹中、隔离存储中或其他任何地方），并返回其中的字节，而不是实际地将下载的 Stream 循环到处理管道中。第二步不必两次花费两分钟。在下载文件的同时，你可以通过内存中的变量将其流式传输到数据库。
除非有充分的理由保留文件系统副本，大多数情况下我会选择第二种方法。
我不理解你所添加的关于时间或需要下载文件两次的限定符，但是，如果系统内存不足，将下载缓存到磁盘然后发送到数据库可能真的是您唯一的选择（假设您的数据提供程序可以接受流）。
编辑：在原帖中，作者将直接写入数据库描述为一个两阶段的过程，我认为这个过程是1.将文件下载到变量中，2.将变量内容流式传输到数据库。如果他在选项2中直接流式传输到数据库，那么我同意这是更好的方法。
我会选择第三个选项。将其保存到磁盘并将URI存储在数据库中。我从来没有喜欢过将文件存储在数据库中。