Sharepoint 网络服务
我有几个正在运行的 Sharepoint 门户（Sharepoint Portal Server 2003 + SQL Server），它们应该共享一些通用数据。 我计划使用两个单独的列表，并构建一个 Web 应用程序，负责通过 WSS 列表服务 (http ://server/_ vti_bin/lists.asmx）。 我想知道这是否是一种常见做法？ 我应该担心这种解决方案的可扩展性吗？ - 该列表应以每月约 3000 条记录的速度增长。
抱歉，这个标题不好，我想不出更好的标题了。
I have a couple of Sharepoint portals (Sharepoint Portal Server 2003 + SQL Server) running and they should both share some commom data. I was planning on working with two separate lists, and build a web app that will be responsible for updating them both throught the WSS Lists Service (http://server/_ vti_bin/lists.asmx). I'm wondering if that's a commom practice? Should I be concerned about the scalability of such solution? - the list should grow at a rate of ~3000 records per month.
Sorry for the poor title, I couldn't think of a better one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
新建议为每个容器 3000 个，因为 Microsoft 在此 白皮书。 这实际上并不是一个硬性限制。 这只是在性能受到重大影响之前可以存储的最大值。 有了这么多的项目，您肯定会想出一个策略，将列表项目拆分到多个文件夹中。
这是微软关于软件边界规划的官方链接，尽管它还没有'自白皮书发布以来未进行过更新。
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.
正如 Corey 提到的，每个文件夹 2000（或 3000）个项目并不是硬性限制，而只是建议的限制。 我相信每个文件夹或索引实际上有 2000/3000 个项目。 因此，您也可以为列设置索引，如果每个索引值只有 2000 个或更少的项目，也超出了建议的范围。 我之前有过 40k 个项目，没有文件夹，但它仍然可以执行。
As Corey mentions, the 2000 (or 3000) items per folder is not a hard limit, but just a recommended limit. I believe it is really 2000/3000 items per folder or index. So, you can set up indexes for your columns as well and if you just have 2000 items or less per index value than you are within the recommended range as well. I have had 40k items before without folders and it can still perform.
如果我理解正确的话，您将构建的 Web 应用程序不是 SharePoint Web 应用程序，而只是一个 ASP.NET Web 应用程序，它将调用 SharePoint 以更新列表，其中包含您的应用程序可能收集的数据。
这是一个完全可以接受的方案，我认为这正是列表 Web 服务的目的。
您可能遇到的唯一棘手问题是，您是否必须将其中一个列表中的数据回传到您的 Web 应用程序中。 双向同步始终是一个棘手的问题。
If i understand correctly the web app you will be building is NOT a SharePoint web application, simply an ASP.NET web app that will call into the SharePoint to update lists with data presumably collected by your application.
This is a perfecty acceptable scheme, I think its exactly what the list web services are intended for.
The only trickiness you may run into is if you have to back-haul data from one of the lists back into your webapplication. Bi-directional synchronization is always a sticky wicket.
您绝对应该关注可扩展性。 在 WSS v3.0 中，每个容器（也称为文件夹）只能（据说）存储 2000 个列表项。 文件夹算作一个列表项。
如果每个文件夹嵌套 2000 个项目，则可能会扩展到数百万个项目，但这仍然是一种尴尬的数据存储方式。
您仍然可以拉出所有项目，展平您创建的任何文件夹层次结构，以帮助您使用一些 CAML 进行扩展，但再次有一些方法可以更好地查询扩展的大型列表。 我建议阅读 Joel Oleson 在此合并的资源。
很抱歉，我找不到更具体的文档，但我怀疑列表在 SPS 2003 中是否能更好地扩展。
You should definitely be concerned with scalability. In WSS v3.0 land you can only (supposedly) store 2000 list items per container (aka folder). A folder counts as a list item.
If you nest 2000 items per folder you can potentially scale into the millions, but still it's an awkward way to store data.
You can still pull all the items out, flattening any folder hierarchies that you've created to help you scale with some CAML, but once again there's ways of querying large lists that scale better. I would suggest reading the resources amalgamated here by Joel Oleson.
I'm sorry I couldn't find more specific documentation, but I doubt lists will scale any better in SPS 2003.