Modeling createdBy and modifiedBy node attributes

[denis_vulinovic]

In my data model, every node has two attributes - createdBy and modifiedBy - that reference Person entities.

If I use relationships for these, then every node will have these two relationships. This will add a lot of "noise" to the graph. And it won't necessarily add much value, as it's not often that we want to query for nodes associated with a Person. Instead, it's normally used to show who created or modified the node.

An alternative is to have a unique property for each Person (say PersonId), and assign this to the createdBy and modifiedBy properties instead. If we index that property, we can have fast lookups when we need it.

Or is there a better way of doing this?

[mike_r_black]

If they're going to be queried infrequently by these date fields, I'd just go ahead and store they information as properties on the node

[ypkkhatri]

@mike.r.black have good point to carry the data in another node, but what happens when deleting that Person who associated with that node via relationship?

Your opinions are much appreciated.

[mike_r_black]

If you store these "system" fields of who created a node and when (fields we see all the time in SQL DBs to help debug when a record changes in a table). Just like in SQL DBs, if a user is removed, without those relationships, those properties stored on the node are just strings & dates. You can use to query and index if you want, but there's no relationship to a "User" node. Therefore no cascading deletes if a user is deleted.

This is where it just depends on your use case. If these values are really just "system information" values you want to to track to help you know when & who changed a value, I'd just store them as a property on the node. If your use case is more than that, create the relationship back to the user. Making you have an extensive audit tracking system and you have a model of (asset)-[:changed]->(Action {when: datetime} )<-[:performed_by]-(User)

It just depends on your use case.