Performance 当将文件作为二进制数据保存到SQL Server 2005数据库时，我需要考虑哪些具体问题？

我正在使用MVC3和EF4.1编写一个在线纳税申报申请。部分申请要求纳税人能够上传与其报税表相关的文件。用户将能够在几天或几周后返回，并可能上载其他文档。在最终提交报税表之前，用户可以查看已上载文件的列表。我编写了一个应用程序，将上传的文件保存到web.config中定义的目录中。当我向用户显示review页面时，我循环浏览目录中的文件并将其显示为列表

我现在认为，除了将文件保存到目录之外，还应该将文件作为二进制数据保存到实际的SQL Server。我试图避免假设情况

如果

• 工作人员意外地从目录中删除了一个文件
• 文件服务器崩溃（其他机构使用与我们相同的SAN）
• 工作人员将其他文件保存到同一目录中。纳税人不应该看到这些
• 导致我们不得不向纳税人请求另一份文件副本的任何其他情况（失败不是选项）

---

我担心保存到SQL Server数据库会产生我不知道的可怕后果，因为我以前从未在生产环境中这样做过。

微软研究院有一篇非常好的论文，名为

经过大量性能测试和分析，他们得出的结论如下：

• 如果图片或文档的大小通常小于256K，则将其存储在数据库

  VARBINARY

  列中会更有效

• 如果图片或文档的大小通常超过1MB，则将其存储在文件系统中会更高效（使用SQL Server 2008的

  FILESTREAM

  属性，它们仍然处于事务控制之下，并且是数据库的一部分）

• 在这两者之间，这取决于你的使用情况

如果您决定将图片放入SQL Server表中，我强烈建议您使用单独的表来存储这些图片-不要将employee foto存储在employee表中-将它们保存在单独的表中。这样，Employee表可以保持精简、平均和非常高效，前提是您不需要在查询中也选择Employee foto

对于文件组，请查看介绍。基本上，您可以从一开始就为大型数据结构使用单独的文件组创建数据库，或者稍后添加一个额外的文件组。我们称之为“大数据”

现在，无论何时创建需要存储

VARCHAR（MAX）

或

VARBINARY（MAX）

列的新表，都可以为大数据指定此文件组：

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

---

查看文件组上的MSDN简介，并使用它

我的电脑在提问时坏了。有些部分被删除了，请给我一点时间重新检查一下。不幸的是，我完全无法知道文件大小。我只知道我在上传大小上设置了15MB的任意上限。基于这一点，听起来我需要使用FS存储。@DougChamberlain：如果您的大多数文档都有超过1MB的机会（如果您的上限是15MB，很可能就是这种情况），那么是的，我想在文件系统中存储是更明智的方法