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

问题

EAV是RDBMS正常约束的解决方法.

如果您要规范化EAV模式,那将是丑陋的.

理念

如果EAV正常化,那将是丑陋的.

我们传统上用手保持这些模式的事实限制了它们的复杂性和实力？

但是,如果以编程方式维护和查询,那怎么办？

图表

如果在n个不同的表中有n个不同的实体,为什么不让你的代码生成n(n 1)/ 2个链接表和它们之间的查询？这不会导致在规范化模式中的真实图形？

在高度相互关联的数据库中,总是存在比顶点更多的边缘.为什么不专注于创建正确的,规范化的verticles(n个实体表),并让我们的代码保持边缘(n ^ x链接表)？

结论

系统可以使EAV归一化并维护生成的复杂模式吗？

可以将复杂图形存储在(并保持真实的)关系数据库中吗？

我相信这是以前做过的,但我从来没有看过.我失踪了什么

示例问题

存储印刷作品及其书目数据

>许多属性可能不只是字符串,而是整个对象.
>在图书馆世界中,没有简单的(和关系)模式可以无损地存储数据而无需极其复杂的模式.
>许多不同类型的关联和关联对象

>及其相关属性(可能会有很大差异).
>他们之间的许多关系,不同的类型.

问题

“你想解决什么问题？”
-Piet

我正在寻找关系数据库系统中的EAV,图形和多态关系的归一化解决方案.

“我会讨厌成为在投入生产后理解或保持它的人.”
-安德鲁

这个“传统维护”是我说的应该是自动化的确切事情.这不是很勉强工作吗？