While creating the architecture of a new project I struggle to come up with a good solution to handle public IDs. For example our users will receive a membership card. Each card has the membership ID printed on it. But because in our branch of industry we expect cooperation with other businesses the format of those membership IDs may change in future, or we will use additional IDs.
Surely the membership ID is not the internal database primary key or something like this.
These are the two options I came up:
- The membership ID is a property of the user model.
- It is easy to query.
- But then we have to change the model and the database schema each time we have a new format.
- The membership ID has its own model which references the user model
- This is easy to extend.
- But then we have to join two tables for (more or less) each query
I know it depends strongly on many factors for which this question is to short to mention all, but is it bad practice to expect database schema changes instead of explicitly modelling this kind of flexibility. I mean this will only happen once in few years.
Or do you have some other ideas?