在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。:)
好吧，以下是一些供你参考的信息：
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。:)
本文转自 kaneb0y 51CTO博客，原文链接：http://blog.51cto.com/kaneboy/294030，如需转载请自行联系原作者
扫一扫
5192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
