Suggestion to add lookup like relation between nodes?

Usually new to graph db and understood basic concepts of it but still wanna know if someone have any suggestion on adding relationship of lookup type like in relational db we do.

What do you mean by “adding relationship of lookup type”? Can you show an example in a relational DB?

Here you go for more detail :

Ah, that’s trivial in a graph database. I will use the DQL syntax to show you the example from the Salesforce page.

First , a relevant quote for those who are too lazy to click on the link:

Lookup Relationships

In our Account to Contact example above, the relationship between the two objects is a lookup relationship . A lookup relationship essentially links two objects together so that you can “look up” one object from the related items on another object.
Lookup relationships can be one-to-one or one-to-many. The Account to Contact relationship is one-to-many because a single account can have many related contacts. For our DreamHouse scenario, you could create a one-to-one relationship between the Property object and a Home Seller object.

One to Many Relationships

Let’s look at the first example (Account to Contact relationship), the DQL schema would look something like this:

<name>:  string .
<contacts>: [uid] @reverse .
type account {
    <name>
    <contacts>
}

type contact {
    <name>
    <~contacts>
}

Now let’s break down this schema, line by line:

<name>:  string .
<contacts>: [uid] @reverse .

This says that the predicate name must be a string, and contacts is a predicate represented by list of object IDs (we call them uid). The [] indicates that it’s a list, so you can have many object IDs linked.
The @reverse in the contacts line indicate that the relationship is two way. This will be explained in a bit.

So now we have these two predicates, let’s see how they are used. We first define a type called account. You can think of a type as analogous to a “table” in relational databases. But don’t hold on too tightly to this idea, as it will eventually lead you astray. But if you are dipping your toes into graph databases, it’s something to hold on to.

type account {
    <name>
    <contacts>
}

What this says is that the account type is made up of nodes that have two predicates linked: <name> and <contacts>. So if you have a node (let’s call it A) that has a link to <name> and a link to <contacts> this node then has a type of account.

You may visualize it as something like this:

image

Now you may be wondering then, “what does this node actually contain??” Let’s not worry about that for now. Instead, let’s focus on analogies with a relational database. The node A is like a row on a database table.

In fact, a very good trick I learned from my machine learning days is that you can treat every table as a graph! How? Each row is headed by a “primary key”, and each field is a relation from the PK to the field. Something like this

image

Now let us look at our next type definition:

type contact {
    <name>
    <~contacts>
}

What this says is that contact is a type (recall that you can loosey analogize type to “tables”). It contains a name, and that weird little ~ before contacts. What ~contacts says is that it’s a reverse lookup from the contacts predicate. The @reverse directive in the predicate earlier is required in order to define ~contacts.

Both these types put together, you can see that a account can link to many contacts . And from each contact, you can use the reverse edge to look up the account.

So, where in a SQL database you would create two tables, in Dgraph, you create two types. Where in SQL databases you add a PK-FK constraint for lookups, in Dgraph, it’s natively/naturally available.

One to One Relationships

Now let us look at One-to-One relationships. Using the example again from the Salesforce page, we can create the following schema:

<seller>: uid @reverse . 

type property { 
    seller
}

type seller {
    ~seller
}

Now, homework for you @dgandhi17 - can you explain this schema back to me?

1 Like