Re:Avoid UUIDv4 Primary Keys
by vrighter on Monday December 15, 2025 @08:54AM
(#46274563)
You can't take into account the fact that things change when you don't know what those changes might be. You might end up needing to either rebuild a new database, have some painful migration, or support two codepaths to work with both types of keys.
[ Parent
| on HN ]
Network protocol designers know better and by default embed protocol version number in message format spec.
I guess you can assign 3-4 bits for identifier version number as well.
And yes - for long living data dealing with compatibility issues is inevitable so you have to take that into account from the very beginning.
when I designed network protocols this is exactly what I did. I also did so in file formats had to create. But a database primary kea is not somewhere where that can be easily done.
Re:Avoid UUIDv4 Primary Keys
by groundzeros2015 on Monday December 15, 2025 @10:59AM
(#46276178)
You can’t design something by trying to anticipate all future changes. things will change and break.
In my personal design sense, I have found keeping away generality actually helps my code last longer (based on more concrete ideas) and easier to change when those days come.
In my experience, virtually every time I bake concrete data into identifiers I end up regretting it. This isn’t a case of trying to predict all possible future changes. It’s a case of trying to not repeat the exact same mistake again.
Re:Avoid UUIDv4 Primary Keys
by groundzeros2015 on Monday December 15, 2025 @03:33PM
(#46280197)
I don’t disagree with that, I’m disagreeing with this comment that we can’t make protocol or data decisions that might change.