我目前处于文档管理系统开发的分析阶段，这将是来自许多应用程序的文档的唯一入口点。文件的大小和数量取决于应用程序。例如，其中一个将在一年内拥有 500,000 个文档，其中 468,000 个文档的大小小于 256 KB。乍一看，来自其他应用程序的文档大小可能是异构的
我提出的解决方案是创建一个 WCF Web 服务，充当外部应用程序和 SQL Server 之间的中间件，以便：
- 当 INSERT 文档
- 外部应用程序会将应用程序 GUID 和文档作为字节 [] 发送到 WCF
- WCF 会将文档插入数据库，并将唯一的 GUID 返回给 WCF，WCF 又会将其传递给外部应用程序以存储在自己的数据库中。
- 当 SELECT 文件
- 外部应用程序会将文档 GUID 和应用程序 GUID 发送到 WCF，Web 服务会查询数据库并返回包含文件内容的字节流
高层架构如下（通过实体框架 6 访问数据）：
在考虑了各种替代方案后，我们选择使用 Filestream（截至 2008 年）和 FileTable（截至 2012 年）的功能。
从这个解决方案的数据库架构的角度来看，我对此表示怀疑，并且我担心数百万个文档存储在 FileTable 中时的未来性能（这也是我客户的主要关注点）。我不知道这种类型的功能（Filestream 和 FileTable）是否会影响小文件的性能。根据我在 Microsoft、MVP 等的不同博客中所读到的内容，他们建议对于小文件（小于 256 KB）在表中更好地存储为 VARBINARY(MAX)，如果文件为 1MB 或更大，则使用 Filestream。
我从未使用过 Filetable 和 Filestream，所以我不知道这种方法的性能。一年之内，多达 6 个不同的应用程序将在此存储库中转储文档，预计一年内将增长约 500 万个文档，这些文档的文件大小是异构的，而且乍一看无法确定。
对于实施，我提出了以下建议：
- WCF 中的逻辑是，根据大小，文档存储在 VARBINARY 或表 FileTable 类型中。我会创建 2 个文件组（一个用于文件 <= 1MB，另一个用于 > 1MB）
- 拥有与应用程序一样多的文件表和同样多的文件组。在有六个外部应用程序的情况下，我将有 6 个 FileTable，每个都有自己的 FILEGROUP，但在这种情况下，我不会区分每个文件大小，而是应用程序。
在上述之后，我需要有关此解决方案架构的建议以及有关硬盘、RAM、处理器等特性的建议。