数据库设计 – 将图形存储在完全规范的关系数据库中

找到一个完美的,灵活的模式,用于存储许多不同类型的对象,并在关系数据库中使用各种各样的链接.

问题

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!