Graph 在节点和属性中表示所有信息如何影响存储和计算？

在使用图形数据库（我的案例Neo4j）时，我们可以用多种方式表示相同的信息。使每个实体成为节点，并通过关系连接所有实体，或仅将实体添加到节点的属性列表中。diff

以下是相同数据的两种不同表示形式。 总的来说，哪种机制适用于哪种条件

我的用例涉及从不同的节点遍历数据库，直到4个深度，并通过连接的节点或属性（基于哪种方法）检查信息。 一个有趣的问题可能是，“谁是去斯坦福大学的约翰的朋友？”

---

在存储、计算方面有什么不同呢？第一个更好，因为您查询的是实体，例如斯坦福，而该实体与许多个人节点相关。我的观点是，作为节点建模更直观，更容易查询。在您的第二个模型中，“查找所有上过斯坦福大学的人”并不容易，因为您没有开始遍历的位置。 我主要使用属性来描述节点/实体。使用属性来过滤查询结果，例如，谁是2010年去斯坦福大学的John的朋友。在本例中，年属性将仅用于修剪结果。取决于您的用例-如果年份非常重要，并且会引发大量查询或用于表示时间线，您甚至可以将年份建模为斯坦福大学的一个节点。

通常， 属性是延迟加载的，并且在缓存中保存更昂贵，尤其是字符串。节点和关系对于遍历最为有效，特别是因为关系类型与Relationship记录一起存储，因此在遍历中使用时不会触发属性加载

此外，一个平衡图（也就是说，没有多少密集节点具有超过10K的关系）是最有效的遍历

---

我将尝试将大多数重复出现的proeprite建模为连接到实体的节点，从而使用图形本身对这些值进行索引，而不必返回到对属性值进行筛选或使用昂贵的索引查找对属性进行索引

谢谢你的回答。这与编写查询有多容易或有多困难无关，而是与问题有关，它影响存储和计算性能。除非Neo4j内部有人告诉我们，否则他没有做出决定的依据。我在哪里可以找到关于Neo4j的事实，例如，“通常情况下，属性是延迟加载的，并且在缓存中保存的成本更高，尤其是字符串。”如果我们通过Neo4j站点获得这些信息，这将对我们的决策产生重大影响。Peter来自Neo4j内部：-）您看过手册中的性能指南了吗：