この段階では、可能な限り少ない仮定（Webアプリの実際の進化に関する）でデータベース設計を決定しようとしています。
JOINSが高価であることを理解するための最初のステップとして、多数の正規化された小さなテーブルではなく、少数のモノリシックテーブルを検討しています。2番目のポイントとして、hstoreと通常のテーブルとJSONB（GiSTインデックス付け）を使用することで混乱しています。
知っている（気軽に修正してください）：
一般に、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のアドホックキー値ストア（メインリレーショナルテーブルのいずれかにキーが格納されている）に格納する必要がありますか？
@Yogeschそれらのリンクには、いくつかの興味深い矛盾するものが含まれています:)道徳的には、MySQLは結合が（悪い）ようであり、NoSQLの人々は実際の根拠なしにこの概念を一般化する傾向があります。一方、AaronとMaxはそのp-wordに敏感です-その幅広い使用法は、非ネイティブスピーカー（自分自身を含む）が間違った単語を喜んで使用する方法を示しています。
—
dezso
@Yogeschは現実的に、インターネット上に何かを「証明」する情報源があると確信しています。宗教テキストが残虐行為を正当化するために使用できるように（歴史を通して劇的に示されているように）。作業が少ないほどコストは低くなりますが、常にある程度のトレードオフがあります。
—
エリック
@Yogesch：結合を回避することは、データアクセスパターンを事前に知っている読み取り重視の操作にとって重要であるため、必要なすべてのデータを1行に安全に配置できます。ただし、これにより他の結合のコストが高くなる可能性があります。さまざまな質問に答えるために、さまざまな方法でデータに参加する必要がないと言うのは誰ですか？今、私たちは...リレーショナルデータモデリングの理論に単純に下降するつもりだ
—
クリス・
@Yogesch私の実践では、データベースのボトルネックはめったにRAMまたはCPUではありませんが、I / Oです。この方法では、冗長データの保存を避けることが重要です。クリスが言うように、データを常に一方向にしか見ない場合、これは価格に見合う価値があるかもしれません。そうでない場合は、かさばって非常に柔軟性のないデータの塊があります。
—
dezso
JSON(B)およびhstore（およびEAV）は、構造が不明なデータに適しています。