Unique Identifier Best Practice

[timojannejokine]

I'm working on a requirement for a corporate knowledge application.
Users can create articles and we store the articles in a MongoDB where they get a unique ObjectID.
Subsequently we store the article in our Neo4J database and create the needed relations.

What is the best practice to uniquely identify nodes and keep the reference to the document in MongoDB?
Should we use a plugin like neo4j-uuid to automatically generate an id and additionally store the ObjectID as another attribute on the node? Or should we just solely store the ObjectID on the node?

We need to keep the reference so we can find the corresponding document in MongoDB but also need to be able to get nodes by id.

[terryfranklin82]

I'm not sure what adding a new uuid via neo4j-uuid (or apoc function) would add, if it were me I would just go with a simple node property that has a uniqueness constraint on it (and therefore an index as well)

[timojannejokine]

That sounds right, thanks. What about other nodes that do not have a reference to our MongoDB?

[terryfranklin82]

Shouldn't be an issue -

Unique constraints do not mean that all nodes have to have a unique value for the properties — nodes without the property are not subject to this rule.

https://neo4j.com/docs/cypher-manual/current/schema/constraints/

[mdfrenchman]

To expand on what Terry was saying. You could/should use the provided ObjectID with a uniqueness constraint, since you already know that's the unique identifier. That will make it easier down the road vs introducing another prop to manage for uniqueness.

[yasu_saberi]

This is very bad advice. Unique Ids in one db should not be used to determine the uniqueness of ids in another. Links between ids in various databases are fine; store as many ids from as many other databases that you like. But, a database by itself should determine the uniqueness of its own "records"

[mdfrenchman]

@yasu.saberi I agree. I was suggesting to create a uniqueness constraint on a non-nodekey property.