「altnameの1つが「foobar」であるすべてのオブジェクトを一覧表示する」という形式のクエリが必要になります。予想されるテーブルサイズは、数百万レコードのオーダーです。そのためにPostgresJSONクエリを使用でき、インデックスを作成することもできます（たとえば、JSON配列で要素を検索するためのインデックス）。ただし、そのように行う必要がありますか、それとも推奨されない厄介な回避策ですか？
できます そのように行われるが、それはあなたがすべきだという意味ではありません。ある意味で、ベストプラクティスはすでに十分に文書化されており（たとえば、hstoreの使用、XMLの使用、EAVの使用、別のテーブルの使用を参照）、すべての目的と実用的な目的（検証と構文を除く）で違いはありません。以前の非構造化または半構造化オプションから。
言い換えれば、それは新しい化粧をした同じ老豚です。
JSONは、逆検索ツリーインデックスを使用する機能を提供します 、hstoreと同じように、配列タイプとtsvectorsも同様です。これらは正常に機能しますが、辞書式順序で値のリストを抽出するのではなく、主に距離順に並べられた近隣のポイントを抽出するように設計されていることに注意してください。
説明のために、ローマの答えが概説している2つの計画を考えてみましょう。
- インデックススキャンを実行するもの ディスクページを直接調べ、インデックスで示された順序で行を取得します。
- ビットマップインデックススキャンを実行するもの 行を含む可能性のあるすべてのディスクページを特定することから始め、不要な領域をスキップするシーケンススキャンを実行しているかのように（実際にはまったく同じように）、ディスクに表示されるとおりにそれらを読み取ります。
質問に戻る：雑然とした特大の逆ツリーインデックス Postgresテーブルを巨大なJSONストアとして使用すると、アプリのパフォーマンスが実際に向上します。しかし、それらも特効薬ではなく、ボトルネックに対処する際の適切なリレーショナル設計までは到達しません。
結局のところ、最終的には、hstoreまたはEAVの使用を決定したときに得られるものと何ら変わりはありません。
- インデックスが必要な場合（つまり、where句、さらに重要なことに、join句に頻繁に表示される場合）、データを別のフィールドに配置する必要があります。
- 主に表面的なものであれば、JSON / hstore / EAV / XML/whatever-makes-you-sleep-at-nightは問題なく機能します。