FileStreamを使用してSQLServer2008に多くの画像、ビデオ、ドキュメントを保存するかなり大きなソリューションがあります。ジオレプリケーションを利用するためにWindowsAzureBLOBストレージの使用への移行を開始しました。これは、varbinary（max）列を、ストレージアカウントを指すカスタムサブドメインに追加する相対URLに変更することを意味します。
これはすべて正常に機能し、テストには満足していますが、現在、ファイル名、拡張子、コンテンツタイプをvarbinaryデータとともに保存しています。
私の質問は、必要に応じてファイル拡張子がオンになる相対URLに移動する場合、この追加データを保存する必要があるかどうかです。私たちはオフィスで議論しており、コンセンサスはそれをシンプルに保ち、URLを保存することであるようです。
このシナリオでは、ほとんどの人が何をしますか？この追加データを保存することの用途/利点は何ですか？
これについてのあなたの考えに感謝します、おそらくこれを解決するのは外部の意見だけです。
私は、Azure に保存するファイルに関するメタデータを保持する傾向があります。これは、URI と共に SQL で役立つと思われます。
「役に立つ」とは？
これは、シナリオによって異なります。たとえば、(ops/監視の観点から) ファイル サイズを URI に対して保存すると、ファイル ストレージの使用状況を簡単かつ迅速に確認できるので便利です。ファイル拡張子/コンテンツタイプも保存します。基本的に、私はメタデータをローカルに保持しようとします。これにより、そうでなければ実際に離れて Azure と通信する必要がなくなります。a) 速度/パフォーマンスのため、b) API でのヒット数を最小限に抑える (したがって、コストを削減する - 本当にのみ)ヒット数が多い場合）
したがって、使用可能なファイルの詳細を必要とするレポートのニーズ/UI については、Azure の近くに行かなくても、有用なメタデータを作成できることを知っています。そして、実際に Azure に触れるのは、ファイルを取得する必要があるときだけです。
役立つと思われるものが2つあります。blobのアップロード時に設定できる各blobの「コンテンツタイプ」システムプロパティがあります（後で変更することもできます）。もう1つは、blobとのキーと値のペアの形式でカスタムメタデータを指定できることです。ただし、メタデータは検索できません。したがって、いくつかのカスタムプロパティに基づいてBLOBを検索する場合は、BLOB（SQLサーバー）の外部に格納する方がよい場合があります。メタデータのもう1つの点は、メタデータの最大サイズです。私が間違っていなければ、8KBの制限があります。