4
votes

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
1

1 Answers

1
votes

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