You are reading a MIX Online Opinion. In which we speak our minds. Karsten Januszewski Meet Karsten Arrow



Be Unique But Don’t Be A GUID

Jun 15, 2011 In Development By Karsten Januszewski

Guids. As in globally unique identifiers. Love 'em. And hate 'em.

I mean , you gotta admit, they're kinda cool. Like fingerprints. Or snowflakes. But unlike snowflakes or fingerprints created through the magic of nature, the GUID can be created by me, the software developer! I have the power!

In fact, who wants to play GUID lotto? Here's how it works. I'll generate two GUIDs. If they match, you win! Note: odds of winning are 1 in 2128!

GUID Lotto


Hours of fun await you.

The problem is, GUIDs are so easy to generate that people -- or I should say, software developers -- tend to fall back on them as a default solution whenever one needs a unique key. Have a row in a database? It must need a GUID!

I'm not sure when this proliferation of GUIDs started. Perhaps we can blame COM. (There's a lot we can blame COM on. Quick: what's the GUID for IUnknown?) Or perhaps it is the GUID generator in Visual Studio:

The crux of my problem with GUIDs isn't technical; it's aesthetic. They're just so darn ugly. And they make really unsightly URLs. I don't want to look at them. Yours. Mine. Anyone's. Keep those GUIDs away from me!

So, I urge all of you software developers—including Microsoft employees who tend to use GUIDs egregiously—to think twice before you start using GUIDs. There are many other options to generate a unique key that isn't globally unique. And if you've got a case where you must use GUIDs, please keep them hidden from the user. I don't want to see your GUID, por favor.

Follow the Conversation

30 comments so far. You should leave one, too.

Offbeatmammal said on Jun 15, 2011

given how easy it is for tinyurl, or even to provide short but unique URLs - both readable and random strings - there's probably no excuse for using a GUID in a URL that you expect humans to share (in IM, email, twitter etc)... yet it seems to take a lot of effort to get people to go that small extra step to make the web more usable..

Waste said on Jun 16, 2011

What a waste of an article

Jamie said on Jun 16, 2011

The reason for long, ugly IDs is to prevent easily guessing them. You could easily pull TinyURLs that are valid by typing in random codes.

If your only need for a unique ID is for some internal purpose, then sure, there's no reason to use a GUID. That's what auto-incrementing fields are for. Why use anything other than a sequential number, if there is no security concern?

But if you don't want, say, someone to be able to steal one of your user's sessions by guessing their session ID, then a big, long ugly ID is the correct approach.

Thom Carver said on Jun 16, 2011

I totally agree about how unsightly they are - but they're so darn useful. In what other way can you let a client generate a unique identifier without the assistance of a central server? Could Git/Hg have been implemented without this capability?

Is an acceptable trade-off to make Guids optional - e.g. identify everything with Guids behind the scenes, but have an alternative human-friendly identifier which you switch to after contacting the server?

Greig Stewart said on Jun 16, 2011

Odds of winning are 1 in 2128?? Is that a joke?

Greig Stewart said on Jun 16, 2011

Ah, 2^128. I see it now. Oops :p

Steve said on Jun 16, 2011

One other very important problem with GUIDs is that they don't index very well in databases. Its slow as mollasses to search off of.

Duncan said on Jun 16, 2011

I won!

Just kidding.

Christian Sciberras said on Jun 16, 2011

So let me see if I understand the argument here, don';t use GUIDs because you use them badly?

Heck, no one should use C/C++; it's unsightly and your more prone to err than get it right.

Does it mean everyone should stop using it??

Mike said on Jun 16, 2011

GUIDs are very useful. Barcodes on products are not pretty either.

@steve there is the NewSequentialGUID available since SQL2005 which improves speed of insertion by reducing page splits, and improves speed of searching.

Mazam said on Jun 16, 2011

GUIDs don't index well in database and in SQL Server they can make poor performance as primary keys because of an ordered clustered index over primary key. Non-sequential GUIDs are hard to sort.

Tom said on Jun 16, 2011

Guids are awesome for Client side hierarchy. for DB have you ever heard of GuidComb?

JoC said on Jun 16, 2011

There is a saved game editor for the game Titan Quest.

It's GUID matches a MS product.

I'm not sure if it was a lottery "win" or some kind of malice against MS.

Daniel Van Der Werken said on Jun 16, 2011

I clicked the "Play GUID Lotto" (2^128-1) times. Darn I missed!

Geoff said on Jun 16, 2011

A programmer complaining about data that is ugly makes about as much sense as a gynecologist complaining about the smell.

Jeffy said on Jun 16, 2011

It is 1 in 2128 factorial

bystander said on Jun 16, 2011

Holy @@@@ you actually won! Go buy a lottery ticket immediately!

MauricioGracia said on Jun 16, 2011

For the LOTTO, it would have been more interesting if you had a SINGLE pregenerated GUID, and then each visitor will create a new GUID and compare it to the one that you have (in this way each visitor to this page..will contribuite to the LOTTO)

austin said on Jun 16, 2011

@Jamie: autoincrement is fine for making ids but there are times when it is inappropriate.
for instance we have a software out there right now which uses auto-increment on its fields but we allow them to use sql server or access (so they can work offline or take their data with them) then we get this horrible occasion where they took their data with them, did some work on it, made some new records, and while they were doing this other people were making records on the old data. the two databases no longer jive. record 15 for instance is different between those two versions, and when we need to merge the two databases together its a horrible pain.

