在SQL Server中存储文件还是将它们保存在文件服务器上？
目前，我们有数千个Microsoft Word文件，Excel文件，PDF，图像等存储在文件夹/子文件夹中。 这些是由应用程序定期生成的，可以在该应用程序中随时访问。 在我们期待升级时，我们现在正考虑将所有这些文档存储在SQL Server 2005中。 这样做的原因是能够压缩文档，添加其他字段以存储有关这些文档的更多信息，并在必要时应用索引。
我想我所追求的是使用SQL Server作为文档存储库而不是将它们保存在文件服务器上的优缺点，以及您在执行此操作时可能获得的任何经验。
我们将使用C＃和Windows Workflow来完成此任务。
感谢您的意见。
编辑
文件有多大？
介于100k = 200k之间（平均70KB）
会有多少？
目前它有大约310万个文件（范围从Word / Excel和PDF），每天可以增加2,600个文件。 （增长也会随着时间的推移而增加）
读了多少？
这个很难量化，因为我们的旧系统/应用程序很难解决这个问题。
在类似职位上指出的另一个有用的链接涵盖了两种方法的利弊。
DB与FileSystem上存储的文件 – 优点和缺点
我会两个都有。
我会用一个唯一的名称重命名文件，因此更容易管理，我会保留数据库中的所有元数据（文件名，内容类型，文件系统上的位置，大小，描述等），所以文件是通过数据库（间接）访问。
好处：
- 文件很容易处理; 您可以在混合中携带多个驱动器
- 数据库可以保留任意数量的元信息，包括可以搜索的文件描述。
- 跟踪文件访问和其他统计信息
- 使用各种范例重新排列文件：树（目录结构），标签，搜索或上下文
您也可以对驱动器进行压缩。 您可以使用RAID进行备份和速度。
doc规则的经验法则是：
size < 256 kb: store in db 265 kb < size < 1 MB: test for your load size > 1 Mb: store on file system 编辑：这个经验法则也适用于SQL Server 2008中的FILESTREAM存储
如果您一直升级到SQL Server 2008，那么您可以使用新的FILESTREAMfunction，该function允许文档在表中显示为列，但作为文件驻留在共享上，可以直接访问它通过程序（如Word）。
我们在谈论什么样的文件？
在SQL服务器中存储文档可能很有用，因为您可以将文档与其他表关联起来并使用全文索引等技术并执行模糊搜索等操作。
缺点是创建文档备份可能有点困难。 使用NTFS压缩或其他技术也可以进行压缩。
这些文档是否基于文本，您是否计划使用SQL Server的全文搜索来搜索这些文档？ 如果没有，我认为将这些文件存储在数据库中没有任何好处。 当然，您始终可以将与文档相关的元数据（包括路径信息）存储到数据库中。
在数据库中使用stroing doc的一大好处是可以更轻松地控制对它们的安全访问，因为您可以通过应用程序中的访问控制来完成所有操作。 将它们存储在文件服务器上需要在文件和文件夹级别处理访问权限，以防止任何直接访问。 在数据库中使用它们可以进行单点备份，因此您可以更轻松地制作完整副本和/或在需要时移动它。
您可以考虑购买一个或使用WSS / SharePoint，而不是编写自定义DMS（文档管理系统），因为这将处理所有平凡的细节（存储，索引，元数据），并让您在顶部构建自定义function。