设计：关系节点 [英] Design : Relation Vs. Node

问题描述

我是新的图形数据库，并且被承诺的范围和权力淹没。在设计应用程序时，我们将情感设计模式与实际性能设计保持一致是非常重要的。困扰我的一个问题是是否将某些信息作为关系属性或节点属性。
这是用例。我们有通过传入关系service_provider相关的实体。起始节点成为终端节点的提供者。现在每个服务提供商都通过一些合同与他们的客户（或消费者）相关。像服务频率，每个服务的费用，没有显示收费等。这些合同是可以从服务到服务的细节，但属性将永远在那里。

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

请注意，我的情感感觉是使其成为关系的一部分，这就是为什么我的描述可能画了这样的图片。但是，并不一定是这样。我想听到你的意见，以便我可以得出结论。

如果你认为这个问题在错误的地方，请考虑建议一个更好的位置。

我已经提到了docs
提升推荐结果@ docs.neo4j.org - 所有文档表明，我提到的是一个可能的解决方案。但是这里是关心的问题
- 关系属性的例子是
- 他们并没有真正衡量PROS的任何一种方法。

相同的多个关系... @ Stackoverflow
- 不是真的同样的问题，但是，它是

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

此外，在Google论坛中查看相同的问题

解决方案

没有一般的经验法则来决定如何实现图形。你有不同的选择，我认为你必须坚持一个你找到最简单没有，但这也给你一个很好的表现。

我实际上看到你的4个选项案例，并按我的偏好顺序排序：

• 您定义一个service_provider类型关系，并添加一个键/值属性{合同：合同类型}。然后，您可以通过其属性对关系进行索引，以便您可以从索引中检索合同和相应的起始和结束节点。




• 您可以定义合同类型的索引节点，每次向某个节点添加新的提供者时，还可以链接节点到合同类型。这当然意味着提供者是唯一的，否则您将无法区分哪个合同链接到客户机节点的哪个提供商。我老实说，不要以为这是最好的解决方案，除非你想使用你的数据库进行明确的模式识别和匹配的合约类型（只有在你计划这样做的时候，我才建议先进的图形挖掘）。 / p>




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




• 定义节点之间的两个关系，一个类型为service_provider，一个与合同的类型。我认为第一种方法如果只是用于存储信息，会更好。但是，这也可能对未来的模式匹配有用，即使在这种情况下，我建议第二个。

你可以看到，它取决于你打算用图表做很多事情。希望这有帮助！

I am new to graph database, and overwhelmed with its promised scope and power. When designing app, it is very important that we align our emotional design patterns with practical performance designs. One of the question that is bothering me is whether to make certain piece of information as relation attribute or node attribute. Here's the use case. We have entities that are related by incoming relation "service_provider". The starting node becomes a provider to end node. Now each of the service provider are related to their customer(or consumer) via some contract. Like frequency of service, cost per service, no show charges etc. These contracts are details that can vary from service to service, but the attributes will always be there.

So now my question is should these contract be a different node, that can be connected to a pair of entities (service provider and consumer) or they should be part of relation itself.

Please note that , my emotional feeling is towards making it part of relationship and that's why my description might have painted a picture like that. However, that is not necessarily be the case. I want to hear your views so that I can conclude my approach.

If you think the question is at wrong place please consider suggesting a better location.

I have already referred to docs Boosting recommendation results @ docs.neo4j.org - all docs indicates that, what I mentioned is a possible solution. But here are the concerns - The examples are lite on relation attributes - They don't really measure the PROS an CONS of either approach

Multiple relationships of the same ... @ Stackoverflow - Not really the same question , however, it is relevant to the usecase.

Referring response from @bendaizer Now here is a performance question. Comparing #1 and #4(partly). Assuming contracts are defined by service provider (at least in most of the cases), the only way a service provider can connect to a consumer is via contract. so we have a service provider surrounded by contracts and contracts connect to consumer. When I try to lookup a consumer by service provider...I have to do the extra hop of contract. While per #1, the same contract information can be put in relationship property. Which one is expected to perform better, assuming all contracts are unique? While do so I don't want to lose the capability of answering questions like [Which all customers of "Service Provider X", are paying a rate $50 an hour - $50/hr is part of contract info]

Also, checkout the same question at Google Forum

解决方案

There are no general rule of thumb to decide how to implement a graph. You have different options, and I think you must stick to the one you find the easiest without but which also gives you a good performance.

I actually see 4 options in your case, and sorted them in my preference order :

• you define a service_provider type relationship, and you add a key/value property {contract : type of contract}. You can then index the relationships by their properties, so you can retrieve back the contracts and the corresponding start and end nodes from the index. Very simple, does the job.

• you can define indexing nodes of the contract types, and each time you add new provider to some node, you also link that node to the type of the contract. This of course imply that the provider is unique, or else you won't be able to distinguish which contract is linked to which provider for a client node. I honestly don't think this this the best solution, unless you want to use your database for explicit pattern identification and matching over the type of contract (I would recommand for advanced graph mining only if you're planning to do so).

• you can define a node for each contract (instead of one node per contract type), you will have a lot more of nodes. But this might be useful if you need to have "egde over edge" type of relationships. This can be the case for individual classification purpose. This is useful if your nodes can have different providers and different type of contract, and the contract can be attached to specific features on an individual basis.

• you can define two relationships between the nodes, one with the type service_provider, one with the type of the contract. I honeslty think the 1st approach is better if it's just for storing the information. But this one can also be useful for future pattern matching, even though in this case I recommand the second one.

As you can see, it depends a lot of what you're planning to do with your graph. Hope this helps !

这篇关于设计：关系节点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！