MOSS --您会选择哪一种-- 120+附加列，还是单独的链接列表？
我有一个设计难题，我可以利用一些反馈，所以我希望我的同事SharePoint专家可以帮助我解决这个问题。
我正在管理一个单独的MOSS列表(List1)中的一组项目，其中“项目名称”列将被视为相关列表的‘主键’(至少在我看来是这样)。每个项目将与其相关一套明确的可交付成果(在每个项目的整个生命周期内至多有37个单独的活动)，每个交付品将跟踪建议在项目期间完成的一项重要活动。
我最初的想法是在一个单独的‘查找列表’(List2)中定义37个可交付产品，这样每个可交付产品不仅有一个“可交付的名称”，而且：
"URL“--链接到单独的非MOSS wiki，用户可以在其中找到更多关于如何完成可交付”描述“的信息--快速解释可交付产品意味着什么(而不必将用户发送到另一台服务器获取任何细节)”项目阶段“--帮助我们筛选和排序可交付的内容，使其符合完成”角色“的顺序--以确定拥有可交付结果完成的主要项目角色。
然后，我将在另一个列表(List3)中创建单独的项，每个项都与(1)项目和(2)“可交付品查找列表”中的“模板”项相关联，这样我们就可以跟踪每个项目/每个可交付领域中的其他项目：
“完成日期”-完成交付品的日期(如果有的话)- "How“-下拉列表，用户可以从中选择”已完成“、”延迟“、"n/a”或“仍在处理中”的"Notes“等状态-免费形式的文本记录更多关于所做事情和原因的解释/理由。
这种方法的一个主要问题是，Microsoft的最佳实践指南强烈阻止了列表中> 2000项的MOSS列表。即使我们从未在每个项目中增加更多的可交付成果，我也担心我们会在很短的时间内扩展到超过54个项目(其中有多少项目“允许”= 2000/37)。从理论上讲，创建多个List3实例是可能的，但我认为自动化(随着我的跟踪项目集的增长)是一场噩梦。
我能想到的第一个选择是预定义项目列表中的37个额外列，加上启用“日期”、“处理”和“备注”字段所需的(37x3)列，用户将需要跟踪每个可交付的内容。此外，还必须管理每个SPD表单和web部件页的脆弱配置/设计，我想使用这些配置/设计来“美化”所有这些数据输入和数据管理的UI。
另一个向我建议的备选方案是为每个项目创建子站点，并在项目子站点中的单个列表中列出项目的可交付成果。对我来说似乎是个重量级人物，我认为这只是我的最后一招。
在MOSS (不依赖于外部数据库或任何必须安装到服务器上的代码)中，你们中的任何人会如何做到这一点？做这个工作有什么诀窍吗，从通常的MOSS列表功能来看，这并不明显？我应该使用的苔藓有什么隐藏的特征吗？SharePoint设计师的一些整洁的方面我还没有发现？我不得不相信，其他许多人也面临着同样的限制，并想出了一些办法来使它发挥作用。我很感激你们能提出的任何想法-谢谢！
回答 4
Stack Overflow用户
发布于 2009-03-26 13:26:16
根据我的经验，每个容器> 2000项(列表、文件夹、索引项)并不是世界末日。更糟糕的是，如果您开始使用多个相互链接的列表(通常通过查找)。然后，当您想要根据其父文件中的值过滤一个不属于查找的值时，它就会变得非常痛苦。如果连接中包含了大量记录，则对此数据的报告可能会非常缓慢。
在过去，我倾向于使用第三种范式，但这并不能很好地处理SharePoint列表，所以我会考虑一个相当平坦的结构。但是，如果你有一对多的关系，你通常会想要使用单独的列表。
Stack Overflow用户
发布于 2009-03-26 13:47:13
Microsoft的最佳实践表明，出于性能考虑，视图中的项不应超过2000项；您完全可以在列表中包含数百万项，但您应该谨慎地定义视图和使用索引列，以便一次只返回少于2000个项。
如果列表数据不经常更改，而且服务器上有大量可用内存，那么查询列表的PortalSiteMapProvider是值得一看的。有关查询列表的各种方法和完整的比较白皮书的更多信息可以找到这里。
干杯!
Stack Overflow用户
发布于 2009-03-26 20:19:09
我建议对每个项目使用子站点或站点集合。可以定义元项目站点，它可以汇总项目站点的重要信息。然后，项目站点不仅可以存储可交付的内容，还可以成为项目协作的焦点。
MS的建议是，如果您使用超过50,000个站点集合，则性能开始受到影响，因此有一些灵活性。当存储许多文档时，子站点可能很快变得无法管理，因为当内容数据库变得太大时，无法在内容数据库之间移动子站点。
我认为每个项目架构的站点集合会给您提供更大的灵活性，并避免使用复杂的查找列表带来的棘手问题。然而，它将依赖于一些相当聪明的搜索结果webpart。
https://stackoverflow.com/questions/684557
复制相似问题
腾讯云开发者
