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

前端之家收集整理的这篇文章主要介绍了sql-server – 在SQL Server 2008中存储文档的最佳策略前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们的一个团队将会开发一个在sql2008数据库中存储记录的应用程序,并且这些记录中的每一个将具有关联的PDF文件.目前有大约340GB的文件,其中大部分(70%)大约是100K,但有些是几兆字节大小.数据主要是插入和读取,但是文件有时更新.我们正在辩论以下选项:

>将文件作为BLOB存储在数据库中.
>将文件存储在数据库之外,并将路径存储在数据库中.
>使用sql2008的Filestream功能来存储文件.

我们已经阅读了关于filestream数据的Micrsoft最佳做法,但由于文件的大小有所不同,我们不确定选择哪个路径.我们倾向于选项3(filestream),但有一些问题:

根据上述数据和文件大小,您会选择哪种架构?
>数据访问将使用sql身份验证而不是Windows身份验证完成,并且Web服务器可能无法使用Windows API访问文件.这会使filstream比其他两个选项更糟吗?
>由于sql备份包括filestream数据,这将导致非常大的数据库备份.其他人如何使用大量的数据流数据来备份数据库

解决方法

好的,我们走吧.选项2是一个非常糟糕的主意 – 最终导致不可靠的完整性约束和不能保证每个定义一致的备份,因为您无法及时备份.在MOST情景中并不是一个问题,当您有一个更复杂(时间点)恢复的时刻,它变成了一个.

备选方案1和3是相当平等的,尽管有一些影响.

> Filestream可以使用更多的磁盘空间.基本上,每个版本都有一个guid,如果你更新旧的文件,直到下一个备份.
> OTOH这些文件不会算作数据库大小(快速版 – 不要使用10gb限制),使用文件共享进一步降低访问权限.这增加了灵活性.
>在数据库中有关于访问的最有限的选择(没有办法让Web服务器在从sql获取路径之后打开文件 – 它必须通过sql协议层漏斗完整的文件),但是具有以下优点:较少的文件(数字).将斑点放在一个单独的表中,一个单独的一组主轴可能在战略上是一个好主意.

关于你的问题:

1:我会和数据库存储一起去.尝试两个 – filestream而不是.当您使用相同的API时,这是表定义中的简单更改.

2:是的,比直接文件访问更糟糕,但比直接文件访问更受保护.否则我不认为filestream和blob有显着差异.

3:你在哪里有很大的备份?不好意思,但是你的340gb并不是一个大数据库.而且你需要备份它任何东西.更好地在一个一致的状态,这是您实现与db存储.加上完整性(没有人偶然删除未使用的文档而不清理数据库).数据库不会比分割大得多,而且它是一个简单的一个备份.

最后,问题是数据库的完整性和易用性. Win Server for sql Server除非你变大 – 这意味着360 TB的数据.

猜你在找的MsSQL相关文章