4 ms·

I think she's refuting the idea that GUID primary keys are a one-size-fits-all solution for database design. Jeff Atwood discussed some of the pros and cons of

I think she's refuting the idea that GUID primary keys are a one-size-fits-all solution for database design. Jeff Atwood discussed some of the pros and cons of this approach a few years ago [1]. The force does seem a little odd, though, and the use of all-caps words and bold/underlined text throughout the article made it harder to read and understand. The take-away, as far as I can tell, is that database design requires some analysis of what's best for one's particular data set, rather than duplicating what looks hot right now. Which is a good idea in any context if performance really matters. [1] http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html http://www.codinghorror.com/blog/2007/03/primary-keys-ids-ve...

famousactress 15y ago
GUIDs are weird, but global ids are awesome. I'm not really sure what reason I'd have to use GUIDs instead of assigning ids out of a single 64bit int key space.. What am I missing? But seriously. Global-id-space is something I'll probably use on every new project I touch... presumably for the same reasons people use GUIDs. So nice to know that you can change data types, pack things into caches without type-ids, or log identifiers without extra metadata. Super handy.
- steve-howard 15y ago
  I'm not familiar with the type of global IDs you're referring to, I'm afraid. A GUID is essentially assigning an ID out of a 128-bit integer keyspace, with the idea that collisions will be highly improbable if used correctly. Any database I've ever designed has been on a very small scale (weekend project kind of stuff), and the real scalable databases I've used were designed by people way smarter than me. Some of them used GUIDs and some didn't, and I have no idea what informed those choices.
  - PaulHoule 15y ago
    The nice thing about GUIDs is that any node in a distributed system can make one at any time and you know that a collision is impossible or almost impossible. On the other hand, they take up a lot of space, in particular, they fill RAM. They make the most used indexes in your system large and slow. Practically, the need for GUIDs can be eliminated by establishing a server that works like the "take a ticket" machine at the supermarket. Any node that makes a new object makes an API call and gets a new id.
    - famousactress 15y ago
      Yes, exactly... and if the cost of getting new keys piece-meal is too expensive, the 'ticket machine' can dole them out in blocks to nodes for fast local-allocation.
      - lukesandberg 15y ago
        No need to create a ticket machine, the db can probably do this for you. I've accomplished this with oracle sequences (supports grabbing blocks of ids). I assume there are similar capabilities in other db systems.
        PaulHoule 15y ago
        In that case, your database is the ticket machine.
- jbri 15y ago
  How are you ensuring global-uniqueness in your global id space when you have multiple systems that may not even be in contact with each other a lot of the time?
  - eru 15y ago
    Like steve-howard said: You choose randomly from a large enough space. That way you can make collisions as improbable as you like. (You can also add an identifier for each system and the current time, if you don't trust your source of randomness. But that's beside the point.)
    - jbri 15y ago
      So in other words, roll your own GUID implementation? Instead of using the built-in, highly-tested stuff?
      - eru 15y ago
        Oh, I was just answering the question in general. The standard GUID implementations use that trick somewhere, too.
    - saurik 15y ago
      That's not what steve-howard said, and it certainly isn't how GUID/UUIDs work: they are based on a combination of your MAC address, a process ID, a sequential ID, a timestamp, and a random number; with this algorithm, global uniqueness is confirmed. A "type 4" UUID, or as we like to call "not a UUID", is a 128-bit random number, and only got defined to retroactively deal with use cases of UUID that caused "too much information leakage" (such as Word documents).
      - eridius 15y ago
        Global uniqueness is certainly not "confirmed". With a 128-bit key, you have at most 2^128 different values (and it's actually slightly less because I think the different UUID schemes all reserve at least one digit). Sure, collisions are extremely unlikely, but they are also extremely unlikely with the simple 128-bit random number.

famousactress 15y ago

GUIDs are weird, but global ids are awesome. I'm not really sure what reason I'd have to use GUIDs instead of assigning ids out of a single 64bit int key space.. What am I missing? But seriously. Global-id-space is something I'll probably use on every new project I touch... presumably for the same reasons people use GUIDs. So nice to know that you can change data types, pack things into caches without type-ids, or log identifiers without extra metadata. Super handy.

steve-howard 15y ago
I'm not familiar with the type of global IDs you're referring to, I'm afraid. A GUID is essentially assigning an ID out of a 128-bit integer keyspace, with the idea that collisions will be highly improbable if used correctly. Any database I've ever designed has been on a very small scale (weekend project kind of stuff), and the real scalable databases I've used were designed by people way smarter than me. Some of them used GUIDs and some didn't, and I have no idea what informed those choices.
- PaulHoule 15y ago
  The nice thing about GUIDs is that any node in a distributed system can make one at any time and you know that a collision is impossible or almost impossible. On the other hand, they take up a lot of space, in particular, they fill RAM. They make the most used indexes in your system large and slow. Practically, the need for GUIDs can be eliminated by establishing a server that works like the "take a ticket" machine at the supermarket. Any node that makes a new object makes an API call and gets a new id.
  - famousactress 15y ago
    Yes, exactly... and if the cost of getting new keys piece-meal is too expensive, the 'ticket machine' can dole them out in blocks to nodes for fast local-allocation.
    - lukesandberg 15y ago
      No need to create a ticket machine, the db can probably do this for you. I've accomplished this with oracle sequences (supports grabbing blocks of ids). I assume there are similar capabilities in other db systems.
      - PaulHoule 15y ago
        In that case, your database is the ticket machine.
jbri 15y ago
How are you ensuring global-uniqueness in your global id space when you have multiple systems that may not even be in contact with each other a lot of the time?
- eru 15y ago
  Like steve-howard said: You choose randomly from a large enough space. That way you can make collisions as improbable as you like. (You can also add an identifier for each system and the current time, if you don't trust your source of randomness. But that's beside the point.)
  - jbri 15y ago
    So in other words, roll your own GUID implementation? Instead of using the built-in, highly-tested stuff?
    - eru 15y ago
      Oh, I was just answering the question in general. The standard GUID implementations use that trick somewhere, too.
  - saurik 15y ago
    That's not what steve-howard said, and it certainly isn't how GUID/UUIDs work: they are based on a combination of your MAC address, a process ID, a sequential ID, a timestamp, and a random number; with this algorithm, global uniqueness is confirmed. A "type 4" UUID, or as we like to call "not a UUID", is a 128-bit random number, and only got defined to retroactively deal with use cases of UUID that caused "too much information leakage" (such as Word documents).
    - eridius 15y ago
      Global uniqueness is certainly not "confirmed". With a 128-bit key, you have at most 2^128 different values (and it's actually slightly less because I think the different UUID schemes all reserve at least one digit). Sure, collisions are extremely unlikely, but they are also extremely unlikely with the simple 128-bit random number.