the new software uses GUIDs and not autoincrement. so the two databases can diverge and all we have to do is rectify the fields that have changed but not the change the indexes of every single record and the fields pointing to those records and fix the ordering just to do a merge.

frits said on Jun 16, 2011


e62533f4-bbe3-4fc3-bf7c-47004451ca39d514f507-2b1b-45ff-beec-99e48669b7f0Holy @@@@ you actually won! Go buy a lottery ticket immediately! Again.

BillV said on Jun 16, 2011

Stop using sub-directories too.

Paul Kelly said on Jun 17, 2011

I think the point of this post (that some commenters might have missed) is that the key word in GUID is "global". If I generate a GUID here, and someone else generates one in Korea, they are guaranteed to be unique (or at least the possibility they won't be can be shown mathematically to be vanishingly small). And sometimes you need that uniqueness - for COM you needed it to make sure your COM classes could be installed on *any* windows machine and not clash with classes from some other vendor (who might be in Korea, or two doors down the road from you).
The argument about URLs etc is irrelevant here. A URL can be very small because it already has a globally unique id, "", at the beginning. This is guaranteed unique by the internet's domain registration system, so a url only has to be unique to that site - and knows all the urls it's already given out so it can pick a very small one each time. Effectively it's doing the same kind of thing as an autoincrement field in a database table but in a more human friendly form.

So only use a GUID if you know it has to be globally unique.

Peter said on Jun 17, 2011

Good article. I use GUIDs a lot. They're good. For creating new records when the data abstraction layer doesn't return integer identitys for newly created records. For example. But child rows only need the integer identity (which I ALSO use) - it is faster and simpler.

The point of the article as I read it... don't EXPOSE the GUIDs to end users if you don't have to (and I can't see why you ever would).

And no... it's not the right choice for keeping secrets. The right choice for security is a digitally signed identity (of whatever kind). Using a GUID makes you FEEL secure when you are not - which is worse than being insecure and knowing that you are....

That was my two cents, anyway...

VoteNeitherVoteNader said on Jun 18, 2011

I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won ! I won !

Lol, actually, a GUID is not anymore guaranteed to be unique. It's just a random number ranging from 0 to 2^128 -1, plus the probability sums up with every GUID you created.

Manjeet Dahiya said on Jun 19, 2011

Completely agree! GUIDs are ugly but useful.

Peter Hillerström said on Jun 24, 2011

In addition to GUIDs (aka UUID v1 or v4) being fugly, their problem is that many programmers generally do not have a slightest idea of how they are made, and that there are different varieties of them.

GUID v1 algorithm appends the machine’s network MAC address (for example 00:12:34:56:ab:cf = 6 bytes, 48 bits) to the time since the adoption of the Gregorian calendar —— whatever that means, as only four countries adopted the calendar in 1582, and others gradually followed within the next 347 years with over dozen different dates combined with variable style of the skipping of about 10-14 days’ correction of the Vernal Equinox (used to calculate the time of easter) around Mar 21 and thus the difference to the previously used Julian Calendar. The gradual adoption in Europe means that between 10 to 13 dates are invalid in the Gregorian calendar in various countries somewhere between years Oct 1852 and Feb 1923. In Sweden and Finland, Wed 17 February 1753 was followed by Thu 1 March. This epoch is probably 1601-01-01T00:00:00Z that is the epoch of Windows’ GetSystemTimeAsFileTime() call.

This, combined with the facts that UUID version takes four bits and that Windows operating system by default only gives time in 15.625 ms resolution (accuracy) and not in microseconds resolution as the Unix like systems, means that a Windows machine can't generate *UNIQUE* GUID’s faster than once every 1/64 th of a second without some even more fugly and unreliable kludge.

So, UUID v1 has a "space" of 2^76 (minus the current time!) of more or less variable timestamp information accurate to 1/64 th of a second. And in addition the 48 bits of the MAC address, which is usually fixed per machine – but can be also changed to whatever you like! Doesn't sound very reliable to me. What do you think? At least, PLEASE do not use GUID or UUIDs to anything even remotely related to security.

UUID v2 (DCE security) has even smaller space, as it replaces 5 bytes of the timestamp with user or group id. UUID v3 uses an MD5 hash and v5 a 160 bit SHA-1 hash TRUNCATED to 128 bits.

That leaves UUID v4, that is the most random (while still relying to pseudo random number generator with a possibly a very short cycle and predictable sequence) with 120 bits of pseudo random number, 4 bits indicating that it is UUID v4 and anpther 4 bits indicating the subtype (or something?).

I feel that generally GUIDs are the most unelegantly engineered software standards I know of — just after the calendars in use... ;-)

But the idea of picking a "star" at random in the universe of 2^128 stars *is* intriguing.

Paul said on Jul 3, 2011

my answer in the link below:{28388768-3ded-4512-a006-12f6cce03de6}/{937ca151-da9c-47fe-8737-9cb95ed9a37a}/empty.htm

Copro said on Mar 15, 2012

GUIDs are GOOD. I make the GUID with partial auto-increment suffix to be make the database happy in the index.

Coach Purses said on May 12, 2012

That is definately one of the best blogs I've sen in ages online. Maintain up the excellent posts.

Pandora Jewelry said on May 21, 2012

Extremely regularly I go to this website. It very a great deal is pleasant to me. Thanks the author!