in the relational database, it is connected by ID:
Table->User: u_ id ,u_ name
Table->Product : p_ id,p_ tittle
Table->Trade: t_ id,u_ id (buyer), p_id (Product ID)
How to design it in dgraph Schema?
in the relational database, it is connected by ID:
Table->User: u_ id ,u_ name
Table->Product : p_ id,p_ tittle
Table->Trade: t_ id,u_ id (buyer), p_id (Product ID)
How to design it in dgraph Schema?
type User {
id: String! @id
name: String
}
type Product {
id: String! @id
title: String
}
type Trade {
id: String! @id
buyer: User!
bought: Product!
}
This will allow you to import data, but this is not preferred for an empty system. For that, I would use the ID
scalar on the id properties instead of the String! @id
. You mentioned existing database so I suppose you need to import those ids.
I’d like to take this opportunity to ask @amaster507 on how one would shift mindset from a table-based SQL structure to graph based structure. If you could share, I could split and make it a wiki post.
In graphDBs you don’t have to care about foreign keys, join tables and so on. Graphs are all about relations.
Your schema would look like
PS: This is a DQL Schema, not GraphQL.
type User {
name
phone
}
type Product {
title
barcode
}
type Trade {
tax
from
products
}
name: string @index(exact) .
phone: string .
title: string @index(exact) .
barcode: string @index(exact) .
tax: int .
from: uid @reverse .
products: uid @reverse .
Your mutation
{
"set": [
{
"tax": "0%",
"from": {
"uid": "0xa31"
},
"products": [
{
"uid": "0x21"
},
{
"uid": "0x22"
},
{
"uid": "0x23"
}
]
}
]
}
And you can do calculations on the fly with queries.
@amaster507
@MichelDiz
Thank you for your answers and efforts.
The question was answered.