データベースデザイン：EAVオプション？

Question

これは単なるデータベース概念の質問です：EAVの次のモデルの長所と短所は何ですか？

モデル1：

TABLE: attribute_value 
====================================== 
| id | fk_id | attribute | value  | 
====================================== 
| 1 | 10 | FName  | John  | 
| 2 | 10 | Lname  | Doe  | 
| 3 | 55 | FName  | Bob  | 
| 4 | 55 | Lname  | Smith  | 
-------------------------------------- 

モデル2：私はモデル2で見

TABLE: attribute 
================== 
| id | attribute | 
================== 
| 1 | FName  | 
| 2 | Lname  | 
------------------ 

TABLE: value 
===================================== 
| id | attribute_id | fk_id | value | 
===================================== 
| 1 | 1   | 10 | John | 
| 2 | 2   | 10 | Doe | 
| 3 | 1   | 55 | Bob | 
| 4 | 2   | 55 | Smith | 
------------------------------------- 

1つの利点は、attributeは重複が含まれていないことです。

Answer 1

Model2の属性表は、というメタデータのコンセプトをミックスに導入し、そこから得られるすべての利点を紹介しています。 Model2には他にも利点があります。例えば、のパフォーマンスの向上は、（Valueテーブルの）小さな行サイズに関連付けられたですが、メタデータの概念に焦点を当てたいと思います。

でもとして-あるモデル2の属性テーブルには、すべての有効な属性（MODEL1と1は、このようなリストを取得する種類の集計クエリを実行する必要があります）のリポジトリを構成しています。-があるとしても、そして、リポジトリは、1つの属性列に格納された値の妥当性確認の外形が必要になります（モデル1とデータセットの整合性を維持することを助けるために外部キー制約を紹介するのに十分である。

いくつかの簡単な追加が

、属性テーブルは、様々な目的のために使用することができる汎用性の高いリポジトリになることができます。たとえば、テーブルには、各属性の表示、フレンドリ名として以下の

• 情報の一部を含むことができ
• いくつかのフラグindicati差別化された処理/処理のためのフィールドのタイプ（数値対文字列対日付など）
• モデルは基になる属性が格納されている特定の値テーブル（モデルは1つのテーブルのみを表示しますが、最適化/ ）
• 属性が「値」テーブルに独自の列として格納されているという事実（やはり最適化の形であり、本質的に両方の世界の最高得点：EAVモデルのスキーマの柔軟性すべてのエンティティに最もよく使用され、かつ/または最も一般的な属性の伝統的なリレーショナル・モデルです。
• メインテーブルを妨げることなく、属性の名前を変更する機能。メタデータレベルでの変更のみ。
• さまざまなアプリケーション指向セマンティクス。たとえば、特定の属性が基本検索オプションフィールドと高度検索フィールドのいずれかとして提供されるべきかどうかの指標。一言で言えば

は、属性テーブルは、アプリケーションが本当にデータ駆動（又はより正確には、メタデータ駆動型）にすることができるリソースとなります。実際にはエンティティテーブル、つまりさまざまなエンティティタイプに関連するメタデータが収集されているものもあります。異なるエンティティタイプ、どのエンティティタイプなどで許可されている属性などです。

今...注意してくださいコメントにはのzerkmsという質問自体の下にあります。 EAVモデルには、すべてのメリットを享受するために、複雑さが問われる複雑さやパフォーマンスの問題など、欠点と課題があります。しかし、これらの懸念は先験的に失格にはならないはずです。EAV：EAVがより良いアプローチである多くのユースケースがあります。
EAVが選択肢であると仮定すると、Model2、またはより滑らかで洗練されたものでさえ、モデル1よりも明らかに優れています。

Answer 2

モデル2では、attribute_idに外部キーを設定し、定義済みの属性のみがテーブルに入力できることを確認できます。

また、モデル2の場合、外部キー（索引）を作成した方がクエリが高速になるため、特定の属性IDを持つ値を取得するために高速なクエリを実行できます。

Answer 3

概念的なレベルでは、これらの2つのモデルは事実上同一です。文字列をID番号で置き換えました。それで全部です。

外来キーが必要な場合は、モデル1の「属性」に外部キー制約を課すことができます。

賛否両論に限り、EAVのこれらの2つの実装には違いはありません。すべてBill Karwin's pointsが両方に適用されます。