2012年に更新すると、すべてのアプリケーションで、画像のサイズと数が増え続けていることがわかります...
サムネイルのように、「元の画像」と「処理された画像」を区別する必要があります。
Jcobyの答えが言うように、2つのオプションがあります。それなら、私はお勧めします：
-
blobを使用する （バイナリラージオブジェクト）：元の画像ストアの場合、テーブルにあります。 Ivanの回答（blobのバックアップに問題はありません！）、PostgreSQLの追加提供モジュール、ハウツーなどを参照してください。
-
DBlinkで別のデータベースを使用します。元のイメージストアの場合は、別の（統合/特殊化された）データベースにあります。この場合、私は byteaを好みます 、ただし blob ほぼ同じです。データベースを分離することは、「統合画像Webサービス」の最良の方法です。
-
byteaを使用する （BYTE配列）：サムネイル画像をキャッシュするため。小さな画像をキャッシュして、（レンダリングの問題を回避するために）Webブラウザーに高速に送信し、サーバーの処理を減らします。幅や高さなどの重要なメタデータもキャッシュします。データベースキャッシングが最も簡単な方法ですが、ニーズとサーバー構成（Apacheモジュールなど）を確認してください。サムネイルをファイルシステムに保存する方が良い場合があります。パフォーマンスを比較してください。これは（統合された）Webサービスであり、別のデータベース（バックアップなし）に格納して、多くのテーブルにサービスを提供できることを忘れないでください。 PostgreSQLバイナリデータ型のマニュアル、bytea列を使用したテストなども参照してください。
注1：現在、「デュアルソリューション」（データベース+ファイルシステム）の使用は廃止されています（！）。デュアルの代わりに「データベースのみ」を使用することには多くの利点があります。 PostgreSQLには、同等のパフォーマンスと、エクスポート/インポート/入力/出力のための優れたツールがあります。
注2：PostgreSQLには byteaしかないことに注意してください 、デフォルトのOracleの BLOBはありません ："SQL標準は（...）BLOBを定義します。入力形式はbyteaとは異なりますが、提供される関数と演算子はほとんど同じです"、Manual。
2014を編集 ：今日は上記の元のテキストを変更していません（私の回答は2012年4月22日で、現在は14票です）、変更の回答を公開します （「Wikiモード」を参照してください。編集できます！）、校正用および更新用 。
質問は安定しています（@Ivansの2008年の回答は19票）、このテキストの改善にご協力ください。