SharePoint 2007：列表理论问题

Question

我正在围绕MOSS 2007编写解决方案。并在列表中存储相当大量的数据。

我的第一个问题是：列表可以处理大量数据 - 大约20万个项目。现在我已经读过它，看起来列表的局限性在于视图可以显示的项目数（2000）。所以问题是：这是推荐还是真正的限制？没有文件证实这一点。

第二个问题，如果它对视图可以显示多少项有实际限制，这是否意味着无法检查包含大量数据的共享点列表中的重复项？

在执行wsList.getListItems的意义上，您必须传递视图（如果列表包含100 000条记录，并且视图只能包含2000条记录），如何检查重复项？

由于

Answer 1

巨大的列表性能

您可能需要阅读“Scaling to Extremely Large Lists and Performant Access Methods”和“Best Practices for LARGE SharePoint Lists and Documents Libraries”。

本文的另一件事没有提到使用SPList.Items.Add添加列表项，因为在大型列表中它是一个巨大的性能压力。你所做的是build efficient query，它不会返回任何项目，然后将项目添加到该集合中（我正在读取web服务在添加项目时表现良好，但是我找不到该文章了。）

您还可以see some tests（或other tests）了解巨额列表的执行情况。

至于重复

您可能希望创建在晚上运行somwhere并检查重复项的计划作业（SPJobDefinition）。

比循环所有SPListItem然后查询每个项目的查询列表以检查重复项更好的想法可能是为所有项目获取DataTable（SPListItemCollection.GetDataTable()）并使用某种技术来确定重复项。

至于视图

过滤项目，以查看相关项目并定义RowLimit。这是观点的关键 - 你只需要最相关的项目，不是吗？

Answer 2

你可以拥有非常大的名单，但性能会变成SUCK。

我们在项目中列出了50,000多个项目，我们发现查询和处理内容的最佳方式是使用SPSiteDataQuery和CrossListQueryCache并在晦涩难懂的SharePoint中格式化查询{ {3}}方言。

Answer 3

如果可能将项目分解为像文件夹这样的容器有助于提高性能。如果其中一个列表项字段是某种类型的分类查找，则可以通过将项目放在该分类类型的文件夹中来替换它。