示されているように最小限ですが、Model2の属性テーブルはメタデータの概念を導入しています それから来るすべての良いもので、ミックスに。 Model2には他にも利点があります。たとえば、パフォーマンスの向上 （値テーブルの）小さい行サイズに関連付けられていますが、メタデータの概念に焦点を当てたいと思います。
現状のまま Model2の属性テーブルは、すべての有効な属性のリポジトリを構成します （model1では、そのようなリストを取得するために、ある種の集約クエリを実行する必要があります）。また、現状のまま 、リポジトリは外部キー制約を導入するのに十分です データセットの整合性を維持するために（モデル1では、属性列に格納されている値の検証の外部形式が必要になります。
いくつかの簡単な追加で、属性テーブルはさまざまな目的に使用できる多目的なリポジトリになることができます。たとえば、テーブルには次のいくつかが含まれる場合があります
- 各属性の表示しやすい名前などの情報
- 処理/処理を区別するための、フィールドのタイプ（数値、文字列、日付など）を示すいくつかのフラグ
- 基になる属性が格納されている特定の値テーブル（モデルには1つのテーブルしか表示されませんが、最適化/スケーリングによってテーブルの分割が求められる場合があります）
- 属性が「値」テーブルに独自の列として格納される可能性があるという事実（これも最適化の形式であり、基本的に両方の世界を最大限に活用します。EAVモデルのスキーマの柔軟性と、従来のパフォーマンスすべてのエンティティで最も使用されている、および/または最も一般的な属性のリレーショナルモデル。
- メインテーブルを邪魔することなく、属性の名前を変更する機能。メタデータレベルでのみ変更されます。
- さまざまなアプリケーション指向のセマンティクス。たとえば、特定の属性を基本検索フィールドと高度な検索フィールドの1つとして提供する必要があることを示すインジケーター。
一言で言えば、属性テーブルは、アプリケーションを真にデータ駆動型（より正確には meta ）にするためのリソースになります。 データ駆動型）。実際、エンティティテーブル、つまり、さまざまなエンティティタイプに関連するメタデータが収集されているテーブルも好きかもしれません。これは、さまざまなエンティティタイプであり、どの属性がどのエンティティタイプに許可されているかなどです。
さて...zerkmsからのコメントに注意してください 、質問自体の下。 EAVモデルには、そのすべての利点について、クエリの複雑さが頭に浮かぶように、欠点と課題があり、パフォーマンスの問題もあります。ただし、これらの懸念は、先験的にEAVを失格にするべきではありません。EAVがより優れたアプローチである多くのユースケースがあります。 P>