Mapping a attribute as a property vs relationship vs node

[amukuntha]

Hi, I'm learning graph modeling with Neo4j and pretty new to few concepts. I have this doubt and not sure how to word it properly so unable to search in Google. Would appreciate all your help in this.

I see that have few options in modeling a feature of particular thing, for ex. features of iPhone in product hierarchy. I can have the feature as a property, another one is to have the feature as a relatonship (and the node being just "Yes") and 3rd one being have the feature as a separate node with relation "has_feature" to the main node.

1. (iPhone:Product {name:'iPhone 8', has_camera:'Yes'})
2. (iPhone)-[:HAS_CAMERA]->(Yes)
3. (iPhone)-[:HAS_FEATURE]->(Camera)

I'm trying to understand the difference between these 3 and how they impact things down the line. As per the O'Reilly Graph Database book email example and "strong-weak" relations, it is better modeled as either a relation or a separate node. Is that usually the case? Can anyone direct me to resources that explain the difference between these?

[koji]

Hi @amukuntha

2. (iPhone)-[:HAS_CAMERA]->(Yes)

The No.2 design is not good.
You need a new relationship name for each new feature.
For example, what if You want to separate camera types?

(iPhone)-[:HAS_4K_CAMERA]->(Yes)
(iPhone)-[:HAS_8K_CAMERA]->(Yes)

Also, '(Yes)' is a node that cannot be labeled.

(:Yes)???

Anyway, I change the model of the graph depending on what kind of search I want to do.

Welcome to the Dark Side: Neo4j Worst Practices (& How to Avoid Them)

Neo4j Graph Database Platform – 24 Feb 16

Welcome to the Dark Side: Neo4j Worst Practices (& How to Avoid Them)

Watch (or read) Field Engineer Stefan Armbruster’s GraphConnect presentation on the best (and worst) practices for deploying Neo4j at your organization.

Graph Modeling Guidelines

Neo4j Graph Database Platform

Graph Modeling Guidelines - Neo4j Graph Database Platform

This guide is designed to walk you through the graph data modeling lifecycle of Neo4j. You will be introduced to the basic process of designing a graph data model that can answer a wide range of business questions across a variety of domains.

[amukuntha]

Thank you Koji! That's very helpful. Particularly great point regarding the querying - better to have a node (rather than a property) if we would be querying that.

[bbrown]

Would a Label attached to the Product node also work? How would that fit into the hierarchy of solutions?

Separate Node
Label on Product Node
Property of Product Node
Relationship to Yes node

[amukuntha]

Thx Bill! I didnt notice about labels, thx for suggesting it. Btw, can nodes have multiple labels?

[bbrown]

Yes nodes can have multiple labels.

[bbrown]

However, to clarify, a Node is useful once it has either a label or a property such as name. So an attribute isn't mapped to a Node, but the label of the node or one of the properties of the node. Likewise, for a Relationship, although we call it a Type instead of a label, and I am fairly sure only one type per Relationship is allowed. Of course you can have multiple relationships between two Nodes. In summary, you can map an attribute to a:

Node Label
Node Property
Relationship Type (similar to Label)
Relationship Property