Sharepoint webservices

Question

私はSharepointポータル（Sharepoint Portal Server 2003 + SQL Server）をいくつか実行しており、どちらもcommomデータを共有する必要があります。私は2つの別々のリストを使って作業し、WSS Listsサービス（http://server/_ vti_bin/lists.asmx）を通してそれらを更新する責任があるWebアプリケーションを構築する予定でした。それが共謀慣行かどうか疑問に思っていますか？私はそのようなソリューションのスケーラビリティについて心配すべきですか？ - リストは毎月約3000レコードの割合で成長するはずです。

貧しいタイトルのため申し訳ありませんが、私はより良いものを考えることができませんでした。

Answer 1

あなたが構築しようとしているWebアプリケーションは、SharePoint Webアプリケーションではなく、単純にアプリケーションを収集したデータでリストを更新するSharePointを呼び出すASP.NET Webアプリケーションではありません。

これは完全に許容される方式です。リストWebサービスが意図しているものとまったく同じだと思います。

リストのデータをウェブアプリケーションに逆戻りさせなければならない場合は、苦労するかもしれません。双方向の同期は常にスティッキーなウィケットです。

Answer 2

はスケーラビリティに関係しているはずです。 WSS v3.0の土地では、コンテナ（別名フォルダ）あたり2000個のリストアイテムしか（おそらくは）格納することができません。フォルダはリストアイテムとしてカウントされます。

フォルダごとに2000個のアイテムをネストすると、潜在的に何百万もの規模に拡大することができますが、それでもデータを格納するのは難しい方法です。

さらに、すべてのアイテムを取り出して、作成したフォルダ階層を平坦化して、一部のCAMLで拡張するのに役立ちますが、もう一度拡張性の高い大きなリストをクエリする方法があります。私はreading the resources amalgamated here by Joel Olesonを提案します。

私は申し訳ありませんより具体的なドキュメントを見つけることができませんでしたが、リストはSPS 2003のいずれかにより優れていますか？

Answer 3

マイクロソフトがwhite paperに更新したため、コンテナごとに3000が推奨されます。これは実際には厳しい制限ではありません。これは重要なパフォーマンスヒットを見る前に保存できる最大値です。その多くのアイテムで、あなたは間違いなく複数のフォルダにあなたのリスト項目を分割する戦略を考え出すでしょう。

ホワイトペーパーのリリース以降に更新されていませんが、planning for software boundriesのMicrosoftの公式リンクはこちらです。

Answer 4

Coreyに記載されているように、フォルダごとの2000（または3000）項目はハード制限ではなく、推奨限度です。私はそれが実際にフォルダやインデックスごとに2000/3000のアイテムだと思います。したがって、列のインデックスを設定することもできます。また、推奨される範囲内にあるインデックスの値よりも2000個以下のインデックスの値を持つこともできます。私はフォルダーなしで40kアイテムを持っていて、それでも実行できます。