If you're really ambitious you'll use two UUIDs for the ID, because for an app in which at least a billion people have at least 327 million random v4 UUIDs, the probability of a collision will be greater than 1%.
Avoid UUID Version 4 Primary Keys in Postgres
391–400 of 463 posts
Re: Avoid UUID Version 4 Primary Keys in Postgres
#392Earlier quoted context omitted.
Entropy says it's special. If you have a million dots and 10,000 coordinates, you have 10,000 ways for all the dots to land in the same coordinate, and a zillion kavillion stupillion ways to have somewhere near 100 dots in each coordinate.
No, if its randomly distributed then every specific configuration has the same exact chance of happening. I am laughing at all the people coming out of the woodwork to reply to my original post in this thread misunderstanding randomness and chance. If you flip a coin a million times and it lands on head every single time, the millionth and 1 time still has a 50/50 chance of landing on heads
> every specific configuration
Who said anything about specific configurations?
We started this talking about whether things "clump" or not. The result depends on your definition of "clump" but let's say it involves a standard deviation. Different standard deviations have wildly different probabilities, even when every specific configuration has the same probability.
Nobody responding to you is calculating things wrong. We're talking about the shape of the data. Categories. And those categories are different sizes, because they have different numbers of specific configurations in them.
> the millionth and 1 time
I don't see any connection between the above discussion and the gambler's fallacy?
Re: Avoid UUID Version 4 Primary Keys in Postgres
#393You probably don't want integer primary keys, and you probably don't want UUID primary keys. You probably want something in-between, depending on your use case. UUID is one extreme on this spectrum, which tries to solve all of the problems, including ones you might not have.
What's in-between? I posted the article because I'm in the middle of that choice and wanted to generate discussion/contradiction. So far, people have talked a lot about UUIDs, so I'm genuinely curious about what's in-between.
An example would be YouTube's video IDs. It's custom-fit for a purpose (security: no, avoiding the problem where people fish for auspicious YouTube video numbers or something: yes).
Another example would be a function that sorts the numbers 0 through 999 in a seemingly random order (but's actually deterministic), and then repeat that for each block of 1000 with a slight shift. Discourages casual numeric iteration but isn't as complex or cryptographically secure as UUID.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#394Earlier quoted context omitted.
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, tha…
If you have a busy system, a single sequence is going to be a pretty big performance bottleneck, since every resource creation will need to acquire a lock on that sequence.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#395Earlier quoted context omitted.
We all await your Nobel for finding a third type of gamete.
The person I was responding to was talking about gender, but if you want to talk about biology then https://en.wikipedia.org/wiki/Intersex#Prevalence https://en.wikipedia.org/wiki/Klinefelter_syndrome https://en.wikipedia.org/wiki/XXYY_syndrome https://en.wikipedia.org/wiki/XXXY_syndrome https://en.wikipedia.org/wiki/XXXYY_syndrome https://en.wikipedia.org/wiki/XXXXY_syndrome https://en.wikipedia.org/wiki/Trisomy_X I…
XXY/etc are all variations within a sex. The above poster is correct to point out that sex is defined entirely by the gamete size that one's body is organized around producing in anisogamous species like humans, and is binary.
Intersex is a misleading term, the better term is https://en.wikipedia.org/wiki/Disorders_of_sex_development. There are male DSDs and female DSDs. Even in the case of ovotestes, you'll have one gamete produced, and the other tissue will be nonfunctional.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#396Earlier quoted context omitted.
That is only true if you're using an extremely idiosyncratic definition of gender. As far as 95% of English speakers are concerned, gender is defined by the body you possess.
As far as nigh on 100% of Bugis speakers are concerned there has always been five genders and they'll tell you the words in their language they have for them. * https://en.wikipedia.org/wiki/Buginese_language It appears to be a cultural construct.
You and the other person are probably talking past each other. For most people, "gender" is merely the polite way of saying "sex", and that's probably what the other commenter was referring to.
Gender in the sense of "the social roles and norms on top of biological sex" is indeed a construct, though heavily informed by the biology that they're based on. Biological sex is very much real and not a construct.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#397Earlier quoted context omitted.
The person I was responding to was talking about gender, but if you want to talk about biology then https://en.wikipedia.org/wiki/Intersex#Prevalence https://en.wikipedia.org/wiki/Klinefelter_syndrome https://en.wikipedia.org/wiki/XXYY_syndrome https://en.wikipedia.org/wiki/XXXY_syndrome https://en.wikipedia.org/wiki/XXXYY_syndrome https://en.wikipedia.org/wiki/XXXXY_syndrome https://en.wikipedia.org/wiki/Trisomy_X I…
XXY/etc are all variations within a sex. The above poster is correct to point out that sex is defined entirely by the gamete size that one's body is organized around producing in anisogamous species like humans, and is binary. Intersex is a misleading term, the better term is https://en.wikipedia.org/wiki/Disorders_of_sex_development . There are male DSDs and female DSDs. Even in the case of ovotestes, you'll have on…
And yet, the original person I was responding to spoke about gender.
If you are going to step into this argument, please do not move the goalposts
edit: I've triggered the HN censor bot, so editing to apologize to EnergyAmy, they are correct on their point. I am still going to throw back at brigandish that they moved the goalposts
Re: Avoid UUID Version 4 Primary Keys in Postgres
#398Earlier quoted context omitted.
XXY/etc are all variations within a sex. The above poster is correct to point out that sex is defined entirely by the gamete size that one's body is organized around producing in anisogamous species like humans, and is binary. Intersex is a misleading term, the better term is https://en.wikipedia.org/wiki/Disorders_of_sex_development . There are male DSDs and female DSDs. Even in the case of ovotestes, you'll have on…
And yet, the original person I was responding to spoke about gender. If you are going to step into this argument, please do not move the goalposts edit: I've triggered the HN censor bot, so editing to apologize to EnergyAmy, they are correct on their point. I am still going to throw back at brigandish that they moved the goalposts
I'm responding specifically to your comment in regards to "but if you want to talk about biology then" followed by a list of biological variations that don't dispute the sex binary. The goalposts are exactly where you've left them.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#399I didn't see my primary use case for UUID's covered: sharing identifiers across entities is dangerous.
I wrote a CRUD app for document storage. It had user id's and document id's. I wrote a method GetDocumentForUser(docID, userID) that checked permissions for that user and document and returned the document if permitted. I then, stupidly, called that method with GetDocumentForUser(userID, docID), and it took me a good half hour to work out why this never returned anything.
It never returned anything because a valid userID will never be a valid docID. If I had used integers it would have returned documents, and I probably wouldn't have spotted it while testing, and I would have shipped a change that cheerfully handed people other people's documents.
I will put up with a fairly considerable amount of performance hit to avoid having this footgun lurking. And yes, I know there are other ways around this (e.g. types) but those come with their own trade-offs too.
Re: Avoid UUID Version 4 Primary Keys in Postgres
#400Earlier quoted context omitted.
This is actually a very deep and interesting topic. Stripping information from an identifier disconnects a piece of data from the real world which means we no longer can match them. But such connection is the sole purpose of keeping the data in the first place. So, what happens next is that the real world tries to adjust and the "data-less" identifier becomes a real world artifact. The situation becomes the same but…
> Stripping information from an identifier disconnects a piece of data from the real world which means we no longer can match them. But such connection is the sole purpose of keeping the data in the first place. The identifier is still connected to the user's data, just through the appropriate other fields in the table as opposed to embedded into the identifier itself. > So, what happens next is that the real world t…
> You can still look up their data from their current email or phone number, for instance. Indexes are not limited to the primary key.
This is the key point, I think. Searching is not the same as identifying.