3 ms·
>> `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 byte
by tagrun 10y ago
>> `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?
- wtetzner 10y ago>Why do you think it's a UUID? Because of this: >Also notice that we are not using serial keys; instead, we are using varchar(50), which stores client-generated GUID values
- tagrun 10y agoGUID and UUID refer to different things in general. Also, depending on the context, they can be longer than 128-bits. Oracle Coherence API defines 256-bit UUIDs for example (which is clearly not RFC 4122 or Microsoft GUID, but it still is an identifying number which can statistically be called unique, which a UUID is). 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.
- mdellabitta 10y agoDo you think it's more likely that they invented a unique id scheme that requires 50 bytes, or that they're using an overly wide datatype for ordinary UUIDs?
- tagrun 10y agoAnd I have to pick one of those two options? 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).
- mdellabitta 10y agoBut is it likely that they are? I would imagine no.