我有几个 Sharepoint 门户（Sharepoint Portal Server 2003 + SQL Server）正在运行，它们都应该共享一些公共数据。我计划使用两个单独的列表，并构建一个 Web 应用程序，负责通过 WSS 列表服务 ( http://server/_ vti_bin/lists.asmx) 更新它们。我想知道这是否是一种常见的做法？我应该担心这种解决方案的可扩展性吗？- 该列表应该以每月约 3000 条记录的速度增长。
抱歉标题很差，我想不出更好的标题。
Claudio
问问题
269 次
4 回答
1
正如 Corey 所提到的，每个文件夹 2000（或 3000）个项目不是硬性限制，而只是推荐的限制。我相信每个文件夹或索引实际上是 2000/3000 个项目。因此，您也可以为列设置索引，并且如果每个索引值只有 2000 个或更少的项目，那么您也可以在推荐范围内。我之前有 40k 个项目没有文件夹，它仍然可以执行。
于 2009-03-05T15:25:41.940 回答
1
如果我正确理解您将要构建的 Web 应用程序不是 SharePoint Web 应用程序，它只是一个 ASP.NET Web 应用程序，它将调用 SharePoint 以使用您的应用程序可能收集的数据更新列表。
这是一个完全可以接受的方案，我认为这正是列表 Web 服务的用途。
您可能遇到的唯一棘手问题是，您是否必须将其中一个列表中的数据回传回您的 Web 应用程序。双向同步始终是一个棘手的检票口。
于 2009-03-05T06:28:25.007 回答
1
您绝对应该关注可伸缩性。在 WSS v3.0 中，每个容器（又名文件夹）只能（假设）存储 2000 个列表项。一个文件夹算作一个列表项。
如果您在每个文件夹中嵌套 2000 个项目，您可能会扩展到数百万个，但它仍然是存储数据的一种尴尬方式。
您仍然可以拉出所有项目，展平您创建的任何文件夹层次结构，以帮助您使用一些 CAML 进行扩展，但再次有查询大型列表的方法可以更好地扩展。我建议阅读 Joel Oleson 在这里合并的资源。
很抱歉，我找不到更具体的文档，但我怀疑列表在 SPS 2003 中是否会更好地扩展。
于 2009-03-05T06:39:19.317 回答
1
The new recommendation is 3000 per container as Microsoft updated in this white paper. This isn't actually a hard limit. It is just the maximum you can store before seeing a significant performance hit. With that many items, you will definitely want to come up with a strategy of splitting your list items into multiple folders.
Here is Microsoft's official link on planning for software boundries although it hasn't been updated since the release of the white paper.
于 2009-03-05T14:38:40.757 回答