>> `site_id` varchar(50) NOT NULL,
> Why varchar(50)? UUIDs are 16-bytes.
Why do you think it's a UUID?
> The best way to store them would be the binary bytes (which is how postgres stores them).
Is it actually better than a pair of BIGINTs?
> Why varchar(50)? UUIDs are 16-bytes.
Why do you think it's a UUID?
> The best way to store them would be the binary bytes (which is how postgres stores them).
Is it actually better than a pair of BIGINTs?
Because of this:
>Also notice that we are not using serial keys; instead, we are using varchar(50), which stores client-generated GUID values
As long as it meets the statistical properties for collision, I don't see any problems with making a 50-bytes GUID. The essential thing is the statistical property, not the number of bits.
Like I mentioned, there are different UUID/GUID schemes using more than 128 bits publicly available already. You don't have to invent one. They may simply be using one of those with additional bytes reserved for future algorithmic changes (using first few bytes as a header to specify the algorithm).