GUID Guide, part one
What is a GUID? The acronym stands for "globally unique identifier"; GUIDs are also called UUIDs, which stands for "universally unique identifier". (It is unclear to me why we need two nigh-identical names for the same thing, but there you have it.) A GUID is essentially a 128 bit integer, and when written in its human-readable form, is written in hexadecimal in the pattern {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.
The purpose of a GUID is, as the name implies, to uniquely identify something, so that we can refer to that thing by its identifier and have confidence that everyone can agree upon what thing we are referring to. Think about this problem as it applies to, say, books. It is cumbersome to refer to a book by quoting it in its entirety every time you mention it. Instead, we give every book an identifier in the form of its title. The problem with using a title as an identifier is that there may be many different books with the same title. I have three different books all entitled "The C# Programming Language" on my desk right now; if I want to refer to one of them in particular, I'd typically have to give the edition number. But there is nothing (apart from their good sense) stopping some entirely different publisher from also publishing a book called "The C# Programming Language, fourth edition" that differs from the others.
Publishers have solved this problem by creating a globally unique identifier for each book called the International Standard Book Number, or ISBN. This is the 13-decimal-digit bar coded number you see on pretty much every book(*). How do publishers manage to get a unique number for each of the millions of books published? They divide and conquer; the digits of an ISBN each have a different meaning. Each country has been assigned a certain range of ISBN numbers that they can allocate; governments then further allocate subsets of their numbers to publishers. Publishers then decide for themselves how to assign the remaining digits to each book. The ISBNs for my three editions of the C# spec are 978-0-321-15491-6, 978-0-321-56299-9 and 978-0-321-74176-9. You'll notice that the first seven digits are exactly the same for each; they identify that this is a publishing industry code (978), that the book was published in a primarily English-speaking region (0), by Addison-Wesley (321). The next five digits are Addison-Wesley's choice, and the final digit is a checksum. If I wish to uniquely identify the fourth edition of the C# specification I need not state the ambiguous title at all; I can simply refer you to book number 978-0-321-74176-9, and everyone in the world can determine precisely which book I'm talking about.
An important and easily overlooked characteristic of the ISBN uniqueness system is that it only works if everyone who uses it is non-hostile. If a rogue publisher decides to deliberately publish books with the ISBN numbers of existing books so as to create confusion then the usefulness of the identifier is compromised because it no longer uniquely identifies a book. ISBN numbers are not a security system, and neither are GUIDs; ISBN numbers and GUIDs prevent accidental collisions. Similarly, traffic lights only prevent accidental collisions if everyone agrees to follow the rules of traffic lights; if anyone decides to go when the light is red then collisions might no longer be avoided, and if someone is attempting to deliberately cause a collision then traffic lights cannot stop them.
The ISBN system has the nice property that you can "decode" an ISBN and learn something about the book just from its number. But it has the enormous down side that it is extraordinarily expensive to administer. There has to be international agreement on the general form of the identifier and on what the industry and language codes mean. In any given country there must be some organization (either a government body or private companies contracted by the government) to assign numbers to publishers. It can cost hundreds of dollars to obtain a unique ISBN.
GUIDs do not have this cost problem; GUIDs are free and there is no requirement that any governing body get involved to ensure their uniqueness. A GUID is a number that you can generate yourself and be guaranteed that no one else in the world will generate that same number. That seems a bit magical. How does that work? Over the next couple of episodes we'll take a look at how that magical property is achieved.
(*) The attentive reader will note that there are usually two bar codes on a book in the United States. The first one is the ISBN; the second bar code is the number 5 followed by a four digit number that is the publisher's suggested price of the book in American pennies.
Comments
Anonymous
April 23, 2012
An interesting choice of topic, but something well work explaining. Great post and looking forward to the others in the series.Anonymous
April 23, 2012
> It is unclear to me why we need two nigh-identical names for the same thing This reminds me of URI and URL.Anonymous
April 23, 2012
Seems like a poor analogy to me. I would expect a GUID to identity a particular instance of a book, not a particular title. Perhaps an SSN would be a better analogy?Anonymous
April 23, 2012
"GUIDs are free and there is no requirement that any governing body get involved to ensure their uniqueness." Who's in charge of MAC addresses? (As for type 4 GUIDs - well, they're not actually unique, just statistically unlikely to collide).Anonymous
April 24, 2012
Looking forward to reading this series.Anonymous
April 24, 2012
>> It is unclear to me why we need two nigh-identical names for the same thing >This reminds me of URI and URL. Except URIs and URLs are not the same thing. URLs are a subset of URIs. And incidentally, ISBN numbers are URIs too ^^Anonymous
April 24, 2012
>Seems like a poor analogy to me. I would expect a GUID to identity a particular instance of a book, not a particular title. A class ID is a GUID that refers to a particular title, rather than a specific book, no? In fact most objects don't have their own GUIDs, but COM classes and interfaces do.Anonymous
April 24, 2012
The comment has been removedAnonymous
April 24, 2012
It is my understanding that UUID (universal) was considered presumptuous. It's possible for an alien on another planet to create a UUID that is identical to one created on Earth. So purists would use the term GUID (global) instead as the number is only guaranteed to be globally unique, not universally unique.Anonymous
April 24, 2012
The subtle difference is that GUIDs are made by gnomes while UUIDs ar made by unicorns.Anonymous
April 24, 2012
The comment has been removedAnonymous
April 24, 2012
@Jacob: I'm sure you're correct, but I like my answer better. It wasn't an original construct. I can no longer remember where I heard it.Anonymous
April 24, 2012
I remember an instance where there was a GUID collision with Microsoft products. One of the windows 95 powertoys (Shortcut Target Menu i think) had it's GUID reused in later versions of windows by Show Desktop (or was it Send to Desktop?). I wasn't pleased, it is one of the few powertoys that is still relevant and non-trivial to duplicated.Anonymous
April 24, 2012
I am slightly surprised the bookseller only gets five digits. I guess 99,999 books is a lot, but I kinda assumed there were some publishers out there with more than that, and also more than 999 publishers in the US, over time. Your surprise is due to your unwarranted assumptions; I did not say that (1) the zero code is the only code for the United States, (2) that every publisher has a three-digit identifier, or that (3) every publisher is only allowed to own one publisher code. None of those assumptions are true. English-speaking regions use both zero and one as the region code. Large publishers can purchase one or more three-digit codes; smaller publishers can purchase longer codes that give them fewer digits to choose themselves. And when we run out of those, they'll start using another three-digit prefix; there are hundreds of those still unused. -- EricAnonymous
April 24, 2012
Wait, GUIDs are free!? I may have been taken advantage of on Ebay.Anonymous
April 24, 2012
@Random832: As always, answer to common factal questions can be found on wiki. en.wikipedia.org/.../MAC_address The MAC address namespace is managed by IEEE.Anonymous
April 24, 2012
The comment has been removedAnonymous
April 24, 2012
Looking forward to "ISBN Guide, part two"Anonymous
April 24, 2012
The comment has been removedAnonymous
April 24, 2012
Microsoft runs into duplicate GUIDs because the think the rules do not apply to them and so they may make up GUIDs manually (in some kind of sequence). This makes them more recognizable of course but you get the risk of duplicates.Anonymous
April 24, 2012
The comment has been removedAnonymous
April 25, 2012
Interesting start to the series...Anonymous
April 25, 2012
Very interesting! Waiting for more.....Anonymous
April 25, 2012
I think in next parts, I'm going to get answers to the questions I had since long time.Anonymous
April 25, 2012
See also Waste-A-GUID http://wasteaguid.info/ (The fallacy of this site is left as an exercise to the reader)Anonymous
April 26, 2012
Great post, looking forward to the next one! I just wanted to point out that GUID are not exactly free. It comes with the price of 16 Bytes each, which probably is not something to consider, but sometimes makes a difference. Using ints for key for example will be much more memory efficient (but has other big disadvantages). Best Regards!Anonymous
April 26, 2012
Of course, the real difference with GUIDs even with the MAC address requirement is, it's easy to buy a MAC address, which you can then use to generate billions of billions of GUIDs without having to further answer to anyone. In principle, something like an ISBN could be made to work the same way, and that it doesn't is an artifact of how the publishing industry works.Anonymous
April 26, 2012
Maybe you could also mention why still today so many of the GUIDs in the registry ends with -444553540000 (eg. {25E609E4-B259-11CF-BFC7-444553540000}). Have patience; this is only part one! -- EricAnonymous
April 26, 2012
You also forgot to mention thatGuid.NewGuidis the finest cryptographic random number generator available in .net :PAnonymous
April 26, 2012
If you want a random record from an SQL Server table, you need to use TOP 1 and ORDER BY NEWID(). (RAND returns the same value for each record in the select.) Does this mean I generate and waste thousands of GUIDs every time? There's only a finite number of them available.Anonymous
April 27, 2012
The comment has been removedAnonymous
April 27, 2012
The comment has been removedAnonymous
April 27, 2012
The comment has been removedAnonymous
April 29, 2012
I had a colleague who was concerned about GUID collisions, which prompted me to write this explanation: ralphbecket.blogspot.com.au/.../birthday-paradox-and-guid-collisions.html The punchline is that you can assign about a million billion GUIDs before you hit a one in a billion chance of a collision.Anonymous
May 01, 2012
What about the CDDB (http://freedb.freedb.org). I think they have also thought that the indentifier of a Music CD should be unique. But I found also collisions there! But anyway, good article!Anonymous
May 02, 2012
I'm very worried that at the rate we are using them we will run out of GUID's and everything after that will have to be non-unique ;-) :-DAnonymous
May 02, 2012
So GUIDs are created by gnomes are they? Well that will explain all those tiny footprints around our database server.Anonymous
May 11, 2012
(*) The attentive reader will note that there are usually two bar codes on a book in the United States. The first one is the ISBN; the second bar code is the number 5 followed by a four digit number that is the publisher's suggested price of the book in American pennies.
In another incarnation back when I was in univeristy, I worked at the university's bookstore and I remember there being two pricing schemes publishers used. One was "list price" where there would a suggested retail price for the book and a set discount passed to the store which was often upwards of 40%. With this pricing, the second barcode would indeed reflect the suggested retail price. The second pricing was "net" pricing, which did not carry a suggested retail price at all. These tended to either be all zeroes or have a number beginning with "9" and seeming random information. Having just read this post prompted me to finally look this up and I see that prefix indicates "internal use". Nice to have that mystery solved :-) For what it's worth, the "net" priced books tended to be "textbooks" whereas list priced books typically fell under the "trade book" category, which while sometimes required reading for courses were of the type to also be in general circulation.