オブジェクト (投稿など) に「タグ」を保存するとします。リリース 9.4 では、主に 3 つの選択肢があります。
多くの場合、3 番目は「タグ」値に対する条件付きクエリを許可しないため、問題外です。私の現在の開発では、そのようなクエリは必要ありません。タグは、投稿をフィルタリングするためではなく、投稿リストに表示されるためだけに存在します。
したがって、選択は主にtext[]との間jsonbです。どちらも照会できます。
何を使いますか？なぜ？
ほとんどの場合、テーブルoption_tagと. ここでの参照実装：optiontag
あらゆる点で最速のオプションではないかもしれませんが、参照整合性、制約、全範囲のデータ型、すべてのインデックス オプション、安価な更新など、DB 機能の全範囲を提供します。
完全を期すために、オプションのリストに追加します。
hstore（良いオプション）xmlhstoreまたはよりも冗長で複雑なjsonbので、XML を操作する場合にのみ使用します。リストが表示用でめったに更新されない場合は、プレーンな配列を検討します。これは通常、他のものよりも小さく、パフォーマンスが優れています。
コメントにリンクされているJosh Berkus @a_horse のブログ エントリを読んでください。ただし、選択された読み取りケースに焦点を当てていることに注意してください。Josh は次のように認めています。
比較書き込み速度をテストしていないことに気づきました。
そして、特に同時負荷の下で単一のタグを大幅に変更する場合は、正規化されたアプローチが大きな効果を発揮します。
jsonbとにかくJSONを操作する場合にのみ良いオプションであり、JSONを「そのまま」保存および取得できます。
カスタムデータ型の代わりに、正規化されたスキーマと CSV で区切られた値を持つ単純なtextフィールドの両方を使用しました (CSV の代わりに、JSON や、www-urlencoding や XML 属性エンコーディングなどの他のエンコーディングを使用できます)。これは、多くの ORM とデータベース ライブラリがカスタム データ型 (hstore、jsonb、array など) のサポートにあまり適していないためです。
@ErwinBrandstetter は、配列オプションよりも、正規化されたスキーマで以前に使用された可能性のあるすべてのタグをクエリする方がはるかに高速であるという、正規化されたものの他のいくつかの利点を見逃していました。これは、多くのタグ システムで非常に一般的なシナリオです。
そうは言っても、タグのクエリにはSolr（またはelasticsearch）を使用することをお勧めします.Solrは、タグカウントと一般的なタグプレフィックス検索を処理するため、Postgresに実行させるよりもはるかに優れています.検索エンジン。したがって、タグの保管はそれほど重要ではなくなります。