| Friday December 19th 2014

Feedburner

Subscribe by email:

We promise not to spam/sell you.


Search Amazon deals:

GUIDs are Great


Whenever someone says they’re going to use a GUID for something, I make it a point to always respond, “No!  Don’t use a GUID there!  If you use one there, eventually you’ll use them all up and we won’t have any left!”

you are uniqueOf course, GUIDs don’t get “used up,” and there are plenty to go around (enough for every star in the observable universe to have about 6.8 quadrillion GUIDs to itself), but this point if this post is to tell you how to use them.

A Globally-Unique Identifier (GUID) is generated algorithmically, usually using your network card’s MAC address (edit: this is no longer the case, please see comments below) as well as the number of 100 nanosecond periods elapsed since 12:00 AM on October 15, 1582 (naturally).  Using these two pieces of data ensures that your computer won’t generate the same GUID twice and two different computers won’t generate the same GUID at the same time.  It’s not a “100% guarantee” but it’s very, very reliable.  What you get is something that looks like this (as a string):

3F2504E0-4F89-11D3-9A0C-0305E82C3301

Despite being a bit unwieldly to type and look at, GUIDs are really good for uniquely identifying logs, transactions, database records and all kinds of things in your code.  On modern hardware, they can be generated quickly and the standard algorithm allows for 10 million GUIDs to be generated per second without conflict.

Often developers will use a timestamp, a random number or both to try to unique-ify some filename or result.  This is called “reinventing the wheel.”  Use a GUID instead, any time you want to tag anything that can’t have a conflict.  Save yourself future headaches.

If you want to see the classic example of a bug resulting from the practice of using a timestamp as a unique id, look no further than Lotus Notes.  In older versions of Notes, “unique” document ids were generated using a timestamp with a resolution of 1/100th of a second.  To avoid an id conflict when new documents were created very quickly, the implementation would increment an internal counter when it saw a conflict in ids.  The end result was that if you managed to create, say, 100,000 documents in a single second, you would have documents that appeared to be created 1,000 seconds (about 16 minutes) in the future (since the unique id and the create date were actually the same field).  This disconnect with reality then could cause databases to fail to replicate properly.  The problem actually still exists in current versions of Notes, although it has been alleviated by some other architectural changes (but they still use creation date as the unique id).

In defense of the Lotus Notes developers, when it was designed, there was no hardware that could generate records that quickly, and I’m fairly certain that the GUID standard wasn’t around at the time.

Nowadays, there’s no excuse to roll your own unique identifier system.  Use a GUID!

If you’re interested in the internals of how GUID generation is implemented, I’d recommend looking at this document (PDF).

Related Posts: On this day...

Leave a Reply

You must be logged in to post a comment.