インデックス付きのJSONBとhstore
この段階では、できる限り少ない前提（Webアプリが実際にどのように進化するかに関して）でデータベース設計を決定しようとしています。
最初のステップとして、JOINSは高価であることを理解し、多数の正規化された小さいテーブルではなく、少数のモノリシックテーブルを検討しています。 2つ目のポイントとして、hstoreと通常のテーブルとJSONB（Gistインデックスを使用）の使用について混乱しています。
AFAIK（自由に修正してください）：
一般に、Postgresでは、hstoreは他のデータ型よりもパフォーマンスが高いことが知られています。このFOSDEM PGDAYからのプレゼンテーションには、興味深いスライドがあります（スライドの後半）。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
Hstoreの利点は、高速なインデックス作成（GiNまたはGist）です。ただし、JSONBを使用すると、GiNおよびGistのインデックス作成をJSONデータに適用することもできます。
第2象限の専門家によるこのブログは、「現時点では、すべての新しいアプリケーションでhstoreの使用をjsonbに置き換える価値がある」と述べています（最後までスクロールしてください）： http://blog.2ndquadrant.com/postgresql-anti -patterns-unnecessary-jsonhstore-dynamic-columns /
だから私は以下について決定したいと思います：
- データの主要な（構造化された）部分について：いくつかのリレーショナルテーブル（比較的多くの列を持つ比較的大きい）に入れる必要があるか、それともhstoreを使用するいくつかのキーと値のストアにする必要がありますか？
- アドホック（ユーザー提供/非構造化）データの場合、JSON形式にするか、hstoreにアドホックキー値ストア（キーは主要なリレーショナルテーブルの1つに格納されます）にする必要がありますか？
リレーショナルデータベースは、結合を中心に設計されており、適切に動作するように最適化されています。
正規化された設計を使用する正当な理由がない場合を除き、正規化された設計を使用してください。
jsonbやhstoreのようなものは、次のような正規化されたデータモデルを使用できない場合に適しています。データモデルは急速に変化し、ユーザーが定義します。
関係的にモデル化できる場合は、関係的にモデル化します。できない場合は、jsonなどを検討してください。Ifjson/jsonb/hstoreから選択する場合は、特に理由がない限り、jsonbを選択してください。 。
それが私が 私のブログ投稿 で言ったことです。 投稿全体をお読みください。あなたが引用した段落は、動的構造を選択している場合hstoreではなくjsonbを選択する必要があることを指摘していますが、ブログ投稿の残りの部分はその理由についてです可能であれば、通常はリレーショナルモデルを使用することをお勧めします。
そう。主要な構造化部分を関係的にモデル化します。テーブルが本当に幅が広く、列がたくさんある場合、これはさらに正規化が必要であることを示している可能性があります。結合を恐れないでください。参加を愛することを学ぶ。多くの小さなテーブルを結合することは、大きな非正規化されたテーブルをクエリして維持するよりも速くなることがよくあります。特定の場合に必要な場合にのみ、そしてできればマテリアライズドビューを介して非正規化してください。
自由形式で構造化されていないユーザー投稿データの場合は、jsonbを使用します。これはhstoreと同じように機能するはずですが、より柔軟で扱いやすくなっています。
理解しておくべき1つの関連事項：jsonbで使用されるようなGistインデックスとGINインデックスは、通常、プレーンなbツリーインデックスよりもmuch効率が低くなります。それらはより柔軟ですが、通常の列のBツリーインデックスは、ほとんどの場合、はるかに高速です。