2 ms·
There's a simple fix - Don't you ever expose primary keys to the users. Ever. Seriously, ever. A primary key is not an order id, it isnt a person identifier,
by hobs 7y ago
There's a simple fix - Don't you ever expose primary keys to the users.
Ever.
Seriously, ever.
A primary key is not an order id, it isnt a person identifier, it isnt a paycheck - its a thing the database should be using behind the scenes.
All of the things I just mentioned change - besides the primary key.
You'll never have this problem if you separate your business logic from your keys.
- Terr_ 7y agoQuite. Not only does it protect you from architecture pain later, but it also allows you to create business-keys that humans have an easier time reading, comparing, and typing. The implicit requirement of a global always-online single master counter is great until it isn't. Perhaps one day it becomes a performance bottleneck, or you have to support systems that create provisional items offline, or some law or client-contract stipulates everything for them must live in a daughter-system hosted inside/not-inside a particular country...
- Macha 7y agoThis is why I'm skeptical of the suggestion to prefer a natural primary key like a username. It works fine... until they day the business asks for changeable usernames because BigClient is now LargeClient and can't stand anything to still have their old brand identity.
- hobs 7y agoEven in the natural key's playground (in my mind) of data warehousing, you still have to manage changing dimensions, and the inevitable reality that your fact table was actually another dimension table all long.