我有一个设计难题，我可以使用一些反馈，所以我希望我的 SharePoint 专家可以帮助我解决这个问题。
我在单个 MOSS 列表（List1）中管理一组项目，其中“项目名称”列将被视为相关列表的“主键”（至少在我看来）。每个项目将与一组已定义的可交付成果相关联（在每个项目的生命周期中最多有 37 项单独的活动），并且每个可交付成果将跟踪建议在项目期间完成的一项重要活动。
我最初的想法是在一个单独的“查找列表”（List2）中定义 37 个可交付成果，这样每个可交付成果不仅有一个“可交付成果名称”，而且还有：
“URL” - 链接到单独的非 MOSS wiki，用户可以在其中找到有关如何完成可交付成果的更多信息 “描述” - 快速解释可交付成果的含义（无需将用户发送到单独的服务器以获取任何详细信息）“项目阶段” - 帮助我们按照需要完成的顺序过滤和排序可交付成果 “角色” - 确定负责完成可交付成果的主要项目角色
然后我会在另一个列表 (List3) 中创建单独的项目，每个项目都与 (1) 项目和 (2) “可交付成果查找列表”中的“模板”项目相关联，这样我们就可以跟踪额外的这些每个-项目/每个可交付的字段：
“完成日期”——可交付成果完成的日期（如果有）进行中” “注释” - 自由格式的文本，用于记录有关所做工作和原因的更多解释/理由
这种方法的一个主要问题是 Microsoft 的最佳实践指南强烈反对列表中包含 > 2000 项的 MOSS 列表。即使我们从未向每个项目添加更多可交付成果，恐怕我们会在很短的时间内扩展超过 54 个项目（我“允许”的数量 = 2000/37）。创建 List3 的多个实例在理论上是可能的，但让我觉得自动化是一场噩梦（随着我跟踪的项目集的增长）。
我能想到的第一个选择是在项目列表中预定义 37 个附加列，加上启用用户需要的“日期”、“处置”和“注释”字段所需的 (37 x 3) 列跟踪每个可交付成果。再加上必须管理每个 SPD 表单和 Web 部件页面的脆弱配置/设计，我想用这些页面来“美化”所有这些数据输入和数据管理的 UI。
有人向我建议的另一种选择是为每个项目创建子站点，并在项目子站点的单个列表中列出项目的可交付成果。对我来说似乎非常重量级，我认为这只是我最后的手段。
你们中的任何人如何在 MOSS 中实现这一点（不依赖外部数据库，或任何必须安装到服务器的代码）？是否有一些技巧可以使这项工作正常进行，这在通常的 MOSS 列表功能中并不明显？我应该使用 MOSS 的一些隐藏功能吗？我还没有发现 SharePoint Designer 的一些简洁方面？我必须相信许多其他人也面临着同样的限制，并且已经找到了一些让它发挥作用的方法。我会很感激你们提出的任何想法 - 在此先感谢！