moss-您会选择-120+个附加列,还是一个单独的链接列表?

我有一个设计难题,我可以利用一些反馈,所以我希望我的SharePoint专家同事可以帮助我解决这个问题。

我正在一个单一的moss列表(列表1)中管理一组项目,其中“项目名称”列将被视为相关列表的“主键”(至少在我看来是这样)。每个项目都将有一组定义的可交付成果(每个项目生命周期内多达37个独立活动),每个可交付成果将跟踪一个建议在项目期间完成的重要活动。

我最初的想法是在单独的“查找列表”(列表2)中定义37个可交付结果,以便每个可交付结果不仅有一个“可交付结果名称”,而且:

“url”-链接到一个单独的非moss wiki,在那里用户可以找到关于如何完成可交付结果的更多信息。 “描述”—快速解释可交付结果的含义(无需将用户发送到单独的服务器以获取任何详细信息) “项目阶段”—帮助我们筛选和排序可交付成果,使其按要求的顺序完成。 “角色”—确定负责完成可交付结果的主要项目角色

然后我将在另一个列表(列表3)中创建单独的项目,每个项目都与(1)项目和(2)可交付结果查找列表中的“模板”项目关联,以便我们可以跟踪每个项目/每个可交付结果字段的其他项目:

“完成日期”—可交付成果完成的日期(如有) “如何处置”—下拉列表,用户可以从中选择状态,如“已完成”、“已推迟”、“不适用”或“仍在处理中” “说明”—自由格式的文本,用于记录有关所做工作和原因的更多解释/理由。

此方法的一个主要问题是,Microsoft的最佳实践指南强烈反对列表中包含>2000项的Moss列表。即使我们从未在每个项目中添加过更多的可交付成果,但我担心我们将在很短的时间内扩展到54个项目之外(允许的项目数=2000/37)。从理论上讲,创建列表3的多个实例是可能的,但我觉得这是实现自动化的噩梦(随着我的跟踪项目集的增长)。

我能想到的第一个备选方案是在项目列表中预先定义37个附加列,再加上启用“日期”、“处置”和“注释”字段所需的(37 x 3)列,用户将需要跟踪每个可交付结果。此外,还必须管理每个SPD表单和Web部件页的脆弱配置/设计,我想使用这些页面“整理”所有这些数据输入和数据管理的UI。

另一种替代方法是为每个项目创建子站点,并在项目子站点的单个列表中列出项目的可交付结果。在我看来,这是非常沉重的,我认为这只是我最后的选择。

你们中的任何人如何在moss中实现这一点(不依赖外部数据库,也不依赖任何必须安装到服务器上的代码)?是否有一些诀窍可以让这个工作,这在通常的moss列表功能中并不明显?我应该使用苔藓的一些隐藏特征吗?我还没有发现SharePoint Designer的一些简洁方面?我 有 相信其他许多人也面临着同样的局限,并且已经发现 一些 让它发挥作用。我很感激你们提出的任何建议-提前谢谢!