What is the current, CUBA-esque way to do composite primary keys?

Support
#1

We have a number of places in the system we’re converting where we use and need composite primary keys. The first example I’m working on is our Patient --> Registration layer. Each patient can have from zero to infinity registrations (a normal master-detail type thing) - each registration is denoted by a date. There can only be one registration per date. We’ve handled this by having the PK for registration be patient_id + date.

I’ve been doing quite a bit of searching and all the references to composite keys go way back - 2015, 2016, and most of the latest around 2017. Many of them discouraged using composite keys at all, though the latest didn’t and suggested using an embedded type as the PK.

None of these examples showed a case where the composite PK also references a master (in this case patient).

Does such an example exist, or is there a newer, better way to do this?

#2

Hi @jon.craig,

It is not impossible to use composite PKs, but your work would be a lot harder. So I would avoid using composite PK if possible. It is way easier using single fields as PK for the table.

You can use Unique Constraints for this kind of requirement. Example in Cuba Studio:
image

That is one of the reasons for not using composite PK :slight_smile:. If you use single field pks, associations to other entities are way easier.

Regards.

3 Likes