サイズ（100kから800kまで）が可変である生のバイナリ文字列をキャプチャしています。それらは索引付けされる必要はなく（duh）、フィールドの内容に関する照会はありません。長いバイナリ（生データ）文字列を格納する
これらのインサートの数量は非常に多く（アーカイブ用です）、1日あたり10,000個としましょう。これらのような大きなバイナリ文字列のための最良のフィールドタイプは何ですか？それはtextまたはblobまたは何か他のものであるべきですか？
までは、PostgreSQLとなるので、タイプtextは問題になりません。その目的のために遅く、より多くのスペースを使用し、エラーが発生しやすくなりますbytea。 ファイルシステム内のファイルとして
使用タイプbytea（SQLのBLOB型の基本的PG相当）
店舗ブロブ：
は基本的に3つのアプローチがありますファイル名 のみをデータベースに格納します。
それぞれには長所と短所があります。
は扱いが簡単ですが、ほとんどのディスクスペースが必要です。いくつかのデコーディングとエンコーディングが必要であり、これも遅いです。バックアップのサイズは急速に拡大します！
は扱いがやや面倒ですが、あなたが必要な場合は、ブロブを操作する独自のインフラストラクチャがあります。そして、より簡単に別々のバックアップを作成することができます。
は、はるかに高速で、最小のディスク容量を使用します。しかし、データベース内に格納するときに参照整合性を得ることはできません。参照整合性とクイックリファレンスについてはbyteaフィールドに小さなサムネイルを格納します。
は、私は、画像ファイルのためのそのような実装の数を持っています。元のイメージをファイルシステムにファイルとして保存します。もちろん、時代遅れのファイルを削除する時期や方法、外部ファイルをバックアップする方法などについて考えなければなりません。
ほとんどのデータベースではおそらくblobを使用してください。 textの列は、しばしばテキストのエンコードまたはロケールに従って正規化または変換されます。実際のバイトは期待どおりに保存されないことがあります。ほとんどの場合、これはtextとblob列の唯一の違いです。
最大300MBのファイルを格納するユーザーVARBINARY列があります。
偉大な答え。ありがとう。 – teustis
これらのアプローチを比較した最近のデータはありますか？客観的な比較があったらすばらしいでしょう。 – beldaz