0

テーブル「foo」と、特定のタイプの foo の追加データを保持する補助テーブル「bar_1」...「bar_k」を含む Postgres データベースがあります。基本的に、「foo」は共通の属性を持つ親クラスと考えることができ、各「bar_i」テーブルは追加のプロパティを追加する「foo」のサブクラスと考えることができます。

スキーマを再設計して、いくつかの「バー」テーブルの代わりに、各種類の「バー」テーブルにあるさまざまな列をリストする「foo_metadata」のテーブルと、「foo_attributes」テーブルを持つようにすることを考えています。通常は「バー」テーブルにある値。

このようなシステムの利点は、非常に汎用的であることです。基本的に、各クラスに関するメタデータをデータベースに入れることになるため、アプリケーションを更新したり、変更または追加されたクラスごとにテストを作成したりする必要がなくなります。

「foo」テーブルから 1 行、「bar」テーブルから 1 行を読み取る代わりに、「foo_metadata」および「foo_attributes」テーブルから複数の行を読み取ることになります。更新についても同様です (ただし、インデックスが作成されていない値とタイムスタンプのみを更新します)。

私の質問は、どの程度のパフォーマンス ヒットが得られるかということです。パフォーマンスへの影響を最小限に抑える方法はありますか? 開発者がシステムの再設計に多くの時間を割く前に、パフォーマンスへの影響を見積もるために使用できる指標は何ですか。

(Postgres が値に型を強制することには関心がありません。値は一般に文字列であり、データベースに挿入される前にアプリケーションが値をチェックする必要があるためです...)

4

1 に答える 1

1

あなたが説明したモデルは、一般的な EAV モデル (エンティティー属性値モデル) です。

それに関する情報はすでにインターネット上に山ほどあります。ただグーグルEAVthiswiki の記事から始めることもできます。

EAV の最大の問題:

  1. クエリを記述するのは難しい場合があります。(単一のテーブルからの複数の列ではなく、同じ値のテーブルへの複数の結合)
  2. このモデルにデータベースの制約を簡単に適用することはできません (したがって、参照整合性とチェックはありません)。
于 2013-02-19T18:38:47.707 に答える