Postgres JSONBの良いユースケースは？
資産（ラップトップ/デスクトップ、モニター、キーボード、マウス、バッグ、ソフトウェアキーなど）を追跡するために、基本的には従業員に割り当てることができるすべての資産管理システムを作成したいと考えています。私の問題は、各タイプが異なる属性を追跡する必要があることです。モニターとは異なる、コンピューターのプロパティ/属性のセットを追跡します。私はEAVパターン（またはほとんどの人が言うことからの反パターン）について読んだことがあり、それはペストによって回避されるべきだと思われます。すべての列を含む単一のテーブルを作成するのはばかげているように思われ、新しいタイプごとに新しいテーブルを作成するのは最適ではないようです。最近、Postgres 9.4でJSONBについて読みました。アプリケーションで処理できるJSONオブジェクトを格納することは、かなり妥協のようです。
これはJSONBの良いユースケースですか？またはEAVは理にかなっていますか？または巨大なテーブルを作成するか、タイプごとにテーブルを作成しますか？
これは確かにオブジェクトのようなデータまたはキー/値のデータを格納するための合理的なケースであり、PostgreSQLのjsonbフィールドにJSONとして表すことは、これを行う合理的な方法です。
一般に、EAVやアプリが動的に列を追加するワイドテーブルなどの代替手段を検討し始めたときは、hstore、xml、jsonbなどを検討するときがきました。 jsonbは基本的に新しいhstoreであり、データを表現するためのより標準的な方法とネスト機能を備えているため、ほとんどの場合に適しています。
さまざまな種類のモノの静的テーブルと、より一般的なモノのカテゴリの親テーブルは、追跡されるモノが（a）かなり静的でユーザー定義ではなく、（b）過度に多くない場合でも意味があります。ここではそうは聞こえません。
属性を通常の列として保持することをお勧めします。
- これらは参照関係の一部を形成します（is-a、has-a、contains、is-contained-by、owns、is-owned-byなど）。
- これらは、
UNIQUE制約が意味を持つ自然なキーです。 - 大多数のクエリでフィルタリングされるか、そうでなければクエリされます
can jsonフィールドをクエリする式に対して、一意の制約、つまり一意のインデックスを定義します。それらを分離することは、しばしばよりクリーンです。同様に、式インデックスは、jsonオブジェクトの一部を保持したい、頻繁に照会されるフィールドに役立ちます。 RI制約はjsonオブジェクトキーの値を参照できないため、これが実際に最も重要な最初のポイントです。