4

I am working the examples of NEO4J found inside Spring Data's book.

 Nodes         - Product, Person, Order

 Relationships - (Order) Items (Product), (person) Reviewed (product)

I am designing my first Neo4J database and coming to a situation where the Review might be better served as a Node instead of a Relationship.

such that a Review could now have a COVERS relationships

 Review COVERED Order , Review COVERED Product 

This review would span multiple COVERED relationships in a sense.

Are there any thoughts on creating a Node Entity vs Node Relationship? Neo4J seems very flexible... if I change my mind it seems I could modify this later, yes?

It just seemed strange to be repeating essentially the same review text in a relationship, across multiple nodes... and to instead save computational space and create one review node

 Review Node Entity
   - String comments
   - int stars
Erik
  • 2,782
  • 3
  • 34
  • 64

1 Answers1

1

First and foremost thing while designing is to jot down on a white board a rough model which will give an insight to what one is intending to achieve.

In this scenario, if you keep REVIEW node separate there will in fact extra nodes and relationships created than reducing the computational space.

(PERSON)-[:GIVEN]->(REVIEW)-[:COVERED]->(PRODUCT)

So consider asking a question (use-case) Get me reviews of a product A?

The graph first will need to check all REVIEW nodes connected to PRODUCT A by relationshiptype COVERED, then again have to trace back to PERSON node to get who gave the review.

But if you do (PERSON)-[:REVIEWED]->(PRODUCT)

You would just need to query once all relationshiptypes REVIEWED incoming at PRODUCT A from PERSON node. And the comments and stars you can store as relationship attribs.

So I think keeping it connected directly via REVIEWED with attribs on REVIEWED will be neater design and less complex

Sumeet Sharma
  • 2,573
  • 1
  • 12
  • 24
  • So you'd recommend doubling up the review data, into two Relationships? – Erik Feb 11 '14 at 15:12
  • Neo4j 2.0 allows to store attributes on relations . So you can save the review data as attributes on REVIEWED relationship – Sumeet Sharma Feb 12 '14 at 02:31
  • I'm aware of that fact... but if the review covered TWO nodes.. I need to write TWO relations.. That seemed inefficient, since I am now doubling the amount of data stored. – Erik Feb 12 '14 at 19:29
  • i think every product will have its own separate review right.Shouldnt it be ideal to separate the reviews of different products so that if you want to back track a particular product review it would be easier . Anyway in case review covered two nodes.. If you create a separate node.. as per match pattern 1 in my answer there will be 2 relation COVERED and 1 REVIEW node and 1 GIVEN relation. As per match pattern 2 in my answer there would be just 2 REVIEWED relationships. – Sumeet Sharma Feb 13 '14 at 06:15
  • The single review per product doesnt hold for the data i am working with.. Ill try two instances .. One where reviews are nodes with multiple relations... And one where the reviews double up relations – Erik Feb 13 '14 at 14:19