我必须为以下任务找到设计决定：
我有一个SQL Server数据库，它包含一个订单表。用户可以通过从网页上传的简单文件上传PDF文档并将其分配给订单。每个订单不超过一个文档（可能没有文档，从不超过一个）。为此，用户打开网页，输入订单号，显示订单并单击上传按钮。所以我知道上传的文件属于哪个订单。
现在我正在考虑将两种文件存储在网络服务器上的选项：
1）通过varbinary（MAX）列扩展我的订单表，并将PDF文档直接存储到该二进制字段中。
2）将PDF文件保存在磁盘上的特定文件夹中，并为其指定与订单相关的唯一名称（例如，我的订单号是数据库中的主键，或者是我可以存储在另外的GUID）订单表的列）。也许我必须将文件存储在子文件夹中，每月一个，并将子文件夹名称存储到数据库的订单行中，以避免在一个文件夹中获得过多的文件。
存储PDF文件后，可以在输入相关订单号后通过浏览器下载和查看。
我倾向于选项（1），因为数据管理似乎更容易让我在一个数据库中拥有所有相关数据。但是我有点担心随着时间的推移我会遇到性能问题，因为我的数据库大小会比使用solution（2）快得多。大约90％甚至95％的数据库总大小仅由那些存储的PDF文件组成。
以下是一些其他信息：
（我知道在使用上述数字大约2年后，我将达到SQL Server Express版本的4GB限制。但是我们可以忽略这一点，从数据库中删除旧数据或升级到完整许可证将是一个可能的选择。）
我的问题是：选项的Pro和Contras是什么？你会推荐什么？也许有人有类似的任务，可以报告他的经历。
提前感谢您的回复！
相关：
答案 0 :(得分：22)
对于SQL Server 2008，当您的文档大小大小为1 MB或更大时，建议使用FILESTREAM功能。这是基于Microsoft Research发布的一篇名为To BLOB or not to BLOB的论文，该论文分析了在数据库中存储blob的优缺点 - 很棒的阅读！
对于平均小于256K的文档，将它们存储在VARBINARY(MAX)列中似乎是最合适的。
介于两者之间的任何事情都是一种折腾，真的。
你说你的PDF文档大多在100K左右 - ＆gt;那些将非常好地存储到SQL Server表中，没问题。您可能想要考虑的一件事是为链接到主要事实表的文档提供单独的表。这样，事实表的使用速度会更快，并且文档不会妨碍您的其他数据。
答案 1 :(得分：2)
多次询问有关存储图像的问题，但对这些图像的讨论仍然适用：
答案 2 :(得分：1)
我还会为文档创建一个单独的表，这样文档检索的搜索数据/关键字段将更加可缓存。在插入或下载期间，数据库需要触摸文档表的唯一时间。
答案 3 :(得分：1)
我建议AGAINST在SQL中存储文件。检索文件时会增加额外的开销。 IIS在提供文件方面非常高效，但是使用SQL是您现在已经引入瓶颈的存储工具，因为您现在必须从Web服务器跳到SQL Server并返回以获取文件。
当您将文件存储在网络服务器上时，您的流程可以根据您列出的条件确定相应的文件，指向并提供服务。 Documentum和Alfresco等文档管理系统将文件存储在共享上，这使您可以非常灵活地进行备份和冗余存储。
答案 4 :(得分：0)
我怀疑在SQL中存储大blob，假设sql页面大小是4k（关闭螺母）..它必须在将文件提供给用户时在nK块中组装整个文件的片段..我不是确定是否是这种情况。
答案 5 :(得分：0)
我们遇到了类似的情况，尽管原则上只是。我们需要一种方法，通过该方式可以通过网页上的链接访问存储到SharePoint的文档。由于一切都是基于项目的，具有唯一的项目编号，因此解决方案是为文档实现通用的命名约定。 s网页是在服务器端创建的，链接是动态创建的。代码采用SharePoint服务器的基本路径，然后添加项目编号和文档的详细信息。
示例：
[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]