Record IDs vs Primary Keys


My product currently uses a relational database with the primary key for most “objects” being a unique long that is auto generated.

The database is also setup as multi-tenant with each user having their own database.

I would like to transition to OrientDb and maintain the multi-tenant model and the unique long primary key design. The Record ID in OrientDB is unique and would work except that it has two parts, not a single long. I believe I could get around this problem by limiting each class to a single cluster and therefore just use the cluster position as the unique ID. However, the documentation states that the default behavior is to create n clusters per class where n is the number of CPUs.

Is there a way to limit the system to 1 cluster per class instead?

If not, how would I go about maintaining the unique long ID (primary key) for a class?




You can force the number of clusters per class changing the MINIMUMCLUSTERS option on the database

In general, using the RID as an application-level primary key is not a good idea for a few reasons:

  • you cannot manually assign it, that means that for instance if you delete a record you cannot re-create it with the same key
  • it can change when you export/import the database
  • it is unique only at db level, ie. on two different databases you will have the same RIDs

We always suggest to use a document attribute when you need an application key