DCN*_*YAM 13 sql-server blob filestream sql-server-2008
我们的一个团队将开发一个应用程序来存储SQL2008数据库中的记录,并且每个记录都有一个相关的PDF文件.目前有大约340GB的文件,大多数(70%)大约是100K,但有些是几兆字节.数据主要是插入和读取,但文件有时会更新.我们正在讨论以下选项:
将文件存储为数据库中的BLOB.
将文件存储在数据库之外,并将路径存储在数据库中.
使用SQL2008的文件流功能来存储文件.
我们已经阅读了有关文件流数据的Micrsoft最佳实践,但由于文件大小不同,我们不确定选择哪条路径.我们倾向于选项3(文件流),但有一些问题:
考虑到上面提到的数据量和文件大小,您会选择哪种架构？
数据访问将使用SQL身份验证完成,而不是Windows身份验证,并且Web服务器可能无法使用Windows API访问这些文件.这会使filstream的表现比其他两个选项差吗？
由于SQL备份包含文件流数据,因此会导致非常大的数据库备份.其他人如何使用大量文件流数据处理备份数据库？
小智 7
好的,我们走了.选项2是一个非常糟糕的主意 - 您最终会遇到不可测试的完整性约束和备份,因为您无法进行时间点备份,因此无法保证每个定义的一致性.在MOST场景中不是问题,只要你有一个更复杂的(时间点)恢复,它就变成了一个问题.
选项1和3非常相同,尽管有一些含义.
OTOH文件不算作数据库大小(快速版本 - 如果您使用它,则不会违反10gb限制),并且使用文件共享可以进一步降低访问权限.这增加了灵活性.
在数据库中有关于访问的最有限的选项(Web服务器在从sql获取路径之后无法打开文件 - 它必须通过sql协议层汇集整个文件),但在具有较少的数据方面具有优势文件(数字).将blob放入一个单独的表中,并且一个单独的一组主轴可能在策略上是一个好主意.
关于你的问题:
1:我会在数据库存储中使用.试试两个 - 文件流而不是.无论如何,当您使用相同的API时,这是表定义中的一个简单更改.
2:是的,比直接文件访问更糟糕,但它比直接文件访问更受保护.否则我不认为文件流和blob会产生重大影响.
3:你在哪里有一个巨大的备份？很抱歉问,但你的340gb并不是一个大型数据库.无论如何你需要支持它.最好在一个一致的状态下执行,这是您使用数据库存储实现的.加上完整性(没有人在不清理数据库的情况下意外删除未使用的文档).数据库并不比进行拆分大得多,而且它是一个简单的一个地方备份.
最后,问题是数据库的完整性和易于备份的问题.除非你变大,否则赢得SQL Server - 这意味着360TB的数据.