Stream（.NET）处理最佳实践

Question

这个问题的标题是“Stream”，因为下面的问题是我对Streams有一个更普遍的疑问的具体例子：

我有一个问题，接受两个解决方案，我想知道最好的一个：

1. 我下载文件，将其保存到磁盘（2分钟），读取并将内容写入数据库（+ 2分钟）。
2. 我下载文件并将内容直接写入数据库（3分钟）。

如果对DB的写入失败，我将不得不在第二种情况下再次下载，但不是在第一种情况下。

哪个最好？你会用哪个？

Answer 1

除非增加的延迟真的让你失望，否则我通常会选择选项1，除非你有理由不想要文件系统上的数据（例如担心安全性，容量......）。 / p>

或者Option 3 as suggested by Max Schmeling，在写入数据库的同时保存到文件系统。

磁盘空间很便宜，备份下载数据通常很有用（例如，测试数据库编写代码的更改，作为下载数据内容的证据，......）。

Answer 2

我认为如果由于文件内容中的某些内容对数据库的写入失败，无论我尝试将相同的内容写入数据库多少次，它总是会失败。在这种情况下，唯一的解决方案是（修复）重新下载文件。如果由于数据库中的某些内容导致对数据库的写入失败，那么您遇到的问题比是否需要再次下载文件还要大。

使用选项＃2。

Answer 3

详细说明Jekke的回复：

根据文件系统创建许多失败的场合（您必须创建一个有效的文件名，确保文件系统未满，请确保该文件可以由您打开和写入，但不能由其他任何人打开和写入，那么并发使用等等。

写入文件的唯一好处我可以想到的是，在使用数据库执行任何操作之前，您将知道下载已成功完成。如果您可以将内容保存在内存中，请执行此操作。如果在下载中断的情况下你不能并且真的坚持不去数据库，至少使用.NET的内置支持来帮助你解决棘手的问题（例如IsolatedStorageFileStream）。

Answer 4

第2步没有理由两次需要两分钟。下载文件时，可以在通往数据库的途中通过内存中的变量进行流式处理。

除非你有令人信服的理由保留文件的文件系统副本，否则在大多数情况下我会选择＃2。

Answer 5

我不明白您添加的关于时间或必须两次下载文件的限定符，但是，如果系统内存紧张，将下载缓存到磁盘然后将其发送到数据库可能真的是您唯一的选择（假设您的数据提供者可以接受流）。

编辑：在原始帖子中，作者描述了直接写入数据库作为两个阶段的过程，我假设是1.将文件下载到变量中，2。将变量内容流式传输到DB。如果他在选项2中直接流入数据库，那么我同意这是一个更好的方法。

Answer 6

我会选择选项二。不应该经常出现故障，有时你可以重新下载。如果由于某种原因你需要在文件系统上有本地副本，那么不要下载，保存，读取和发送到数据库...只需下载并发送到数据库，同时保存到文件系统

Answer 7

我选择选项3.将其保存到磁盘并将URI存储在数据库中。我从来不喜欢在数据库中存储文件。

Answer 8

到目前为止，我还没有提到my blog post about blobstreams主题中提到的一个尚未提及的选项（可能在评论中除外）：设置一个处理流的处理管道，负责下载和解释你的文件需要。然后使用代码从此复合流中读取解释记录，并在一个事务内（根据您的功能要求，每个文件/每个记录）在数据库中执行所需的插入/更新。

这种情况是基于Stream的类优于哪种情况。这意味着在处理过程中，您永远不会将整个文件放在磁盘上或内存中的任何位置。如你所说，下载文件需要几分钟，它可能很大。您的系统可以采用整个文件的中间存储（可能不止一次：内存和磁盘）？即使多个文件同时处理？

另外，如果您在实践中发现该链对您来说不够可靠，并且您希望能够将下载的文件临时存储到磁盘，并且确实希望重复处理它而无需下载它再次，这很容易。所需要的只是管道中的额外Stream，它将检查所需的文件是否已经存在于“已下载的文件”缓存中（在某个文件夹中，在隔离的存储中，无论如何）并返回其中的字节实际上将下载Stream循环到您的处理管道中。