Most like a category → sub category … more sub categories
looks have to create two type, one is Node, another is Link ?
any help is appreciate
Most like a category → sub category … more sub categories
looks have to create two type, one is Node, another is Link ?
any help is appreciate
declare Node type :
type Node {
id: ID!
name: String!
edges: [Edge] @hasInverse(field: from)
}
declare edge type :
type Edge{
id: ID!
name: String! @search(by: [term])
from: Node!
to: Node!
weight: Int
}
is correct design schema ? since we want the edge can suit to variant link relationship but fixed define in node , but not sure if this way is best for query.
what schema design principle should keep in dgraph ?
any advice is much appreciate !
Hi @RobinCc
There are two different approaches. You already mentioned one of them when you are using a middle node to connect two other nodes. This approach has its benefits, like easily putting extra data with different types on middle node instead of working with facets and dql and the down side of this approach is that you have lots of middle node(We use graph database to get rid of middle tables most of the time ).
The second approach is to just use one type Node:
type Node {
NodeID: ID!
parent: Node
children: [Node]
}
I am not sure if hasInverse works in this case or not but you can handle that with some extra steps like a lambda resolver to insert nodes.
Also someone else had a similar situation and we had a discussion about this. You might want to take a look at that too:
thanks for answer,
type Domain {
DomainID: ID!
source: [Domain]
target: [Domain]
}
the idea is great, I like it