Database design 在完全规范化的关系数据库中存储图形 目标

找到一个完美、灵活的模式，用于在关系数据库中存储许多不同类型的对象，这些对象之间有各种各样的链接

---

问题 EAV是RDBMS正常限制的一种变通方法。

如果您要规范化EAV模式，那么它将是丑陋的

---

主意 如果EAV被标准化，它将是丑陋的

我们传统上手工维护这些模式的事实是否限制了它们的复杂性和威力？

但如果它是以编程方式维护和查询的，那又有什么关系呢

---

图 如果在

n

不同的表中有

n

不同的实体，为什么不让代码生成

n（n+1）/2

链接表以及它们之间的查询？这不会在规范化模式中产生一个真正的图吗

在高度互连的数据库中，边总是以指数形式多于顶点。为什么不集中精力创建适当的规范化垂直体（

n

实体表）并让我们的代码维护边（

n^x

链接表）

---

结论 系统能否规范化EAV并维护生成的复杂模式

复杂的图形能否存储在关系数据库中（并保持真实性）

我肯定这以前做过，但我从未见过。我错过了什么

---

示例问题 存储印刷作品及其书目数据

• 许多属性可能不仅仅是字符串，而是整个对象
• 在图书馆的世界里，没有一个简单（和关系）的模式可以无损地存储数据，而没有极其复杂的模式
• 许多不同类型的关联和关联对象
  • 以及它们的相关属性（可能变化很大）
  • 以及他们之间的许多不同类型的关系

---

问题 “您想解决什么问题？”
-皮特

我正在寻找关系数据库系统中EAV、图形和多态关系的规范化解决方案

“我不想成为在它投入生产后必须理解或维护它的人。”
-安德鲁

---

这种“传统维护”正是我所说的我们应该自动化的东西。这不是很大程度上是繁重的工作吗？

这完全取决于图形的定义

在关系数据库或其他数据库中存储图形的唯一“正确”方法是简单（或其变体之一）。其他一切都是这项技术的衍生、专门化或优化，取决于问题领域的知识

您在问题中描述的方法本质上是将此通用邻接列表反规范化或重新规范化为多个“类型化”邻接列表（或链接表），这可能更合适，也可能不合适，具体取决于您的问题

我肯定这以前做过，但我从未见过。我错过了什么

您可能没有遗漏任何东西：实际上，像这样存储一般图形的情况非常罕见。你想解决什么问题

补遗 在高度互连的数据库中，边的数量总是以指数形式超过顶点。为什么不集中精力创建适当的、规范化的垂直线（表），让我们的代码保持边缘呢

---

我认为这比你想象的要普遍得多。我主要熟悉Python，但所有主要的ORMs/RDBMS工具包（SQLAlchemy、Django、SQLObject等）都支持自动维护多对多链接表，这是一项标准功能。

您的想法肯定会创建一个完全灵活的模式，可以表示任何类型的对象图。我不想成为在它投入生产后必须理解或维护它的人

设计良好的数据模式的一个好处是约束。我指的不仅仅是您可以定义的物理列约束，而是由整体结构施加的约束。有一组固定的显式关系，这提供了定义良好的路径

在您的场景中，从一个实体到另一个实体总是有大量的路径。有人怎么知道哪条路是“正确”的。“正确”的路径将只是“开发人员选择填充的关系集”

设想一个具有这些关系的数据库

客户发票发票LineItem产品

如果我看到这个，有人问我：“给我一个客户列表，每个客户都有一个他们购买的产品列表”，我就会知道如何编写查询

但是，如果这是一个所有东西都指向其他东西的图形，我怎么知道哪条路径是“正确”的路径呢。“客户-产品”关系、“客户-发票-行-项目”到“客户-产品”，或“客户-发票”到“发票-产品”，或“客户”到“发票”到“发票-行-项目”到“其他表格”到“产品”？答案可以是“它应该是显而易见的”，但对于一个开发人员来说，显而易见的东西是很常见的

为什么不让您的代码生成 n（n+1）/2“链接”表及其查询 他们之间

每当我在计算机科学中看到答案是“关于n平方”的任何东西时，我立刻认为答案是错误的。：-）

但更现实地说，当“n”变得中等大小时，链接表的数量变得非常庞大，非常非常快。国际海事组织（IMO）表示，这一方法不能代表通用解决方案

但我真正的反对意见是——你提出的方法不是一个可行的工程解决方案。工程就是制造贸易