Database 将图形数据结构映射到关系数据库有意义吗？

特别是一个

一些同事提出了这个建议，我完全困惑不解

---

对此有什么见解吗？

嗯，信息必须存储在某个地方，关系数据库不是个坏主意

---

它只是一个多对多关系、一个节点列表表和一个边缘/连接列表表。

考虑Facebook如何在他们的数据库中实现社交图。他们可能会有一张桌子给人，另一张桌子给朋友。friendships表至少有两列，每列都是people表的外键

---

由于友谊是对称的（在Facebook上），他们可能会确保第一个外键的ID总是小于第二个外键的ID。Twitter的社交网络有一个有向图，所以它不会使用这样的规范表示。

这是一个可以接受的方法。你需要考虑这些信息是如何被操纵的。更可能的是，您需要一种与数据库分离的语言来进行这种类型的数据所暗示的与图形相关的计算。具有广泛的截面图数据结构及其操作

在不考虑可能执行的查询类型的情况下，从两个表开始

顶点

和

边

。顶点很简单，一个标识符和一个名称。在多重图中，边是复杂的。边应该由两个顶点（即外键）和一些附加信息的组合唯一标识。附加信息取决于您正在解决的问题。例如，如果航班信息，起飞和到达时间以及航空公司。此外，您还需要确定边缘是否定向（即单向），并跟踪该信息

---

根据计算的不同，你最终可能会遇到一个问题，这个问题最好用某种人工智能/机器学习算法来解决。例如，最佳航班。这本书有一些用于此目的的有用算法。但是数据保存的位置不会改变算法本身

在数据库中存储图形非常简单：有一个用于节点的表和一个用于边的表，它充当节点表和自身之间的多对多关系表。像这样：

create table node (
  id integer primary key
);

create table edge (
  start_id integer references node,
  end_id integer references node,
  primary key (start_id, end_id)
);

然而，以这种方式存储图形有几个难点

首先，该方案中的边缘是自然定向的——起点和终点是不同的。如果边是无向的，那么在编写查询时必须小心，或者在表中为每条边存储两个条目，一个在任意方向（然后小心编写查询！）。如果你存储一个边，我建议对存储的形式进行规范化——也许总是考虑以最低ID为起点的节点（并添加一个检查约束来执行此操作）。通过不让边引用节点，而是在它们之间有一个联接表，可以得到一个真正无序的表示，但这对我来说似乎不是一个好主意

其次，上面的模式无法表示多重图。您可以很容易地扩展它来实现这一点；如果给定一对节点之间的边不可区分，最简单的方法是向每个边行添加一个计数，说明引用的节点之间有多少条边。如果它们是可区分的，那么您需要向节点表中添加一些内容以允许对它们进行区分-自动生成的边ID可能是最简单的事情

---

然而，即使对存储进行了分类，也存在处理图形的问题。如果希望对内存中的对象执行所有处理，并且数据库纯粹用于存储，那么就没有问题。但是，如果您想在数据库中对图形进行查询，那么您必须了解如何在SQL中进行查询，因为SQL没有对图形的任何内置支持，并且其基本操作不容易适应处理图形。这是可以做到的，特别是如果您有一个支持递归SQL的数据库（PostgreSQL、Firebird和一些专有数据库），但这需要一些考虑。如果您想这样做，我的建议是发布有关特定查询的更多问题。

您希望执行哪种查询？搜索？集群？等