1

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

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

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

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

我已经参考了文档 提升推荐结果@docs.neo4j.org - 所有文档都表明，我提到的是一个可能的解决方案。但这里有一些问题——这些例子是关于关系属性的——它们并没有真正衡量这两种方法的优点和缺点

相同的多个关系...... @ Stackoverflow - 不是同一个问题，但是，它与用例相关。

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

另外，在 Google 论坛上查看相同的问题

4

1 回答 1

2

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

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

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

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

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

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

如您所见，这在很大程度上取决于您计划对图表执行的操作。希望这可以帮助 ！

于 2013-01-11T10:26:15.277 回答