A product catalog has articles. Every article has specific properties. These properties like material, size, form etc. are shared by some of the articles e.g. a tool is available in 3 sizes (6", 8", 10") and 2 materials (304, 316). In a catalog you'll find now 6 records, for every version of the possible combination one. This will raise very fast when you add another property, e.g. Voltage (230, 400, 500) as you now have 18 records. I am pondering if I should keep the properties in the nodes so that I have 18 nodes for every property like
(n:Tool {name:"X", voltage:"230", size:"6"})
and search the nodes for properties to find the right node or if I would try to set those key properties as nodes and connect the tool nodes to the property nodes, e.g.
(n:Tool {name:"X"}) -[:HAS_SIZE]- (s:Size {size:"6"})
(n) -[:HAS_VOLTAGE]- (v:Voltage {voltage:"230"}) a.s.o.
and try to find the node X by following paths. This last options might also have the charme that I could fill form fields with all available options by picking e.g. all voltage-nodes.
The last might lead to many nodes and relations and when the number raises e.g. having 20 property nodes I am unsure how to find my node X? The query then might look like
MATCH (n:Tool) -[:HAS_SIZE]- (s:Size)
MATCH (n:Tool) -[:HAS_VOLTAGE]- (v:Voltage)
MATCH (n:Tool) -[:MADE_OF]- (m:Material)
where s.size = "6" AND v.voltage="230" AND m.material ="304"
return n
This will become very big queries.
Maybe someone has a link to an article/post where a basic layout for such a data model is shown? Thank you!
