Graph OrientDB：边与链接列表与链接地图

使用

链接列表

、

链接映射

或

边

来存储顶点之间的关系有哪些优点和缺点？

边定义了两个顶点之间的关系。例如，定义两个顶点：人和车。然后定义一个边缘驱动器。此边将两个顶点连接在一起。“简”开“福特”

链接列表是与另一个类关联的类的列表。汽车类可能具有零件类中零件的链接列表。汽车由多个部件组成

---

链接映射是与另一个类关联的键、类值的映射。car类可能具有PartType、Part的链接映射。一辆汽车由多个部件组成，可以按发动机、车身、底盘等进行分组。

到达时间有点晚，但我最近一直在寻找这个答案，并且有点清楚

OrientDB中的链接提供了关系数据库世界中外键关系的等价物。如果将表视为类，则链接在两个类

之间连接。 在他们的3.0手册的“下连接”和“无连接”部分中，他们指出

  SELECT * FROM Employee WHERE city.country.name = 'Italy'

他们在手册中没有告诉您的是，它们来自链接表，而不是图形关系

要在图形技术中实现这一点，首先需要创建边。我会将其标记为

locatedIn

so

  Employee => `locatedIn` => City

也有城市记录的边缘

 City => `ofCountry` => Country

然后，基于图形的OrientDB查询可能是

 SELECT * FROM Employee WHERE out(“locatedIn”).out(“ofCountry”) = “Italy”

你可能会想，这看起来要复杂得多。的确如此。但稍后，只需为该员工提供另一个名为

salesterrotry

的边缘关系 是由其他人添加的，然后可以像这样遍历和发现

 TRAVERSE * FROM Employee MAXDEPTH = 2

---

在这里，您将发现新的

salesratritory

边。这就是用Graph DB发现几乎任何深度的特别关系的地方。如果已经在关系数据库中实现了这一点，则需要探索新FK的模式。这是可行的，但要复杂得多。

+1是一个很好的例子。我仍然不知道什么时候使用链接列表而不是边缘更好。如果我以你为例，汽车有多个部件（两个顶点之间也有关系）。为什么我不应该创建多个边而不是链接列表？@AlexB:如果你想知道汽车的组成部分，链接列表是合适的。如果你想知道一个零件用在什么车上，以及组成一辆车的零件是什么，那么你可以使用边。边需要比链接列表更多的存储空间。边允许双向导航，如果您需要遍历图形，它是正确的选择。