Linking nodes vs searching predicates

Users
1

In my app users can have websites, and websites can be for specific web properties, think Twitter, LinkedIn.

Currently my setup is

        username: String @index(hash)

        webProperty: uid @reverse .
        websiteUserValue: String @index(hash) .
        webPropertyName: String @index(hash) .
        webPropertyKey: String @index(hash) .

So users will all share unique web properties, when they have the same key, say twitter. This way I can quickly find all twitter users if I wanted as the nodes are joined, I can also add extra properties to the twitter webProperty (maybe an icon).

{
 users(func: has(username)) {
  username
  uid
	websites {
       websiteUserValue
       webProperty {
         webPropertyKey
         webPropertyName
       }
     }
   }
}

Having come from an SQL background this is kinda what made sense to me initially. It’s just like a join.

This nesting however adds complexity when creating the entities, and in some ways it would be nice to not have this sub-nesting. Maybe something like:

{
 users(func: has(username)) {
  username
  uid
	websites {
      websiteUserValue
      webPropertyKey
  }
 }
}

Here multiple users would have the same string “webPropertyKey” and if I wanted to find all twitter users I would just search for this predicate.

So my question is: how much of a disadvantage is it to have a webPropertyKey instead of a link to a webPropertyNode?

Are there performance characteristics that are an advantage one way or another?

Is one way more appropriate for a GraphDB?

My thoughts on pros and cons:

node pros

  • add extra attributes to webProperty easily for all users
  • find users who have node via @reverse

node cons

  • more complex to create the node as you are linking it
  • *currently returns as an array, even though the relationship is really a has_one relationship. A website can only have one and belong to one WebProperty.

Simple predicate pros

  • easy to create websites as they are now just two predicates and the webPropertyKey acts as a type filter

Simple predicate cons

  • adding any extra properties would require you add them to every user
  • takes up more space? (Is this true)

Are these pros on cons right? Am I missing anything. Any thoughts would be appreciated. #datamodelingishard

2

Do you have a question, @vespertilian?

3

@dmai I accidentally saved this before finishing it!

1 Like
4

The benefit of a graph database compared to a relational database is that you can model your data more naturally in a form similar to a mind map.

A website that can only have one property should use a value predicate. If a website can have multiple properties, use an object predicate.

2 Likes
5

@dmai

Thanks for the reply, by object predicate I assume you mean a link to a new node? It make sense there would be no performance issue either way.

I think I am on the right track, talking this through is useful.

Thanks!

6

Yes, object predicate means new node.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.