sql-server - SQL Server 2008 中存储文档的最佳策略

Question

我们的一个团队将开发一个应用程序来将记录存储在 SQL2008 数据库中，并且每条记录都将有一个关联的 PDF 文件。目前大约有 340GB 的文件，其中大多数(70%)约为 100K，但也有一些文件大小为几兆字节。数据主要是插入和读取，但文件有时会更新。我们正在讨论以下选项:

1. 将文件作为 BLOB 存储在数据库中。

2. 将文件存储在数据库外部并将路径存储在数据库中。

3. 使用SQL2008的Filestream功能来存储文件。

我们已经阅读了 Microsoft 关于文件流数据的最佳实践，但由于文件大小各异，我们不确定选择哪个路径。我们倾向于选项 3(文件流)，但有一些问题:

1. 考虑到上述数据量和文件大小，您会选择哪种架构？

2. 数据访问将使用 SQL 身份验证(而不是 Windows 身份验证)完成，并且 Web 服务器可能无法使用 Windows API 访问文件。这会让 filstream 的性能比其他两个选项更差吗？

3. 由于 SQL 备份包含文件流数据，这将导致非常大的数据库备份。其他人如何处理具有大量文件流数据的数据库备份？

Answer 1

好的，我们开始吧。选项 2 是一个非常糟糕的主意 - 您最终会得到不可测试的完整性约束，并且不能保证每个定义的备份一致，因为您无法进行时间点备份。在大多数情况下这不是问题，但当您进行更复杂的(时间点)恢复时，它就会变成问题。

选项 1 和 3 相当相同，尽管有一些影响。

• 文件流可以使用更多的磁盘空间。基本上，每个版本都有一个 guid，如果您进行更新，旧文件将保留到下一次备份。

• OTOH，这些文件不计为数据库大小(精简版 - 如果您使用它，则不违反 10GB 限制)，并且可以使用文件共享进一步访问。这增加了灵 active 。

• 在数据库中，有关访问的选项最有限(Web 服务器无法在从 sql 获取路径后打开文件 - 它必须通过 sql 协议(protocol)层传输完整的文件)，但有文件(数量)较少的优点。将 blob 放入单独的表中，并将其放入一组单独的主轴中可能是一个策略性的好主意。

关于您的问题:

1:我会选择数据库存储。尝试两者 - 文件流和非文件流。由于您无论如何都使用相同的 API，因此这只是表定义中的一个简单更改。

2:是的，比直接文件访问更糟糕，但它比直接文件访问受到更多保护。否则，我认为文件流和 blob 不会产生显着差异。

3:你们哪里有大量的备份？抱歉，您的 340GB 并不是一个大型数据库。无论如何你都需要备份它。最好在一种一致的状态下完成，这就是通过数据库存储实现的目标。加上完整性(没有人会在不清理数据库的情况下意外删除未使用的文档)。数据库并不比进行拆分时大得多，而且它是一个简单的单处备份。

最后，问题是数据库完整性和备份的难易程度。除非您变得很大，否则 SQL Server 会获胜 - 这意味着 360 TB 的数据。