3 ms·

In a recent large project, I moved to using GUIDs. Following advice from this article: http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-und

In a recent large project, I moved to using GUIDs. Following advice from this article: http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database http://www.codeproject.com/Articles/388157/GUIDs-as-fast-pri... it was fairly straightforward and performant. Obviously YMMV (as may your definition of 'large' and 'performant').

deathanatos 12y ago
UUIDs are wonderful: they're fairly small (16 bytes), and can be generated on multiple servers independently with no coordination. If you use version 4 or 5 UUIDs, the first couple of bytes are random, so short-circuiting comparisons should in theory bail quickly… but I've never had a need to measure. Perhaps the only gotcha I've run into is that JS can't reliably generate them. (You need a decent RNG, and while JS has an RNG, no guarantees are made about it.) (Trivially work-aroundable with an AJAX endpoint on the server, of course.)
- AaronBBrown 12y ago
  Strictly speaking they are 16 bytes when stored as binary, which sounds grat, but when represented as strings (as they usually are) they are 36 characters which is 36-bytes in ASCII, but 108(!) bytes in 3-byte unicode. So, in practice they are terrible primary keys in systems that do not have a native UUID type. In that case, an 8-byte bigint generated externally by a ticket service like Snowflake is often far superior.
  - deathanatos 12y ago
    > they are 36 characters which is 36-bytes in ASCII, but 108(!) bytes in 3-byte unicode. I'm going to argue that that's not the norm: "3-byte unicode" is kinda WTF, since it doesn't really exist. If you're in UTF-8, it's a 36 byte comparison. That sounds, however, a lot like MySQL, which has perhaps one of the more braindead "UTF-8" implementations. That said, I'm not sure that it uses 3 bytes for code points that don't require it. (At least, that it spaces them that way: there may be nulls past the data, sure, but those won't count in a comparison.)

deathanatos 12y ago

UUIDs are wonderful: they're fairly small (16 bytes), and can be generated on multiple servers independently with no coordination. If you use version 4 or 5 UUIDs, the first couple of bytes are random, so short-circuiting comparisons should in theory bail quickly… but I've never had a need to measure. Perhaps the only gotcha I've run into is that JS can't reliably generate them. (You need a decent RNG, and while JS has an RNG, no guarantees are made about it.) (Trivially work-aroundable with an AJAX endpoint on the server, of course.)

AaronBBrown 12y ago
Strictly speaking they are 16 bytes when stored as binary, which sounds grat, but when represented as strings (as they usually are) they are 36 characters which is 36-bytes in ASCII, but 108(!) bytes in 3-byte unicode. So, in practice they are terrible primary keys in systems that do not have a native UUID type. In that case, an 8-byte bigint generated externally by a ticket service like Snowflake is often far superior.
- deathanatos 12y ago
  > they are 36 characters which is 36-bytes in ASCII, but 108(!) bytes in 3-byte unicode. I'm going to argue that that's not the norm: "3-byte unicode" is kinda WTF, since it doesn't really exist. If you're in UTF-8, it's a 36 byte comparison. That sounds, however, a lot like MySQL, which has perhaps one of the more braindead "UTF-8" implementations. That said, I'm not sure that it uses 3 bytes for code points that don't require it. (At least, that it spaces them that way: there may be nulls past the data, sure, but those won't count in a comparison.)