2

フィードバックを活用できる設計上の難問があるので、仲間の SharePoint 専門家がこれを解決するのを手伝ってくれることを願っています。

私は一連のプロジェクトを 1 つの MOSS リスト (List1) で管理しています。ここで、「プロジェクト名」列は、関連するリストの「主キー」(少なくとも私の頭では) として扱われます。各プロジェクトには、一連の定義済みの成果物 (各プロジェクトの存続期間全体で最大 37 の個別のアクティビティ) が関連付けられており、各成果物は、プロジェクト中に完了することが推奨される 1 つの重要なアクティビティを追跡します。

私が最初に考えたのは、37 の成果物を個別の「ルックアップ リスト」(List2) に定義して、各成果物に「成果物名」だけでなく、次の項目も含めることでした。

「URL」 - 別の非 MOSS wiki へのリンク。ユーザーは、成果物を達成する方法に関する詳細情報を見つけることができます。詳細を取得するための別のサーバー） 「プロジェクト フェーズ」 - 成果物をフィルタリングし、完了する必要のある順序で並べ替えるのに役立ちます 「役割」 - 成果物の完成を所有する主要なプロジェクトの役割を特定します

次に、別のリスト (List3) に個々のアイテムを作成します。それぞれのアイテムは、(1) プロジェクトと (2) 「成果物ルックアップ リスト」の「テンプレート」アイテムに関連付けられています。プロジェクト/成果物ごとのフィールド:

「完了日」 - 成果物が完了した日付 (ある場合) 「どのように処分されたか」 - ユーザーが「完了」、「延期」、「該当なし」、「まだ」などの状態を選択できるドロップダウン リスト「処理中」 「メモ」 - 何が行われたか、その理由についての説明/根拠を記録する自由形式のテキスト

このアプローチの大きな問題の 1 つは、Microsoft のベスト プラクティス ガイダンスが、リストに 2000 を超えるアイテムを含む MOSS リストを強く思いとどまらせることです。各プロジェクトにこれ以上成果物を追加しなかったとしても、非常に短期間で 54 プロジェクト (「許可されている」数 = 2000/37) を超えてスケ​​ールするのではないかと心配しています。List3 の複数のインスタンスを作成することは理論的には可能ですが、自動化するのは悪夢のように感じます (追跡するプロジェクトのセットが大きくなるにつれて)。

私が考えることができる最初の代替案は、ユーザーが必要とする「日付」、「処分」、および「メモ」フィールドを有効にするために必要な (37 x 3) 列に加えて、プロジェクト リストに 37 の追加列を事前定義することです。各成果物を追跡します。さらに、このすべてのデータ入力とデータ管理の UI を「きれいに」するために使用したい SPD フォームと Web パーツ ページの脆弱な構成/設計を管理する必要があります。

誰かが私に提案した別の代替案は、プロジェクトごとにサブサイトを作成し、プロジェクトの成果物をプロジェクトのサブサイトの単一のリストにリストすることです。私にはとてつもなく重いように思えます。これは私の最後の手段としてのみ考えています。

MOSS でこれを実現するにはどうすればよいでしょうか (外部データベースや、サーバーにインストールする必要のあるコードに依存することなく)。通常の MOSS List 機能からは明らかではない、これを機能させるためのトリックはありますか? 私が使用すべきMOSSの隠れた機能はありますか? まだ発見していない SharePoint Designer の素晴らしい側面はありますか? 他の多くの人がこれと同じ制限に直面し、それを機能させる方法を見つけたと信じなければなりません. 皆さんが提案できるアイデアをいただければ幸いです - 事前に感謝します!

4

4 に答える 4

4

Microsoftのベストプラクティスでは、パフォーマンス上の理由から、ビューに2000を超えるアイテムを含めることはできません。リストには数百万のアイテムを含めることができますが、ビューを慎重に定義し、インデックス列を使用して、一度に返されるアイテムが2000未満になるようにする必要があります。

リストデータが頻繁に変更されず、サーバーで使用可能なメモリが多い場合は、リストのクエリについてPortalSiteMapProviderを確認する価値があります。リストを照会するためのさまざまな方法と完全な比較ホワイトペーパーの詳細については、こちらを参照してください。

乾杯！

于 2009-03-26T13:47:13.853 に答える
1

私の経験では、コンテナ（リスト、フォルダ、インデックス付きアイテム）ごとに2000を超えるアイテムを使用することは、世界の終わりではありません。ただし、さらに悪いのは、相互にリンクされている複数のリストを使用し始めた場合です（通常はルックアップを介して）。次に、ルックアップの一部ではない親の値に基づいて子をフィルタリングする場合、大きな問題になります。結合に関係するレコードが多数ある場合、このデータのレポートは非​​常に遅くなる可能性があります。

これまでの私の傾向は、第3正規形を使用することでしたが、SharePointリストではうまく機能しないため、かなりフラットな構造を検討します。ただし、1対多の関係がある場合は、ほとんどの場合、個別のリストを使用することをお勧めします。

于 2009-03-26T13:26:16.230 に答える
1

プロジェクトごとにサブサイトまたはサイト コレクションを使用することをお勧めします。プロジェクト サイトの重要な情報をロールアップできるメタ プロジェクト サイトを定義できます。プロジェクト サイトは成果物だけでなく、プロジェクト コラボレーションの焦点にもなります。

MS のアドバイスでは、50,000 を超えるサイト コレクションを使用するとパフォーマンスが低下し始めるため、ある程度の柔軟性があります。コンテンツ データベースが大きくなりすぎた場合、コンテンツ データベース間でサブサイトを移動する適切な方法がないため、多数のドキュメントを格納すると、サブサイトはすぐに管理不能になる可能性があります。

プロジェクト アーキテクチャごとのサイト コレクションにより、柔軟性が向上し、複雑なルックアップ リストに関する厄介な問題を回避できると思います。ただし、検索結果 Web パーツのかなり巧妙な使用に依存します。

于 2009-03-26T20:19:09.187 に答える
0

「リストに2000を超えるアイテムがあるMOSSリスト」

これは、ビューに表示されるものであるため、問題ではありません。MOSSは、より多くのフィールドを持つ萌えの複雑なアイテムを追加するための開発プラットフォームではないと思います。通常のSQLserverASP.NEtアプリケーションを実行する必要があります

于 2009-04-03T21:07:55.973 に答える