EAV完全忠诚或严重不同; 5NF由技术熟练的人员或无知者完成。
第六范式是不可简化的范式(不需要进一步的标准化)。它消除了很多常见的问题,如The Null Problem,并提供了识别缺失值的最终方法。这是在学术和技术上强大的NF。没有产品可以支持它,它不常用。要正确和一致地实施,它需要一个元数据的目录来实施。当然,导航它所需的SQL变得更加繁琐(SQL重新连接繁琐),但是通过从元数据中自动生成SQL可以轻松解决这个问题。
EAV是6NF的部分集合或子集。问题在于,通常是为了某种目的(允许添加列而无需进行DDL更改)以及不知道6NF的人以及不实现元数据的人员完成的。重点是,6NF和EAV作为原则和概念提供了实质性的好处,并且性能提高;但通常它没有得到正确执行,而且没有实现好处。不少EAV的实施都是灾难性的,不是因为EAV不好,而是因为实施效果差。
例如,有些人认为从6NF/EAV数据库构建3NF行所需的SQL很复杂:不,这很麻烦但不复杂。更重要的是,可以提供普通的SQL VIEW,这样所有的用户和报表工具都只能看到直接的3NF VIEW,而6NF/EAV问题对他们来说是透明的。最后,所需的SQL可以自动化,因此很多人忍受的人工成本是不必要的。
所以答案的确是,第六范式,是EAV的父亲,是一个更纯粹的形式,是它的替代品。注意事项是,确保它正确完成。我有一个大的6NF数据库,它没有任何人员发布的问题,它执行得很漂亮,客户很高兴(没有进一步的工作是完全功能满意的标志)。
我已经发布了一个非常详细的回答另一个问题,它适用于你的问题还有,你可能会感兴趣。
Other EAV Question
与其取代你所拥有的东西,因为它确实满足特定的需求,你应该考虑用随时间存储变化的东西来扩充你的基本EAV模型。 – RibaldEddie 2010-10-29 05:24:29
我同意RibaldEddie,它不会很简单,但为您的Attribute定义添加日期/版本可能会比完全重构构建在当前架构上的所有代码更容易。 – JeremyWeir 2010-10-29 05:47:03
有没有可能关闭这个?无论是评论和进展,还是投票和选择答案。谢谢。 – PerformanceDBA 2011-01-25 12:32:33