なんで？ すべて あなたのエンティティはこのように拡張可能である必要がありますか？おそらくそうではありません-ほとんどのアプリケーションでは、このレベルの柔軟性の恩恵を受けるエンティティはせいぜい1つまたは2つです。他のエンティティは、実際には notの安定性と明確さから恩恵を受けています 常に変化します。
EAVは、内部プラットフォーム効果 の例です。 ：
つまり、制約やデータ型など、適切なRDBMSがすでに提供しているすべてのことを実行するアプリケーションコードを作成するのはあなたの責任です。 NOT NULLのように列を必須にするような単純なものでも EAVでは機能しません。
プロジェクトが多くのテーブルを必要とする場合があるのは事実です。しかし、2つのテーブルを作成するだけでプロジェクトを単純化したと思うなら、あなたは自分をだましています。テーブルと同じ数の個別のエンティティがありますが、それらがゴミの山にならないようにするのはあなた次第です。
EAVに時間をかけすぎる前に、誰かがデータリポジトリを任意に柔軟にしようとしたために機能しなくなった会社について、次の記事を読んでください。悪いCaRMa 。
また、EAVについての詳細は、ブログ投稿 EAVFAIL に書いています。 、および私の本の章では、 SQLアンチパターン：データベースプログラミングの落とし穴を回避する> 。