我是图形数据库的新手，并且承诺了其承诺的范围和权力。在设计应用程序时，我们将情感设计模式与实际性能设计保持一致非常重要。困扰我的一个问题是，是否将某些信息作为关系属性或节点属性。 这是用例。我们有与传入关系“service_provider”相关的实体。起始节点成为终端节点的提供者。现在，每个服务提供商都通过一些合同与其客户（或消费者）相关。像服务频率，每项服务的成本，没有显示费用等。这些合同的细节可能因服务而异，但属性将始终存在。
所以现在我的问题是这些合约应该是一个不同的节点，可以连接到一对实体（服务提供商和消费者），或者它们应该是关系本身的一部分。
请注意，我的情感感觉是让它成为关系的一部分，这就是为什么我的描述可能会画出这样的画面。但是，情况不一定如此。我想听听你的意见，以便我可以结束我的方法。
如果您认为问题出错，请考虑建议更好的位置。
我已经提到了文档 Boosting recommendation results @ docs.neo4j.org - 所有文档都表明，我提到的是一种可能的解决方案。但这是关注点 - 示例是关于关系属性的精简版 - 他们并没有真正衡量PROS是这两种方法的缺点
Multiple relationships of the same ... @ Stackoverflow - 然而，不是同一个问题，它与用例有关。
参考@bendaizer的回复 现在这是一个性能问题。比较＃1和＃4（部分）。假设合同由服务提供商定义（至少在大多数情况下），服务提供商连接到消费者的唯一方式是通过合同。所以我们有一个服务提供商，包括合同和合同连接到消费者。当我尝试通过服务提供商查找消费者时...我必须做额外的合同。虽然每＃1，相同的合同信息可以放在关系属性中。假设所有合同都是独一无二的，那么预计哪一个会表现更好？虽然这样做，但我不想失去回答问题的能力，例如[服务提供商X的所有客户，每小时支付50美元的费用 - 50美元/小时是合同信息的一部分]
答案 0 :(得分：2)
决定如何实施图表没有一般的经验法则。你有不同的选择，我认为你必须坚持你最容易找到的那个，但也会给你一个很好的表现。
我实际上在你的案例中看到了4个选项，并按照我的偏好顺序对它们进行了排序：
您定义了service_provider类型关系，并添加了键/值属性{contract：contract of contract}。然后，您可以按其属性索引关系，以便可以从索引中检索合同以及相应的开始和结束节点。很简单，做到了。
您可以定义合同类型的索引节点，每次向某个节点添加新提供程序时，还会将该节点链接到合同类型。这当然意味着提供者是唯一的，否则您将无法区分哪个合同与客户端节点的提供者相关联。老实说，我不认为这是最好的解决方案，除非您想使用您的数据库进行显式模式识别和匹配合同类型（我建议只有在您计划这样做时才进行高级图挖掘。） / p>
您可以为每个合约定义一个节点（而不是每个合同类型一个节点），您将拥有更多的节点。但是，如果您需要“egde over edge”类型的关系，这可能会有用。这可以是个人分类目的的情况。如果您的节点可以具有不同的提供者和不同类型的合同，这非常有用，并且合同可以单独附加到特定功能。
您可以在节点之间定义两个关系，一个类型为service_provider，另一个类型为合同类型。我认为如果只是存储信息，第一种方法会更好。但是这个对于将来的模式匹配也很有用，即使在这种情况下我推荐第二个。
正如您所看到的，这取决于您计划对图表执行的操作。希望这有帮助！