データベース EAV の長所/短所と代替案

Question

ユーザー定義のフィールドと値を許可するデータベースソリューションを探していました（無制限の数を許可）。一見したところ、EAV が適切であるように思えましたが、少し読んだ後では確信が持てなくなりました。

EAV の長所と短所は何ですか?

ユーザー定義の属性/フィールドと値を許可する代替のデータベース方法はありますか?

Answer 1

これは完全な回答とは考えられませんが、このトピックに関するいくつかのポイントにすぎません。

質問には というタグも付いているので、 [sql] タグ、一般的に言っておきますが、 リレーショナルデータベース を使用してデータを保存するのには特に適していません。 EAV モデル。SQL で EAV モデルを設計することもできますが、リレーショナル データベースがもたらす多くの利点を犠牲にする必要があります。参照整合性を強制したり、値に SQL データ型を使用したり、必須属性を強制したりすることができないだけでなく、非常に基本的なクエリの作成さえ困難になる可能性があります。実際、この制限を克服するために、いくつかの EAV ソリューションは関連テーブルとの結合ではなく、データの複製に依存していますが、ご想像のとおり、これには多くの欠点があります。

「無制限の数の属性を許可する」スキーマレス設計が本当に必要な場合、おそらく最善の策は、 NoSQL 解決。リレーショナル データベースに対する EAV の弱点は NoSQL の代替にも当てはまりますが、従来の SQL データベースでは実現が困難な追加機能が提供されます。たとえば、通常、NoSQL データストアはリレーショナル データベースよりもはるかに簡単にスケーリングできます。これは単に、NoSQL データストアがある種のスケーラビリティの問題を解決するように設計されており、スケーリングを困難にする機能を意図的に削除しているためです。

多くのクラウド コンピューティング プラットフォーム (たとえば、 アマゾン, グーグル そして マイクロソフト) は、EAV モデルに基づくデータストアを特徴としており、任意の数の属性を特定のエンティティに関連付けることができます。アプリケーションをクラウドに展開することを検討している場合は、大手ベンダー間の激しい競争により価値対コストの比率が非常に高いレベルに押し上げられているため、これをビジネス上の利点と技術的な利点の両方として考えることができます。継続的に機能を強化し、財務コストと実装コストを削減することによって。

Answer 2

posgtres hstoreの http://www.postgresql.org/を見てくださいドキュメント/ 9.0 /静的/ hstore.htmlする これは欠点のほとんどせずに、正確に何をしたい行います。

Answer 3

の ストリームプラットフォーム に基づいて代替方法を提案します ストリーム (実際には、それはドメイン モデルです), 田畑 そして 課題 エンティティ。

Answer 4

  

ユーザー定義の属性/フィールドと値を許可する別のデータベース方法はありますか？

1つの代替は、ユーザ入力に基づいて、データベーススキーマを変更することである。例えば、ユーザは、新しいフィールドを望んでいる場合、データベースに対応する列を追加

。