SharePoint流言终结者:一个文档库里面的文件数量不能超过2000吗?

在SharePoint平台上的众多流言中,这一定是流传得最广的流言之一:不要在一个文档库中存放超过2000个的文件(对应到列表,可以被描述成:不要在一个列表中存放超过2000个列表项)。

好吧,以下是一些供你参考的信息:

1、这里没有一个实际的硬性限制,所以用户的确可以在一个文档库中存放远远超过2000个的文件。一个拥有子文件夹的文档库(列表)可以存放500万个文件(列表项)。

2、微软提供的最佳实践是:如果在一个文件夹下存放超过2000个文件(列表项),文件夹载入的性能将随着文件数量的增加而线性下降。微软对各种使用场景进行了大量的测试,请参考白皮书《Working with Large Lists in Office SharePoint Server 2007》

3、根据第2条,如果你使用SharePoint内置的列表视图来展现文档库(列表),在一个文件夹下面最好不要存放太多文件,但是我个人觉得这是一个很保守的数字,实际上,如果你的系统硬件不是特别差,你会发现即使在一个文件夹中存放远远超过2000个文件,也不会感到太多的性能下降。当然如果可能,最好在一个文档库中创建层级式的文件夹,然后就可以在一个文档库(列表)中存放远远超过2000的文件(列表项)。所以关于这个数字,我的建议是,在你的实际系统中进行一次评估测试,得到一个更实际的结果,这样你会更有把握。任何脱离评估测试的规划都是缺乏说服力的。

4、如果你使用了自定义界面来展现文档库(列表)数据,那么在代码中正确的使用分页查询,你应该可以在列表中直接存放很多的列表项(即使就放在一个文件夹里面),而不太受到性能的影响。

5、即使你像第4条所说的那样,正确的在代码中使用了分页查询,但是也要考虑由于一个文档库中所有的数据都存放在一个网站中,而一个网站位于一个网站集里面,一个网站集只能使用一个Sql Server Database,而不能将其内容分拆存放到多个Database中。这也就意味着,如果一个网站集里面存放的文件数量太多,那么其所在的Database也将变得极其庞大。你也许需要考虑那个Database最终会变得多大,它会占用多大的磁盘空间,会对SQL Server造成何种影响...关于磁盘容量规划,请参考这篇文章。如果你要存放大量的文件,考虑引入EBS或RBS

6、虽然SharePoint提供了列表,但并不意味着我们应该总是使用列表来替代数据库Table,它们各有各的好处。列表好在提供了一个内置的输入、编辑、展现界面,而且我们可以很容易的为列表数据添加诸如事件处理程序、工作流之类的东东。但是如果你的数据并不需要这些东东,而且大部分界面也需要定制,那么为什么不直接使用数据库Table?

7、如果可能,将文档库(列表)中的数据分区存放。例如,如果你有一个存放“费用报销单”的表单库,那么就可以考虑将3个月之前提交且已经审批完成的表单自动移动到其他文件夹(或其他表单库)里面,表单库的根文件夹则总是只存放最近3个月的表单。数据的自动归档可以使用SharePoint内置的过期管理策略或使用自定义代码来完成。

8、如果是SharePoint 2010系统,那么关于大容量文档库(列表),多了一个List Throttling功能。我会再写一篇blog专门讲述List Throttling。

最后总结,关于这个流言,其结论应该是:PLAUSIBLE。:)

posted on 2010-04-12 09:21  kaneboy  阅读(586)  评论(0编辑  收藏  举报

导航