找到一个完美的,灵活的模式,用于存储许多不同类型的对象,并在关系数据库中使用各种各样的链接.
问题
EAV是RDBMS正常约束的解决方法.
如果您要规范化EAV模式,那将是丑陋的.
理念
如果EAV正常化,那将是丑陋的.
我们传统上用手保持这些模式的事实限制了它们的复杂性和实力？
但是,如果以编程方式维护和查询,那怎么办？
图表
如果在n个不同的表中有n个不同的实体,为什么不让你的代码生成n(n 1)/ 2个链接表和它们之间的查询？这不会导致在规范化模式中的真实图形？
在高度相互关联的数据库中,总是存在比顶点更多的边缘.为什么不专注于创建正确的,规范化的verticles(n个实体表),并让我们的代码保持边缘(n ^ x链接表)？
结论
系统可以使EAV归一化并维护生成的复杂模式吗？
可以将复杂图形存储在(并保持真实的)关系数据库中吗？
我相信这是以前做过的,但我从来没有看过.我失踪了什么
示例问题
存储印刷作品及其书目数据
>许多属性可能不只是字符串,而是整个对象.
>在图书馆世界中,没有简单的(和关系)模式可以无损地存储数据而无需极其复杂的模式.
>许多不同类型的关联和关联对象
>及其相关属性(可能会有很大差异).
>他们之间的许多关系,不同的类型.
问题
“你想解决什么问题？”
-Piet
我正在寻找关系数据库系统中的EAV,图形和多态关系的归一化解决方案.
“我会讨厌成为在投入生产后理解或保持它的人.”
-安德鲁
这个“传统维护”是我说的应该是自动化的确切事情.这不是很勉强工作吗？
解决方法
是的,有更好的设计方法,为了您的描述的目的和用途.
第一个问题是EAV,通常执行得非常糟糕.更准确地说,EAV人群,因此文献质量不高,标准不能维持,所以关系数据库的基本完整性和质量就会丢失.这导致许多有据可查的问题.
你应该考虑适当的学术衍生的替代方案.这完全消除了关系的完整性和能力.它被称为第六正常形式.实际上EAV实际上是6NF的一个子集,没有充分的理解;更常见的6NF的再现.
6NF正确实现是特别快的,因为它存储列而不是行.因此,无论您用于访问图形的向量如何,您都可以以这种方式映射数据(图形系列,数据点),以获得平稳的高速度. (您可以将重复消除到比5NF高的次序,但这是高级用途.)
“高度相互关联”根本不是问题.那就是关系数据库的性质.这里需要注意的是,它必须是真正的规范化,而不是一个无关紧要的平面文件.
自动化或代码生成不是问题.当然,如果你想要质量和可维护性,你需要扩展sql目录,并确保它是表驱动的.
我对这些问题的回答提供了对这个问题的全面对待.由于提出的背景和论点,最后一个特别长.
EAV-6NF Answer One
EAV-6NF Answer Two
EAV-6NF Answer Three
这也是值得的：
Schema-Related Problem
原文地址：https://www.jb51.cc/mssql/82277.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
