EAV 数据模型是否被视为数据库规范化的高级形式？
当我查看使用 EAV 概念设计的数据库时，我感到很困惑。 EAV 代表实体、属性和值。我的问题是：EAV 数据模型是否被视为数据库规范化的高级形式？它是“必须使用”才能“最新”吗？
长话短说：什么时候使用 EAV，什么时候不使用？
i am confused when looking at databases designed with the EAV concept. EAV stands for entity, attribute and value. my question is: Does EAV datamodels considered as advanced form of database normalization ? is it a "must use" to be "up to date" ?
to cut long things short: when to use EAV and when not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，它们被认为是反模式。
它们可以被视为将规范化达到了荒谬的水平（我见过人们认为这是一个好主意），导致人们失去所有简单即席查询的概念，并对正确索引的概念造成严重破坏。
当您不知道架构是什么时（例如客户端可定制的“数据库”），EAV 就有用武之地。
No, they are considered to be an anti-pattern.
They can be seen as taking normalization to an absurd level (I have seen people think that this is a good idea), causing one to lose all notion of easy ad-hock querying and causing havoc with the notion of proper indexing.
EAV has a place when you have no idea what the schema will be (say for a client customizable "database").
作为一般经验法则，EAV 模型不是良好的设计实践，在大多数情况下应避免。然而，在某些情况下，它们可能是当前问题的最佳解决方案，但这种情况应该很少见。
您的数据库工具箱应该包括各种工具，其中一些工具比其他工具更加专业。 EAV 不应该是锤子或螺丝刀，而更像是大锤；你可以用它钉钉子，但从长远来看效果不是很好。
As a general rule of thumb, EAV models are not good design practices, and should be avoided in most cases. However, there may be cases where they are the best solution for the problem at hand, but it should be rare.
Your database toolbox should include a variety of tools, some of which are much more specialized than others. The EAV shouldn't be a hammer or a screwdriver, but more like a sledgehammer; you can drive nails with it, but it's not very effective in the long run.