Snowflake or sonyflake ids work:
Avoid UUID Version 4 Primary Keys in Postgres
331–340 of 463 posts
Re: Avoid UUID Version 4 Primary Keys in Postgres
#332I was born in the Vancouver Social Security office #538 area in 1962.
Guess how much I have to defend against attackers trying 538-62-xxxx
Re: Avoid UUID Version 4 Primary Keys in Postgres
#333Earlier quoted context omitted.
> Norwegian PNs have your birth date (in DDMMYY format) as the first six digits. Surely that doesn't change, right? Well, wrong, since although the date doesn't change, your knowledge of it might. Immigrants who didn't know their exact date of birth got assigned 1. Jan by default... And then people with actual birthdays on 1 Jan got told, "sorry, you can't have that as birth date, we've run out of numbers in that ser…
>To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. You still have that problem from organic birthdays and also the problem of needing to change ids to correct birth dates.
To add to that, birthdays can clump, just like any seemingly "random" data.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#334A prime example of premature optimization. Permanent identifiers should not carry data . This is like the cardinal sin of data management. You always run into situations where the thing you thought, "surely this never changes, so it's safe to squeeze into the ID to save a lookup". Then people suddenly find out they have a new gender identity, and they need a last final digit in their ID numbers too. Even if nothing c…
Uuid v7 just has a bias in its generation; it isn't carrying information. You're not going to try and extract a timestamp from a uuid. Random vs time biased uuids are not a decision to shave off ms that you will regret. Most likely they will be a decision that shaves off seconds (yes, really - especially when you consider locality effects) and you'll regret nothing.
> You're not going to try and extract a timestamp from a uuid.
So, random library: https://pkg.go.dev/github.com/google/uuid#UUID.Time
> Time returns the time in 100s of nanoseconds since 15 Oct 1582 encoded in uuid. The time is only defined for version 1, 2, 6 and 7 UUIDs.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#335Meh, uuid go brrrrrrrrrrrrrrrrrrrrrrrrr
Re: Avoid UUID Version 4 Primary Keys in Postgres
#336A prime example of premature optimization. Permanent identifiers should not carry data . This is like the cardinal sin of data management. You always run into situations where the thing you thought, "surely this never changes, so it's safe to squeeze into the ID to save a lookup". Then people suddenly find out they have a new gender identity, and they need a last final digit in their ID numbers too. Even if nothing c…
counterpoint: IRL, data values in a system like PostgreSQL are padded to word boundaries so either you're wasting bits or "carrying data."
Re: Avoid UUID Version 4 Primary Keys in Postgres
#337Earlier quoted context omitted.
In Postgres I often like to use a single sequence for everything. It leaks some information yes but in a busy system it tends to be "obscure enough".
It's not leaking that's the concern. It's that not having the names of objects be easily enumerable is a strongly security-enhancing feature of a system. Yes of course everyone should check and unit test that every object is owned by the user or account loading it, but demanding more sophistication from an attacker than taking "/my_things/23" and loading "/my_things/24" is a big win.
With a single sequence and a busy system, the ids for most high-level tables/collection are extremely sparse. This doesn't mean they can't be enumerated, but you will probably notice if you suddenly start getting hammered with 404s or 410s or whatever your system generates on "not found".
Also, if most of your endpoints require auth, this is not typically a problem.
It really depends on your application. But yes, that's something to be aware of. If you need some ids to be unguessable, make sure they are not predictable :-)
Re: Avoid UUID Version 4 Primary Keys in Postgres
#338Earlier quoted context omitted.
Nobody forces you to use a real Unix timestamp. BTW the original Unix timestamp is 32 bits (expiring in 2038), and now everyone is switching to 64-bit time_t. What 48 bits? All you need is a guaranteed non-decreasing 48-bit number. A clock is one way to generate it, but I don't see why a UUIDv7 would become invalid if your clock is biased, runs too fast, too slow, or whatever. I would not count on the first 48 bits b…
> Nobody forces you to use a real Unix timestamp. Besides the UUIDv7 specification, that is? Otherwise you have some arbitrary kind of UUID. > I would not count on the first 48 bits being a "real" timestamp. I agree; this is the existential hazard under discussion which comes from encoding something that might or might not be data into an opaque identifier. I personally don't agree as dogmatically with the grandparen…
That is like the HTML specification -- nobody ever puts up a web page that is not conformant. ;p
The idea behind putting some time as prefix was for btree efficiency, but lots of people use client side generation and you can't trust it, and it should not matter because it is just an id not a way of registering time.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#339From the fine article: > Random values don’t have natural sorting like integers or lexicographic (dictionary) sorting like character strings. UUID v4s do have "byte ordering," but this has no useful meaning for how they’re accessed. Might the author mean that random values are not sequential, so ordering them is inefficient? Of course random values can be ordered - and ordering by what he calls "byte ordering" is exa…
To be polite, I don't think this article rests on sound technical foundations.
How so?
Re: Avoid UUID Version 4 Primary Keys in Postgres
#340Earlier quoted context omitted.
>To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. You still have that problem from organic birthdays and also the problem of needing to change ids to correct birth dates.
To add to that, birthdays can clump, just like any seemingly "random" data.
A million dots scattered randomly over a graph can all land on the exact same coordinate if it’s truly random.
What most people intuit as random is some sort of noise function that is generally dispersed and doesn’t trigger the pattern matching part of their brain