我有一个设计难题，我可以使用一些反馈，所以我希望我的SharePoint专家可以帮助我解决这个问题。
我在一个MOSS列表（List1）中管理一组项目，其中“项目名称”列将被视为相关列表的“主键”（至少在我看来）。每个项目都会与一组定义的可交付成果相关联（每个项目的生命周期内最多37个单独的活动），每个可交付成果将跟踪建议在项目期间完成的一项重要活动。
我最初的想法是在单独的“查找列表”（List2）中定义37个可交付成果，以便每个可交付成果不仅仅具有“可交付名称”，还包括：
“URL” - 链接到单独的非MOSS维基，用户可以在其中找到有关如何完成交付的更多信息 “描述” - 快速解释可交付物的含义（无需将用户发送到单独的服务器以获取任何详细信息） “项目阶段” - 帮助我们对可交付成果进行过滤和排序，使其成为需要完成的顺序 “角色” - 确定拥有完成可交付成果的主要项目角色
然后我会在另一个列表（List3）中创建单独的项目，每个列表与（1）项目和（2）“可交付物查找列表”中的“模板”项目相关联，以便我们可以跟踪其他项目这些每个项目/每个可交付领域：
“完成日期” - 可交付成果完成的日期（如果有的话） “如何处置” - 一个下拉列表，用户可以从中选择“已完成”，“推迟”，“不适用”或“仍在进行中”等状态 “备注” - 自由格式文本，记录有关已完成内容和原因的更多解释/理由
这种方法的一个主要问题是，微软的最佳实践指南强烈反对MOSS列表＆gt;列表中有2000个项目。即使我们从未在每个项目中添加更多可交付成果，我担心我们会在非常短的时间内扩展到超过54个项目（我允许多少个项目= 2000/37）。从理论上讲，创建List3的多个实例是可能的，但让我感到自动化的噩梦（随着我的跟踪项目的增长）。
我能想到的第一个选择是在项目列表中预先定义37个附加列，以及启用用户的“日期”，“处置”和“注释”字段所需的（37 x 3）列将需要跟踪每个可交付成果。此外，还必须管理每个SPD表格的简化配置/设计。 web部分我想用来“漂亮”所有这些数据输入的UI的页面＆amp;数据管理。
有人向我建议的另一个选择是为每个项目创建子站点，并在项目的子站点的单个列表中列出项目的可交付成果。对我来说似乎非常重要，我只是把它当作我的最后一招。
你们如何在MOSS中解决这个问题（不依赖于外部数据库，或者必须安装到服务器的任何代码）？是否有一些技巧可以完成这项工作，这在通常的MOSS List功能中并不明显？我应该使用MOSS的一些隐藏功能吗？我还没有发现SharePoint Designer的一些简洁方面？我有相信许多其他人都面临同样的限制，并且已经找到一些的方式来使其工作。我很感激大家提出的任何想法 - 提前感谢！
答案 0 :(得分：4)
Microsoft的最佳做法指出，出于性能原因，视图中的项目不应超过2000个;您可以在列表中完美地拥有数百万个项目，但是您应该仔细定义您的视图和索引列的使用，以便一次只返回少于2000个项目。
如果列表数据不经常更改并且服务器上有大量可用内存，则值得查看PortalSiteMapProvider以查询列表。 有关查询列表的各种方法的更多信息和完整的比较白皮书可以找到here。
干杯！
答案 1 :(得分：1)
根据我的经验＆gt;每个容器2000个项目（列表，文件夹，索引项目）不是世界末日。更糟糕的是，如果您开始使用彼此链接的多个列表（通常通过查找）。当你想根据父节点中不属于查找的值过滤子节点时，它会变得非常痛苦。如果您在联接中涉及大量记录，则报告此数据可能会非常缓慢。
我过去的倾向是使用第三范式，但这对SharePoint列表不起作用，所以我会考虑一个相当扁平的结构。如果你有一对多的关系，你通常会想要使用单独的列表。
答案 2 :(得分：1)
我建议为每个项目使用子网站或网站集。 可以定义元项目站点，该站点可以汇总项目站点的重要信息。然后，项目站点可以存储的不仅仅是可交付成果，而是可以成为项目协作的重点。
MS建议如果您使用超过50,000个网站集，性能开始受到影响，因此有一些灵活性。当存储许多文档时，子站点可以迅速变得难以管理，因为当内容数据库变得太大时，没有好的方法在内容数据库之间移动子网站。我认为每个项目架构的网站集将为您提供更大的灵活性，并避免复杂查找列表中令人讨厌的问题。它依赖于一些相当聪明的使用搜索结果webpart。
答案 3 :(得分：0)
“列表中包含＆gt; 2000个项目的MOSS列表”
这不是问题，因为它只是您在视图中显示的内容。我认为MOSS不是一个开发平台，可以添加包含更多字段的复杂项目。我应该做一个普通的SQLserver ASP.NEt应用程序