10

必要に応じて動的フィールド値を入力できるAccountgroupように、テーブルに動的フィールドがあるデータベースを作成する必要があります。Accountsおそらく重要ではありませんが、EF と Linq で C# を使用しています。

私はそのようなことをしたことがないので、私にとっては難しいです.私が調査したので、EAVシステムはひどいので、別の方法で設計する必要があると誰もが言っています.問題は、後で誰も教えてくれないことです-どのように?

それで、EAVを使わずに似たようなものを実装する方法を教えてください。

これは私がこれまでに持っているものです。

ここに画像の説明を入力

2020 編集:

2020年なので、この投稿を編集したいだけで、これに対する明確な答えがあります：Postgres with jsonb type. EF Core はこれをサポートしているため、実際に動的 json を問題なく保存してクエリを実行できます。

4

4 に答える 4

23

経験則の問題は、「通常、X を実行するのは悪い考えである」から「決して X を実行しない」に急速に移行することです。

EAV は、多くの点でリレーショナル スキーマの目的を無効にし、リレーショナル DBMS の多くの機能と利点、および Entity Framework のような ORM などの RDBMS 上に構築された他のテクノロジを奪うため、一般的に悪い考えです。

ただし、RDBMS があまり適していない特定の設計上の問題があります。まったく新しいテクノロジーを発明しなければならないほど適合性が低いものもあります (MongoDB のような NoSQL DB など)。

不完全なオプションのセットから EAV がおそらく最良の選択である場合があります。スキーマが何であるかを事前に知らない (できない) 場合は、EAV が最良の選択かもしれません。これは、スキーマが重要ではないことが判明した場合に特に当てはまります。たとえば、製品の膨大なリストがあり、それぞれにいくつかの機能があるオンライン製品カタログを考えてみましょう。どの製品がどの機能を備えているかを事前に予測することはできません。最終的に、製品の機能に対して行う唯一のことは、とにかく「機能: 値」リストにそれらをダンプすることです。これは、スキーマが特に強力ではない状況であるため、EAV でそれを無効にしても特に害はありません。

最も重要なことは、設計の選択が機能と運用にどのような影響を与えるかを理解することです。すべての設計はトレードオフです。ポイントは、トレードオフを意識的に行うことです。「EAV は悪だ」ではなく、「EAV は装填済みの銃です。誰の足を指しているのかを確認してください」と考えてください。

于 2013-06-21T10:40:40.740 に答える
3

EAV は「悪」ではありません。他のソリューションの方が適切な場合に、悪用されることがあります。

属性が真に動的で、動的に列を追加することを避けたい場合は、 EAVが適切です。

1たとえば、テーブルのロックを回避するため、または選択した ORM が適切に機能しないため、またはテーブルが多すぎるため。

于 2013-06-21T10:31:38.483 に答える
3

最も単純なレベルでは、値を列として追加するだけです。おそらく、データベースでスパース列のサポートを使用して、サイズに大きな影響を与えないようにします。これにより、EAV とプラットフォーム内効果の両方が回避され、値を通常の型付き値として保存することになります。

于 2013-06-21T09:46:19.260 に答える
2

レポートや BI に EAV フィールドを使い始めると、自分自身を撃ちたくなるでしょう。

  1. XML フィールドを使用します。ほとんどのデータベースには、優れた XML サポート、XPath クエリ、インデックス作成があります。

  2. テナントのユーザー設計フィールドの新しいスキーマを作成します。ユーザーがそのスキーマでやりたいことを実行できるようにします (妥当な範囲内で)。

例えば

create table account_group (
  id primary key references real_schema.accountgroup(id),
  super_important_note_field text not null
);

はい、スキーマ間で外部キーを実行できます。

于 2013-06-21T17:43:39.750 に答える