设计：关系与。节点

Question

我是图形数据库的新手，对它承诺的范围和功能感到不知所措。在设计应用程序时，将我们的情感设计模式与实际性能设计保持一致是非常重要的。困扰我的问题之一是是否将某些信息作为关系属性或节点属性。 这是用例。我们有通过传入关系“service_provider”相关的实体。起始节点成为结束节点的提供者。现在每个服务提供商都通过一些合同与他们的客户（或消费者）相关联。像服务频率、每次服务成本、不显示费用等。这些合同的细节可能因服务而异，但属性将始终存在。

所以现在我的问题是，这些合约是否应该是一个不同的节点，可以连接到一对实体（服务提供者和消费者），或者它们应该是关系本身的一部分。

请注意，我的情感感觉是让它成为关系的一部分，这就是为什么我的描述可能会描绘出这样的画面。但是，情况不一定如此。我想听听你的意见，以便我总结我的方法。

如果您认为问题出现在错误的位置，请考虑建议更好的位置。

我已经提到过文档 Boosting recommendation results @ docs.neo4j.org - 所有文档都表明，我提到的是一个可能的解决方案。但这里有一些担忧 - 这些例子是关系属性的精简版 - 他们并没有真正衡量这两种方法的优点和缺点

Multiple relationships of the same ... @ Stackoverflow - 不是同一个问题，但是，它与用例有关。

引用来自@bendaizer 的响应 现在这是一个性能问题。比较#1 和#4（部分）。假设合同是由服务提供者定义的（至少在大多数情况下），服务提供者可以连接到消费者的唯一方式是通过合同。所以我们有一个被合同包围的服务提供者，并且合同连接到消费者。当我尝试通过服务提供商查找消费者时......我必须做额外的合同跳跃。而根据#1，可以将相同的合同信息放入关系属性中。假设所有合同都是唯一的，预计哪一个表现更好？虽然这样做，但我不想失去回答诸如[“服务提供商 X”的所有客户支付每小时 50 美元的费率 - 50 美元/小时是合同信息的一部分] 之类的问题的能力]

Also, checkout the same question at Google Forum

Answer 1

没有通用的经验法则来决定如何实现图表。你有不同的选择，我认为你必须坚持你认为最容易没有但也能给你带来良好表现的那个。

我实际上在您的案例中看到了 4 个选项，并按照我的偏好顺序对它们进行了排序：

• 您定义了一个 service_provider 类型关系，并添加了一个键/值属性 {contract : type of contract}。然后，您可以通过它们的属性对关系进行索引，这样您就可以从索引中检索合同以及相应的开始和结束节点。很简单，干活。

• 您可以定义合约类型的索引节点，每次向某个节点添加新的提供者时，您还可以将该节点链接到合约类型。这当然意味着提供者是唯一的，否则您将无法区分哪个合同链接到客户端节点的哪个提供者。老实说，我不认为这是最好的解决方案，除非你想使用你的数据库来进行明确的模式识别和合同类型的匹配（只有当你打算这样做时，我才会推荐高级图挖掘）。

• 您可以为每个合同定义一个节点（而不是每个合同类型一个节点），您将拥有更多的节点。但是，如果您需要具有“egde over edge”类型的关系，这可能会很有用。这可能是用于个人分类目的的情况。如果您的节点可以有不同的提供者和不同类型的合约，并且合约可以单独附加到特定功能，这将非常有用。

• 您可以在节点之间定义两种关系，一种是 service_provider 类型，一种是合约类型。老实说，如果仅用于存储信息，我认为第一种方法会更好。但是这个对于未来的模式匹配也很有用，尽管在这种情况下我推荐第二个。

如您所见，这在很大程度上取决于您打算如何处理图表。希望这会有所帮助！