EAVの概念で設計されたデータベースを見ると混乱します。 EAVはエンティティ、属性、値の略です。私の質問です:EAVのデータモデルは、データベースの正規化の高度な形式と見なされますか?それは「最新のもの」であるために「使用する」必要がありますか?EAVデータモデルは高度なデータベース正規化形式と見なされますか?
長いことを短く切る:EAVを使うときと使わないときは?
EAVの概念で設計されたデータベースを見ると混乱します。 EAVはエンティティ、属性、値の略です。私の質問です:EAVのデータモデルは、データベースの正規化の高度な形式と見なされますか?それは「最新のもの」であるために「使用する」必要がありますか?EAVデータモデルは高度なデータベース正規化形式と見なされますか?
長いことを短く切る:EAVを使うときと使わないときは?
いいえ、これらはアンチパターンとみなされます。
これは、不合理なレベル(私は人々がこれが良いアイデアだと思っていると思っていると思っている)に正規化していると見なすことができ、簡単なアドホッククエリの概念を失い、適切な索引付け。
EAVには、スキーマがどのようになるか分かりません(クライアントのカスタマイズ可能な「データベース」)。
「アンチパターン」はどういう意味ですか? –
+1。時には必要ですが、最後の手段としてのみです。 –
"モダンな"データベースデザインでは "使用する必要がある"のですか –
一般的な経験則として、EAVモデルは優れた設計手法ではないため、ほとんどの場合、避けるべきです。しかし、それらが問題の解決に最適な解決策である場合もありますが、それはまれです。
データベースツールボックスにはさまざまなツールが含まれている必要がありますが、その中のいくつかは他のツールよりもはるかに特殊です。 EAVはハンマーやドライバーであってはいけませんが、ハンマーハンマーのようなものです。あなたはそれで釘を運転することができますが、それは長期的にはあまり効果的ではありません。
EAVを考慮する必要があるのは、完全なスキーマを前もって知ることができない**場合だけです。それは、あなたがスキーマ要件の完全な分析を行うのが面倒であるケースを含みません。 –
これはASP.NETと関連していないようです。その場合は、この質問から「ASP.NET」タグを削除することを検討してください。 – mikemanne