4 ms·
Sorry I'm a bit confused. I'm in agreement that a natural key shouldn't be used as the primary key for a record. I was responding to a comment about having a
by Jarwain 1y ago
Sorry I'm a bit confused.
I'm in agreement that a natural key shouldn't be used as the primary key for a record.
I was responding to a comment about having a hidden "database ID" (which I interpreted as being a serial key?) and a public "Uuid", and questioning the utility of that hidden database ID versus having a public UUIDv7 as the sole primary key, followed by questioning whether the utility of obscuring that primary UUIDv7 is worth the complexity of having to manage multiple artificial keys.
I agree that security through obscurity is a valuable layer in a multi-layered security position.
I guess I just don't think obscuring a Uuid primary key is worth the added complexity in most systems.
I see it like adding a second front door to your house with a separate set of keys. Sure it'd be more secure, but it's an added pain and doesn't help if you don't have a sturdy doorframe, or smash-resistant windows.
- ringeryless 1y agoUUID is PUBLIC id, use it to look up the bigint numerical id, when necessary. one should not divulge scale, placement in numerical sequence, etc wtr to integer id, hence ouvlic UUID, which is basically unguessable token
- Jarwain 1y agoWhy have a bigint numerical ID at all?
- ringeryless 1y agofast lookup for internal usage. it's significantly faster than a UUID on every DBMS i have ever seen
- Jarwain 1y agoThat's a good reason! I think with UUIDv7, because it's sequential it's indexes are faster than UUIDv4. Still larger than bigints though. I'd like to do a benchmark at some point