Use _ID as primary key?

[dgllghr]

Is there a way to use the autogenerated _ID as the primary key for entities?

[andyfengHKU]

Hi @dgllghr,

It's not recommended to use _ID as the primary key as it's meant for internal usage and should be read only. May I know what's the main reason that you want to use it as the primary key?

[semihsalihoglu-uw]

Interesting. What identifies the nodes in the original/source database? I assume something (maybe a system-level property) must be identifying them.

[andyfengHKU]

I believe primary key is necessary because edges need to be defined over unique identifier between nodes. And these unique identifier (which should come from outside of the system) usually serves as the primary key.

[dgllghr]

Some of the labels have a unique constraint applied to them, but most are just identified by their system generated ID.

Something else that would work here is the ability to have property level permissions or some kind of VIEW-like functionality (I don't know how that would even work in a graph database though) so I could hide the property. I know this is probably a much bigger thing to consider but I just want to get your thoughts on it.

BTW, as someone who comes from the relational world, Kuzu makes a lot more sense to me and I have really been enjoying using it.

[semihsalihoglu-uw]

I see. So in short, we do need a primary key to be defined somehow to identify the nodes. We might consider having a shortcut that uses a default PK for nodes, i.e., if PK is not defined in the node table schema definition, we add a default SERIAL "ID" or "{tablename}_ID" column, but it would still be visible to you. So not sure what to recommend for now. We would need a longer discussion if having the internal _ID as a default PK if PK is not defined but having PK for node tables is a core assumption in the system, so I'm not very optimistic it would be easy to drop this assumption. We would need to evaluate its feasibility.

For Kuzu looking relational: Great to hear! We are quite open and proud in saying that Kuzu (and frankly almost all other DBMSs) are relational at their cores, even if the data model and query languages have graph-specific features.

[dgllghr]

Makes sense. Thanks for the info!