231–240 of 246 posts
Earlier quoted context omitted.
You still have to know that 0 is 0 and not O, and that 1 is 1 and not I or l.
but if mistake is made, and you wrote down L instead of 1, and sent me in a e-mail. I, knowing that it is crockford 32, would easily deduce what mistake was made.
Earlier quoted context omitted.
You still have to know that 0 is 0 and not O, and that 1 is 1 and not I or l.
but if mistake is made, and you wrote down L instead of 1, and sent me in a e-mail. I, knowing that it is crockford 32, would easily deduce what mistake was made.
Earlier quoted context omitted.
Because simple integers are not universally unique, a major feature of UUIDs…
UUIDs are integers, they just happen to be 128 bits long instead of the more common 32 or 64, and they are usually printed in a specific way that differs from how integers are usually printed. But that's just smoke and mirrors. UUIDs are generally not guaranteed to be universally unique. The name is misleading marketing. If you generate them randomly, then the probability of collision is small enough not to matter, b…
Earlier quoted context omitted.
That is…not what universally unique means.
From RFC4122: "A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs." Hard to achieve if everyone starts from 00000000-0000-0000-0000-000000000000.
Earlier quoted context omitted.
> Or reverse the time fields during indexing (slower, but still not as slow as an unnecessary disk read!). When you're IO bound, I'm not sure it actually is slower in practice.
Depending on caching strategy, using random UUIDs also decreases the maximum working set size before you become I/O bound by a huge factor. Postgres e.g. relies heavily on the O/S block cache and is subject to this.
I wasn't discussing using random UUIDs.
I'm sure I take bigger penalty hits for less, sorry but UUID's "click" in my head and they prevent a whole slew of foot-guns. It would be one thing if auto-inc was the same as UUID but there are really annoying things with auto-inc (not knowing the id until after insert being top of mind) and also you can generate UUID's client-side/offline if needed. Yes, I know some people argue for auto-inc as primary and still us…
Why would anyone use a random value as a primary key? I haven’t done databases in a long time but isn’t it standard practice to use a sequential incrementing value for the primary key?
reasons are: 1. no need for coordination in distributed system, no need to check what is the next available id. 2. if userid is visible to users, sequential userid gives away information about the amount of users and allows guessing other valid userids.
Earlier quoted context omitted.
Depending on caching strategy, using random UUIDs also decreases the maximum working set size before you become I/O bound by a huge factor. Postgres e.g. relies heavily on the O/S block cache and is subject to this.
> using random UUIDs I wasn't discussing using random UUIDs.
Earlier quoted context omitted.
"Bad for performance as primary keys" -> "Bad for performance as primary keys in MySQL". This isn't an issue in PostgreSQL and perhaps the lesson here is that as you scale, you need to understand more about the internals of the DB system you've chosen. This isn't limited to RDBMS as it's pretty easy to show trade-offs in choosing a NoSQL as well.
They are still generally found to be slower to use than sequential primary keys in postgresql.
Earlier quoted context omitted.
Even in MySQL - one can use Sequential UUIDs.
I never understood why people would use sequential UUIDs. That rather defeats the purpose of a UUID. If you need something sequential then just use a much more simple number
Each GUID generated by using NEWSEQUENTIALID is unique on that computer. GUIDs generated by using NEWSEQUENTIALID are unique across multiple computers only if the source computer has a network card.