Think of a JSON map as a document or an entity. Then the keys would be predicates, and the values would be either references to another JSON map (document/entity) or a value (like a string, int or something).

{"uid": "0xabcd", "friend": [{...}, {...}], "name": "HN user", "age": 21 }

This is a valid JSON for Dgraph. It means, the overall JSON map is an entity of UID, 0xabcd. It has friends (other maps), name "HN user", and age 21. Here, "friend", "name", "age" are predicates.

Thanks for the reply mrjn. So a predicate includes a relation, but we take it from its logical point of view. (Rather than in an RDBMS, where we contort the relation so that we can see it from the perspective where it has a cardinality of 1.)

And the notion of one-ness of the predicate comes not from the fact that there's only one relation, but the fact that there's only one _logical value per predicate_ - here, we have two values of `friend` which cannot be conveniently coded in an RDBMS without the use of a join table.

So do I correctly interpret your faq "when not to use Dgraph" as saying "Dgraph is probably overkill if predicates naturally have a single value - that is, join tables are rare and you can naturally put foreign keys in the object they logically belong with, rather than in the table where they have a cardinality of 1".

This makes me think my other by @thundergolfer is probably wrong (sorry) - actually, an ecommerce site would benefit from an efficient graph db since you have an order, and now you want to find all the items in it, so the link from an order to an item should be associated with the order. Yet in the standard model, as with his, once you've found the order now you have to filter through the items to find the ones which reference the relevant orders; indeed, this is almost the only way that relation will ever be travelled - logically backwards.

I appreciate your time @mrjn. I like to hope you can benefit from answering my silly questions because someone can improve that faq. I'm trying to pick the right db for a personal project but I never expect to make money from it so I don't feel like I can give you any direct benefit from your time.

I’m not 100% sure, but a basic ecommerce site I think would be a classic example for a relational data model or key-value data model if you want to be fancy. Assuming the former, we’d then expect that in this data domain we could only come up with one maybe two predicates.

Without thinking too hard and deep, this seems true. An Order HAS Items, an item HAS a price, a customer HAS Orders, Addresses, etc.

I think you’d get quite far modelling the entire problem just with HAS.

But "has" isn't a predicate. "Has" is a relation. If we take "has an item" an "has a price" and "has an order" to be predicates, then we already have three predicates. So that can't be the definition of predicate.

Yes HAS is a relation, but in my example it's also the predicate.

A predicate is a statement that may be true or false depending on the values of its variables. In my example we'd have HAS(order_i, item_2), where both the order and the item are variables (or vertices) in our graph.

It wouldn't make sense to model with HAS_AN_ITEM(order_i), because as you say you'd proliferate predicates all over the place when you introduce new entities.

So yes, HAS is a predicate, and it handles nicely models a shopping cart.

A single Order, order_i, has the edges:

```

HAS(order_i, item_1) HAS(order_i, item_2) HAS(order_i, item_11) HAS(order_i, item_49) ... ```

DGraph models this with a 'PostingList' anchored on the predicate (they call it the "attribute"). This model is not particularly advantageous though in this shopping cart case as using a single HAS predicate means that in practice almost every 'PostingList' will have the same predicate and thus we will more often find ourselves joining across PostingLists when doing single predicate queries, which shouldn't happen.

In this example, item, price, order would be predicates.

No they're variables, or in DGraph parlance, 'Entity's and 'ValueId's.

Hi thundergolfer. mrjn is the person who created dgraph, so I think he knows what the terminology is.

Oh wow haha. This classic turn-up has now happened to me.

I’ll have to rethink the shopping cart example to see why those would be predicates.