私は、添付ファイルとその他のコンテンツを保存するための両方のメカニズムを実行した大規模なソフトウェアシステムに取り組んでいます。システムの最初の反復では、すべてのデータがDBのBLOBに格納されました。私はその時それを呪いました。プログラマーとして、サイドスクリプトを記述して、データをすぐに操作し、必要なときにいつでもデータを変更することができました。
約10年進んで、私はまだ同じソフトウェアを管理していますが、アーキテクチャが変更され、ファイルシステムポインタで記述されています。私は今それを呪い、それがDBに戻ってきたらいいのにと思います。私には数年の追加の利点があり、このアプリケーションをより多くのより大きな状況ではるかに大きな能力で働いてきたので、私の意見は今よりよく教育されていると感じています。アプリケーションのプロモーションまたはシステム移行には、何百万ものファイルの広範なスクリプト作成とコピーが必要です。あるとき、OSを変更し、すべてのファイルポインターのディレクトリ区切り文字が間違っていたり、サーバー名がファイルの場所で変更されたりして、週末にDBAで簡単なSQL更新ステートメントを記述してスケジュールしなければなりませんでした。もう1つは、ファイルシステムとDBレコードが同期しなくなることです。理由は不明ですが、数千日間の操作の後、非トランザクションシステム（ファイルシステムとDBはトランザクションコンテキストを共有しない）が単に同期しなくなることがあります。不思議なことにファイルが失われることがあります。
これらすべてがDBにある場合、移行または環境の促進はDBのダンプとインポートの問題でした。行の変更は適切に監査でき、同期しているすべてのものとログは、必要に応じて特定の時点で再生できます。確かにDBは大きくなりますが、2011年であり、これはデータベースにとっての課題ではありません。
一部のデータをストリーミングするときに大きなデータバッファーで同様の問題が発生したことの価値については、A）JDBCのInput | OutputStreamsを使用してバイトバッファーにデータをポンプでき、B）他のツールを使用する場合は、ストアドプロシージャを作成しましたこれにより、BLOBが一時テーブルにチャンク化され、一時テーブルからチャンクが繰り返し提供されます。うまくいきます。
の技術的な理由は関係ありません このようなものをDBに配置しますが、非常に簡単です 統合された場所で管理するために、ハードウェアを2倍または3倍にするか、DBをグリッド化して、コンサルタントや顧客が異種ファイルを短期間で管理するために浪費することができました。
更新：コメント投稿者は気楽に話してください。コメント投稿者は問題について意見を述べているだけです。