MicrosoftがMOSSを構築してすべてのデータをSQL Serverデータベースに書き込む場合、開発のベストプラクティスはすべて、ファイルシステムなどのデータベースの外部にファイルを保存することを提案するのはなぜですか?Sharepoint MOSSカスタマイズされたvがカスタマイズされていない
すべて最高
MicrosoftがMOSSを構築してすべてのデータをSQL Serverデータベースに書き込む場合、開発のベストプラクティスはすべて、ファイルシステムなどのデータベースの外部にファイルを保存することを提案するのはなぜですか?Sharepoint MOSSカスタマイズされたvがカスタマイズされていない
すべて最高
これは哲学的な項目です。トランザクションの整合性は、ファイルをDBに格納する利点です。それには、トランザクションログを膨らませるなどの短所があります。
Sharepointの将来のバージョンでは、MSはあなたのため、パフォーマンスの問題のSQL 2008
のFILESTREAM機能を使って、「データベース外のファイルを格納するオプションを与え、場合、私は驚かないだろう。保存パフォーマンスを損なうだけで、ページレイアウトを取得するためのデータベースへのラウンドトリップです。
一方、パフォーマンスのためにローカルファイルシステム上のファイルを使用すると、カスタマイズオプションが減少します。
ウェブサイトのユーザーにこれらのファイルを編集させたい場合は、データベースにファイルを保存する必要があります。 SharePointは、これらのファイルのほとんどが編集可能であるように設計されているため、データベースに格納されています。
アプリケーション・アーキテクトとしては、ソリューション・リリース以外で使用頻度の高いファイル(ページ・レイアウト、マスターページなど)が編集されないことがわかっている場合、ファイル・システムにページを格納するオプションがあります。
ファイルシステムに格納すると、データベースの往復が不要なため、アクセスパフォーマンスが少し向上します。たとえば、Webページのすべてのページでマスターページが必要になるため、ファイルシステムに保存することで、ユーザーの要求が高いときにパフォーマンスが向上します。
SQL 2008にはデータベースの「外部」のファイルを管理する機能があるため、この機能はSharePointにとって望ましいものではありません。
SharePointページをカスタマイズしないでおくと、ページの1つのインスタンスが最初の実行時にコンパイルされ、メモリに保持され、同じ種類のすべてのページで再利用されます。カスタマイズされたページがこの動作を共有しない理由は、それらが一意であり、ApplicationDomainがdllを読み込むとアンロードできないためです。したがって、カスタマイズされたページはすべての要求で解析されます。
私は、と言っていますが、すべてのベストプラクティスでは、ファイルの格納にファイルシステムを使用する必要はありません。それは常に状況に依存します。単一のサーバーがある場合、ファイルシステムにファイルを格納することは問題ありませんが、ファイルが複数のサーバーに存在する必要がある場合は、レプリケーションを管理する必要があります。通常、データベースのバックアップは、データベースやファイルより簡単です。これらの状況はすべて管理できますが、柔軟に対応する必要があります。
「ベストプラクティス」はどこで手に入りましたか?
MSとMOSSの経験では、このようなベストプラクティスを聞いたことはありませんでしたが、非常に特殊な場合を除いては...私はこれは良い方法ではないと言います。
あなたのデプロイは、このように簡単ではありません...管理者ユーザーがどこ修正したファイルを見つけるために知っておく必要があり、バックアップは地獄のようなもの、など
しかし、私は...特にであってもよく言うようにそれは役に立つかもしれない。
ここでは、機能、ソリューション、マスターページ、レイアウト、ウェブパーツなどの開発について話しています.MVPのほとんどのテクニカルブック/記事では、ファイルシステムにファイルを保存することをお勧めします。 ;) – 78lro
SharePointには、ファイルシステムのキャッシュページングであるというと呼ばれる技術があります。
私はそのような "ベストプラクティス"を聞いていませんでした... 100%あなたに同意します。私はいつもすべてをコンテンツデータベースに入れようとします。 – Romias