Looking for wisdom (rule of thumb) for labels/indexes versus relationships...

[Alan Robertson]

Hi,

When looking at which IP addresses are part of which subnets, for IPv4,
it's possible that up to 1024 (or maybe) more IP addresses could be part
of a subnet. For IPv6, there's no obvious limit to how many IP addresses
could be on a subnet (2^64 for example).

I could represent this as a relationship to a subnet object - with a
large number of relationships - typically no more than 200 or so at a
time, but there could be many more. Or I could create a label for each
subnet, or a value with an index associated with it.

Is there a rule of thumb for how the maximum number of relationships
should exist to a single node?

At what point does it make sense to take the relational approach and go
with an index of some kind (a label, or an indexed attribute)?

--
Alan Robertson
al...@unix.sh

[John Singer]

I don't know if there is a rule of thumb for number of relationships per node, but I would prefer to start the design process with identifying the concepts being modeled and representing those as Node types using labels to indicate the type.  So in your example you would have an IPV6 label and a SUBNET label.  yes, it's possible that there could be a huge number of ipv6's in a subnet but in practice will that happen?  You don't want to create a label for each subnet as then you lose the ability to relate the subnets to other node types.  I did a graph model like this and we related the IP to the L2 interface and then to the Host computer system.  

[Michael Hunger]

You can also sub-structure the relationships from the subnet to represent the levels in the ip address.

Otherwise it might also be possible to just store the IP as a numeric value array and use a filter on top of that array for the subnets (or a second property for the subnet).

Michael

--
You received this message because you are subscribed to the Google Groups "Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.