Sharepoint网络服务

Question

我有几个Sharepoint门户（Sharepoint Portal Server 2003 + SQL Server）正在运行，它们应该共享一些通信数据。我计划使用两个单独的列表，并构建一个Web应用程序，负责通过WSS列表服务（http://server/_ vti_bin / lists.asmx）更新它们。我想知道这是不是一个普通的做法？我应该关注这种解决方案的可扩展性吗？ - 该列表应以每月约3000条记录的速度增长。

对于糟糕的头衔感到抱歉，我想不出更好的一个。

Answer 1

如果我理解正确，您将构建的Web应用程序不是SharePoint Web应用程序，只是一个ASP.NET Web应用程序，它将调用SharePoint以使用您的应用程序可能收集的数据更新列表。

这是一个完美的可接受方案，我认为它正是列表Web服务的目的。

您可能遇到的唯一棘手问题是，您是否必须将其中一个列表中的数据回传到您的Web应用程序中。双向同步总是一个棘手的小门。

Answer 2

您应该肯定关注可扩展性。在WSS v3.0版本中，您只能（据称）每个容器（aka文件夹）存储2000个列表项。文件夹计为列表项。

如果你为每个文件夹嵌套2000个项目，你可以扩展到数百万，但它仍然是一种存储数据的尴尬方式。

您仍然可以拉出所有项目，展平您创建的任何文件夹层次结构，以帮助您使用某些CAML进行扩展，但是再一次有查询大型列表的方法可以更好地扩展。我建议reading the resources amalgamated here by Joel Oleson。

对不起，我找不到更具体的文档，但我怀疑列表会在SPS 2003中更好地扩展。

Answer 3

微软在此white paper中更新后，每个容器的新建议为3000。这实际上不是一个硬限制。它只是您在看到重大性能影响之前可以存储的最大值。有了这么多项目，你肯定会想出一个将列表项分成多个文件夹的策略。

以下是微软在planning for software boundries上的官方链接，尽管自白皮书发布以来尚未更新。

Answer 4

正如Corey所提到的，每个文件夹的2000（或3000）项不是硬限制，而只是建议的限制。我相信每个文件夹或索引真的是2000/3000项。因此，您也可以为列设置索引，如果每个索引值只有2000个项目或更少，那么也在建议的范围内。我之前有没有文件夹的40k项目，它仍然可以执行。