Neo4J 节点与关系实体

Posted 2023-02-26

【中文标题】Neo4J 节点与关系实体

【英文标题】：Neo4J Nodes vs Relationship Entities

【发布时间】：2014-03-08 18:52:11

【问题描述】：

我正在研究 Spring Data 书中的 NEO4J 示例。

 Nodes         - Product, Person, Order

 Relationships - (Order) Items (Product), (person) Reviewed (product)

我正在设计我的第一个 Neo4J 数据库，并且遇到了这样一种情况：评论可能更适合作为节点而不是关系。

这样评论现在可以有 COVERS 关系

 Review COVERED Order , Review COVERED Product 

从某种意义上说，这条评论将跨越多个 COVERED 关系。

对于创建节点实体与节点关系有什么想法吗？ Neo4J 看起来非常灵活......如果我改变主意，我似乎可以稍后修改它，是吗？

在关系中跨多个节点重复基本相同的评论文本似乎很奇怪......相反，为了节省计算空间并创建一个评论节点

 Review Node Entity
   - String comments
   - int stars

【参考方案1】：

在设计时，首要的事情是在白板上记下一个粗略的模型，它可以让人们深入了解想要实现的目标。

在这种情况下，如果您将REVIEW 节点分开，实际上会创建额外的节点和关系，而不是减少计算空间。

(PERSON)-[:GIVEN]->(REVIEW)-[:COVERED]->(PRODUCT)

所以考虑提出一个问题（用例）让我对产品 A 进行评论？

图表首先需要检查所有REVIEW 节点通过关系类型COVERED 连接到COVERED，然后再次必须回溯到PERSON 节点以获取谁给出了评论。

但如果你这样做(PERSON)-[:REVIEWED]->(PRODUCT)

您只需要查询一次所有关系类型REVIEWED 从PRODUCT A 节点传入PRODUCT A。 comments 和 stars 可以存储为关系属性。

所以我认为通过REVIEWED 与REVIEWED 上的attribs 直接连接将是更简洁的设计和更简单

【讨论】：

所以你建议将评论数据加倍，分成两个关系？

Neo4j 2.0 允许在关系上存储属性。因此，您可以将评论数据保存为 REVIEWED 关系上的属性

我知道这个事实......但是如果审查涵盖两个节点......我需要编写两个关系......这似乎效率低下，因为我现在存储的数据量增加了一倍。

我认为每个产品都有自己单独的评论权。将不同产品的评论分开是不是很理想，这样如果您想回溯特定的产品评论会更容易。无论如何，如果审查涵盖了两个节点..如果您创建一个单独的节点..根据我的回答中的匹配模式 1，将有 2 个关系 COVERED 和 1 个 REVIEW 节点和 1 个 GIVEN 关系。根据我回答中的匹配模式 2，只有 2 个 REVIEWED 关系。

每个产品的单一评论不适用于我正在使用的数据。我会尝试两个实例。一个是评论是具有多个关系的节点……另一个是评论加倍关系