Criteria for deciding on merging nodes (multiple labels) vs different nodes with more relationships

[pdrangeid]

I'll lay out my scenario. I have several things that represent a physical asset (PC, server, NAS, switch, printer, firewall, etc) in my graph database:

The primary source of truth (which service tickets are based on) is in asset management (:Crmasset).
But there are other nodes that also represent assets: RMM/Patching platform (:Mwphost), another monitoring platform (:Nagioshost), an LDAP computer object (:Ldapobject).

Part of the use of this is to validate when an asset is properly represented in these various systems. Currently I'm doing something like this:
(:Crmasset)-[:PATCHED_VIA]->(:Mwphost)
(:Crmasset)-[:MONITORED_VIA]->(:Nagioshost)
(:Ldapobject)-[:COMPUTER_OBJ]->(:Crmasset)

Of course there are often several properties in common (FQDN, mac address, name, description...)
So when would it make more sense to simply add a label to the existing node that represents the device is present in multiple platforms vs DIFFERENT nodes with relationships added?

We use this system to be sure our onboarding policies are followed (example: Server devices should be in patching AND monitoring, PCs should be only in the patching system. ALL assets should be reflected in our asset management platform regardless of monitoring requirements....

[andrew_bowman]

It sounds like you have multiple contexts for an asset, and you're using multiple labels (with :Crmasset being the high-level generic label) to work with those assets in their different contexts.

If the properties are pretty much the same (with the difference simply being that you don't care about some properties when working with the node in a different context), then your current approach of relying on multi-labeling makes sense, as you avoid redundancy and only have a single node per physical asset.

Is this current approach not working for you in some regard? Breaking out each node into multiple for each context usually isn't a good approach unless you have some very compelling reasons for offsetting the simplicity of a single node per asset.