The Gospel of the GUID - And Why It Matters!

The Gospel of the GUID

There is only one commandment in the Gospel of the GUID:

I. Thou shalt always use a GUID to uniquely identify a row in a table.

Whenever I hire a new member for my team, this is one of the first rules that I teach them. At first, they almost always look at me like a puppy with their ears up and their head tilted to the side as if to say "huh?"


So I show them that every single table has field that is a unique identifier, and most of the time, that field is the primary key and usually the clustered index at that. For example, if we have an Employee table, it has a field named EmployeeGUID that is a unique identifier, and it is the primary clustered key. It's at this point that I usually start get the "uh oh, my boss is an idiot but I don't want him to know I think that look." Next the questions and the "but I do x" comments start to come:

  1. I just use an int.
  2. I don't do that because they are so big.
  3. Don't you know how hard it is to go look up something by that, an int is so much easier.
  4. Surely you don't do that for many-to-many bridge table?
  5. What happens if they run out of GUIDs?
  6. I don't think I trust that they won't be duplicated.
  7. I have never heard of this, therefore it is probably a bad idea.
  8. Don't you think there is a performance penalty for doing that?

So then begins my quest to make them a convert. I have a high conversion rate among "thinking" people, and therefore I challenge you to read this and see if you too will become a believer!

Reason 1: I can make less trips to the database, now THAT is a performance enhancement!

There are many reasons to use a GUID as the primary key for your table. My primary reason is directly related to how I build my object models. I prefer to create a "new" instance of my object without round tripping the database. So if I am going to create a new Order object, I don't have to round trip the database to get the OrderID (OrderGUID in my world) like I would if I was using an int as the "ID" of the order. While not all that impressive at this level, consider this. I can create a new Order object with an OrderGUID, and ten OrderLineItem objects with their own OrderLineItemGUID without EVER round tripping the database unlike the INT solution which needs to make 11 calls to the DB.

Reason 2: Data Merging is so easy, Mac using developers can do it!

My second reason for always using a GUID is data merging. I can't count how many times that I have had to merge data. Back before I saw the light, I too would use INTs or some other thing to make my row unique but when I had to merge data, I always had to write a conversion.

Consider the following:

Customer Database 1:
Order Table

Customer Database 2:
Order Table

OrderID: 1

OrderID: 1

CustomerID: 1

CustomerID: 1

If customer 1 acquires customer 2 and I need to merge their data, I have to convert someone's OrderID 1 and CustomerID 1 to some INT that is not used, and update a lot of rows of data, and possibly monkey around with seed values. Multiply that out by dozens of tables, millions of rows of data, and I have a REALLY big task ahead of me, that will require a lot of testing after I write the SQL and/or code.

However, if I had followed the Gospel of the GUID

Customer Database 1: Order Table

Customer Database 2: Order Table

OrderID: {C290A815-BAAA-4455-82EA-F18F5D0CEF2E}

OrderID: {79E9F560-FD70-4807-BEED-50A87AA911B1}

CustomerID: {52335ABA-2D8B-4892-A8B7-86B817AAC607}

CustomerID: {60FA3045-BAE8-4526-87A2-DF22ED5F093B}


Now all I have to do is insert all the rows from one customer's db into the other's db. No conversion, no testing of the conversion necessary, just nice clean and efficient.  I recently needed to merge two of my client's data in just such a manner: AT&T and Cingular.  My "conversion" took all of 45 minutes.

Another similar example: imagine if you had a need for people to work disconnected and you need to merge in their changes once they get back online. Now it is child's play... if you are a believer in the Gospel of the GUID. You can easily push changes made in either DB to the other.

Reason 3: Type/Table Ignorance

The third reason I believe in the Gospel of the GUID is what I call "Type Ignorance" which is a play on "Type Inference" in .NET 3.5 as it is kind of the opposite meaning: I don't care what the type is at the row level in my table. Let's assume that I have an application that has been in production for a while. It has the following tables (among others) Customer, Order, OrderLineItem, Product, and finally Vendor. Now I determine that I want to be able to add "notes" to all of these items. I can simply create a new table and object that looks like:




Unique Identifier


Unique Identifier




I can insert all my notes into a single table, using the GUID of the parent object in the ParentGUID field. If I want to get to any object's notes all I need is a simple join. For example, to get to a Vendor's notes, all I need is a simple join of Note.ParentGUID to Vendor.VendorGUID. I don't need a "type" indicator so I know which table to join, nor do I need a myriad of join tables to know which note goes with which type.

You would be surprised how often this little technique comes in handy. We recently added "auditing" to our application where we needed to know exactly who added, updated, and deleted what. We simply added a handful of lines of code to the SubmitChanges() method of the datacontext (We use LINQ exclusively in  our new app)  and write out the appropriate record to our audit table. Any time we add a new object type/table to our app, it will automatically get the auditing ability without us having to change a single line of code, or make any modifications to our "auditing table."


Reason 4: The hits just keep on coming!

There are many less than obvious reasons for using GUIDs to identify things, but here is one that I did not plan for and was incredibly grateful for and ultimately it saved my client millions of dollars... yes I did say MILLIONS!

I was developing an AP Feed ability for a large client. They were going to be able to pay millions of dollars of their bills at the push of a button. Basically, push a button in our system, we would generate a feed file, ship it to their AP system, and it would generate the checks... and out the money would go. Of course, I used GUIDs to identify every single thing. So when the AP system generated a reconciliation file, I could easily match it up to my end.

At our site, this client had a production database and a test system which was a copy of their production system, just somewhat stale. A couple of months stale to be exact. During our testing, someone on their end saw one of our test feed files and mistakenly assumed that it was a production feed which should be "paid" so they dropped it over into their production AP system. You guessed it... they just paid a lot of legit vendors twice (once from the production system, and once from the test system) and some not so legit vendors got checks they shouldn't have because they were no longer the landlord (remember, the test db was a couple of months stale.)  Through no fault of my own, I now had a horrible mess of data... or at least my client thought so. However, since all of my payment records had GUIDs for identifiers, I could easily join the two db's against AP System which had my GUID for each payment, to determine which payments were legit and therefore should be paid, and which should get a good ol "stop payment."  Imagine if I had used INTs. I would have no way of knowing if PaymentID 1000 was from the good data or the test data.

So how did this save my client millions? Easy... thousands of payments multiplied by "stop payment" fees adds up in a hurry. Especially when they make this horrible mistake 3 times! J


So are there any downsides to the Gospel of the GUID?

In short, yes there are, however, they are so miniscule that they don't even come close to changing my mind. The most "in your face" downside is when you have to hand write SQL to find something.


is a lot easier than typing

SELECT * FROM ORDER WHERE ORDERGUID = ‘{45F57B42-38A4-46ce-A180-6DE0E7051178}'

A second downside is that there is a small performance hit for joins that are based on GUIDs if measured against the same data using INTs instead. In my experience, even when using multimillion row tables, this has NEVER been an issue. A few milliseconds are such a minor price to pay for all of the goodness.

I encourage you to try out this technique in your next small project, especially if you are still a skeptic. I think you will find it more useful than you ever dreamed.

Published Sunday, November 4, 2007 10:35 PM by wwright


Monday, November 5, 2007 12:05 AM by John S.

# re: The Gospel of the GUID - And Why It Matters!

What about the segment sql server paging issues (aka the reason NewSequentialId() exits)?

Monday, November 5, 2007 7:04 AM by Guy

# re: The Gospel of the GUID - And Why It Matters!

im officially converted after reading reasons 3 and 4!!!!!!

Monday, November 5, 2007 9:43 AM by Ian

# re: The Gospel of the GUID - And Why It Matters!

I'm not sure I'm a full convert, but you've definitely made some strong points, particularly related to the merging of the two customer tables...I've been there and that's a nightmare with ints.

Monday, November 5, 2007 11:51 AM by Justin

# re: The Gospel of the GUID - And Why It Matters!

Concerning the downsides...

What about the performance hit you take with clustered indexes constantly being resorted on inserts and deletes?

Monday, November 5, 2007 12:06 PM by Dave

# re: The Gospel of the GUID - And Why It Matters!

Can't say you convinced me - I'll take a number for the primary key any day if I have a choice. I dealt with a db that used guids instead of numbers for Primary keys. It did this for a "valid" reason as it periodically was aggregating data from different SQL installations. Dealing with those Damn GUIDS everyday really starts to simply suck for the exact example you gave - SELECT * FROM ORDER WHERE ORDERGUID = ‘{45F57B42-38A4-46ce-A180-6DE0E7051178}'

Monday, November 5, 2007 12:18 PM by Chris

# re: The Gospel of the GUID - And Why It Matters!

Hi, I don't really explain Reason number 1...can you explain it in a little more detail?

Monday, November 5, 2007 1:11 PM by Anonymous

# re: The Gospel of the GUID - And Why It Matters!

DW Specific:

If an int (4-bytes) or bigint (8-bytes) is more than enough for any warehouse table, why would I want to use a datatype that requires 2 or 4 times the storage space? The space increase can be significant if you have billions of rows.

I guess ignoring efficiency is why we need the latest hardware to run Windows Vista and other bloated, poorly coded applications at an acceptable performance level.

Monday, November 5, 2007 1:29 PM by Rob

# re: The Gospel of the GUID - And Why It Matters!

At the end of the day the important thing is that it works for you and your team.

I think you will however have a very hard time convincing the 'skeptic' masses to stray from best practices and adopt this approach.

I used to live in your world with a GUID colored sky but now treat the GUID everywhere approach as an anti-pattern.

After supporting a few GUIDbeasts in production I have come to learn that judicious use of GUIDs are absolutely beneficial in scenarios where cross-database uniqueness is a requirement but the GUID everywhere approach just becomes a painful mess for the people that live within the system.

Anyway, it is not worth debating the merits here as the kool-aid has been consumed but I might just offer you 1 piece of advice.  Please cover this approach in the interview with your new people before you hire them...that at least gives them the chance to run screaming from the room BEFORE they actually quit their current job!

Monday, November 5, 2007 4:28 PM by jwasp

# re: The Gospel of the GUID - And Why It Matters!

I hardly think that 'typing' should be considered a downside ... hopefully, at this level, we're not manually typing queries like that. I agree largely with what you're saying here as I've started using GUID's more. Another potential downside ... using stored proc's and returning identity values from them. At least in SQL Server 2005 ... IIRC, you cannot return a GUID (uniqueidentifier) from a stored proc ... only int's. I'd love to hear that I'm wrong on that though!

Monday, November 5, 2007 4:56 PM by Peter Murray

# re: The Gospel of the GUID - And Why It Matters!

Yes, but you didn't answer two of your own questions:  <blockquote>5. What happens if they run out of GUIDs?

6. I don't think I trust that they won't be duplicated.</blockquote>

The answer to the first is somewhat obvious, but what about the second?

Monday, November 5, 2007 4:58 PM by Patrick Cox

# re: The Gospel of the GUID - And Why It Matters!

On Item #3, what about referential integrity?  You could end up with a bunch of stray notes with no parent records existing...  I don't believe a foreign key constraint could be created since the foreign key relates to more than one table.

Monday, November 5, 2007 7:28 PM by EtienneT

# re: The Gospel of the GUID - And Why It Matters!

I completely agree.  Our company use this a lot right now.  Libraries like SubSonic make things lot easier when working with this.  Type/Table Ignorance is really easy to do with subsonic and GUID.  We used this to make a table of permissions.  For example this user has access to this object, or this role can access this object etc.

What would you think of a GroupMap table?  ParentGUID, ChildGUID kind of relationship.  Encapsulating many to many relationships and handling the type binding in code with generics?

Monday, November 5, 2007 9:07 PM by JB

# re: The Gospel of the GUID - And Why It Matters!

Reason 1 is very weak.  This can be accomplished by using an SP with a output parameter.

Monday, November 5, 2007 9:28 PM by Scott

# re: The Gospel of the GUID - And Why It Matters!

never...ever...ever...use a (non SQL2005 sequential) GUID as the clustered index key.  Fragmentation goes through the roof at just slightly slower than the speed at which your queriy performance will go through the floor

Monday, November 5, 2007 9:53 PM by Paul Kohler

# re: The Gospel of the GUID - And Why It Matters!

Nice one. I regularly have similar issues with those types of questions but this article is a good list of the "whys". In weighing up the pros and cons I also found "its more to type for an ad-hock query" not enough reason to not use a GUID! The merging of data is a very big plus...

Monday, November 5, 2007 10:45 PM by Vk

# re: The Gospel of the GUID - And Why It Matters!

For Reason 3: What happens when I want to know to which Parent this note belongs to?

Tuesday, November 6, 2007 3:18 AM by dani

# re: The Gospel of the GUID - And Why It Matters!

I basically agree, but I believe COMBs are even better solution that GUIDs because they also allow you to sort data and actually distinguish GUID values in a logical manner.

Basically, you construct a GUID so that first part is a timestamp representation of GETDATE and the rest is a generated GUID, thus allowing sorting, date filtering and such.

A rutine in SQL would look like this:


Similar can be done in managed code, JS code etc. to avoid round trips.

Tuesday, November 6, 2007 4:13 AM by Marcus

# re: The Gospel of the GUID - And Why It Matters!

I'm afraid I can't agree with you on this post and I would even go as far as to say that it sets a bad example to readers. You are making a case for GUIDs based on solution edge cases where GUIDs *may* provider a better option. When generalising, GUIDs do not provide an overall better solution or performance.

Your reasons:

Reason 1: Only holds if your write volume is very high compared with read. Otherwise this is a false economy. Most apps do a minimum of 10 times more reading than writing. Our biggest app does 1000 times more reading than writing.

Reason 2: I really wouldn't be designing my system so that I could cope with future customer mergers. How often does that happen? ie. what percentage of customers are going to merge? I bet you'd be lucky to find one.

Reason 3: I'm not sure a DBA would agree with you here... What about referential integrity constraints which help the optmizer in combination with statistics decide SELECT strategies?

Reason 4: This is very specific to a particular solution.


Tuesday, November 6, 2007 4:17 AM by Rich

# re: The Gospel of the GUID - And Why It Matters!

1. I've never had to make extra database calls because of this. Manipulate your new object without an ID and then save it. It's only when needing to identify it in the future that you'll need to query it back anyway and you'll get the ID no extra cost than a GUID then.

2. This appears to be the same reason as (4). I think it's valid, but not necessarily a likely scenario for many. Interesting though.

3. You could do this with ints too.

I don't think I could ever use this though in a large scale, mission critical, application purely because of the, albeit minimal, risk of collisions. Actually unique IDs are a must if you're dealing with financial transaction IDs.

Tuesday, November 6, 2007 4:32 AM by Roland

# re: The Gospel of the GUID - And Why It Matters!

Excuse me, while I agree with most of your statements here, isn't it a bad idea to put a *clustered* index on GUID columns?

I've always understood that clustered indexes are used for columns that have some kind of ordering properties, such as integer or date values. While GUIDs are completely random this will actually degrade performance to a certain level.

Your thoughts please.

Tuesday, November 6, 2007 5:03 AM by Julen Parra

# re: The Gospel of the GUID - And Why It Matters!

Interesting design idea. You say that you are saved trips to the database. Does that mean that you prefer to assign GUIDs at the application level, rather than using the GUID datatype (where available) or insert triggers? I'm never used GUIDs in my database designs, but certainly the concept seems to have merit. I can certainly think about several times when it'd have come handy. I'm curious about what your opinion is about using GUID datatypes, triggers, or application level functions.

Tuesday, November 6, 2007 8:12 AM by Justin Etheredge

# re: The Gospel of the GUID - And Why It Matters!

Agreed, if at all possible, GUIDs trump integer primary keys any day of the week. The only time I would disagree is if the table has a natural primary key, such as a social security number.

Tuesday, November 6, 2007 10:18 AM by Corey Trager

# re: The Gospel of the GUID - And Why It Matters!

This guy at work was telling me about your idea and I said to him that it was stupid.  He just kept saying, read the article.  So I read it and your are very convincing.

I'm dealing with your "Reason #2" right now.

Tuesday, November 6, 2007 12:14 PM by Brennan Stehling

# re: The Gospel of the GUID - And Why It Matters!

Why not use the GUID and an INT set as the identity column with an auto-incrementing value? That way you can still do "SELECT * FROM TABLE1 WHERE ID = 25" and still benefit from the GUID being a uniquely indexed value on the table. I have considered this approach. I once enabled synchronization across databases and doing so added a GUID column to the tables to assist with the data transfer process. Either the GUID or the INT could be the primary key while the other is simply a unique index. In addition to the GUID I also like placing a Created and Modified DATETIME field in each table, and potentially an IsDeleted BIT column for soft deletes. Those extra details can be helpful in scenarios similar to the ones you described.

I do like your point about being able to create fresh objects without hitting the database. But for the rest, I have rarely needed to sync databases. And if I ever do I think I will simply add a GUID column with the unique values generated as if they were there the entire time. Then the data migration and go smoothly.

Tuesday, November 6, 2007 12:30 PM by Rick Glos

# re: The Gospel of the GUID - And Why It Matters!

Just be sure to use the right tool for the job.  In many cases this would work.  In large enterprises that do Data Warehousing, use of GUIDs for IDs would not be acceptable.  It's not always black and white.

Tuesday, November 6, 2007 12:57 PM by tony

# re: The Gospel of the GUID - And Why It Matters!

Pardon my GUID ignorance here.

First, I have to say your arguments are the best i've read yet on the GUID/INT IDENTITY debate, and have seriously made me reconsider my stance.

Your first reason brings up a question i have.  Based on what I understand from Reason #1, are you saying that in you .NET code, you create your GUID through .NET code and then save it back to the database, hence no round trips?  If that is the case, my question is what happens if someone calls the save sproc from T-SQL and uses T-SQL to gen a new GUID?  Would there every be a chance of duplicate GUIDS? or is the chance so small that its not even worth worrying about?

Tuesday, November 6, 2007 4:54 PM by Josh Anderson

# re: The Gospel of the GUID - And Why It Matters!


Unless I misunderstand the application, there are easy ways to get around the return value.  If you're talking about a GUID equivalent to @@Identity, it's not necessary -- you can generate the GUID anywhere in your app.  The beauty is that you know it'll be unique.  The insert statements don't have to return a value because you're supplying the GUID to the sproc, not the other way around.

I switched to GUIDs in a recent app, and I don't think I'll ever go back to integer IDs.  There's so much flexibility in GUIDs.


Tuesday, November 6, 2007 4:58 PM by Chris Pietschmann

# re: The Gospel of the GUID - And Why It Matters!

INT has a maximum value. But, you'll never run out of GUIDs.

Tuesday, November 6, 2007 5:33 PM by billbass

# re: The Gospel of the GUID - And Why It Matters!

I used to agree with you on this one and started using GUIDS everywhere as primary keys. Then  I found the downside.

GUIDs are a lot bigger than integers.

Tuesday, November 6, 2007 11:45 PM by Muhammad Haroon

# re: The Gospel of the GUID - And Why It Matters!

I love GUIDs for exactly the same reasons as you mentioned.  I have successfully used these on large-scale projects, but the concurrent user base for such projects was rather small (relatively).  My current project has a very high dependance on the database and my DBA won't let me use GUIDs.  His explanation is that it takes longer to read a GUID than an int, and when you multiply that by millions of reads our database goes through each day, we loose a lot of performance.  Any thoughts?

Wednesday, November 7, 2007 2:07 AM by kiwwi

# re: The Gospel of the GUID - And Why It Matters!

especially for reason 1 and 3 -

i use uuids for all my tables and python as scripting language. It has been sooo much easier to do things done.

Wednesday, November 7, 2007 4:25 AM by Matt Thrower

# re: The Gospel of the GUID - And Why It Matters!

Interesting article. I'd say that typing out a GUID instead of an int in your select queries isn't quite so insignificant as you make out but you're trying to construct a persuasive argument, so we'll pass that over.

I have a question - probably because I'm not a "Thinking" person - I don't understand your first point. How does a GUI save you trips to the database? Fancy giving a more long winded explanation in the interest of gaining converts?

Wednesday, November 7, 2007 6:53 AM by ParanoidPenguin

# re: The Gospel of the GUID - And Why It Matters!

I think it might not be ideal to use a GUID for a clustered index since they do not naturally increment, and therefore inserts will not be at the end. Might be better off having a different index as clustered if you want it and leaving the GUID PK unclustered.

Wednesday, November 7, 2007 10:45 AM by Brennan Stehling

# re: The Gospel of the GUID - And Why It Matters!

I took my time leaving a comment yesterday but it seems it is not here. Was it deleted?

Wednesday, November 7, 2007 1:30 PM by Jon Davis

# re: The Gospel of the GUID - And Why It Matters!

The question of whether a GUID is suitable as a primary key is primarily a question of performance, not ideology. Obviously from a developer perspective a GUID is handy. However, it is also randomly generated and therefore NOT guaranteed to be unique.

The performance considerations are not trivial. By default, SQL Server's table designer configures the primary key of any type with clustered indexing. This works great with integers because each new primary key can just append itself to the "stack" on cluster. But with a GUID, since the values are not consecutive (they are random), the cluster is partitioned off. You end up with a fragmented table. With each new record you have the potential of having an isolated fragment!! This means fragmentation hell. It's almost as if you aren't indexing your table at all.

So, using a GUID is fine for a developer's "primary key", but it's unacceptable for a table's primary key, unless you're careful to configure how it is indexed.

I'm really very surprised neither the blog post author nor other commenters brought this up.


Wednesday, November 7, 2007 9:43 PM by Jay Levitt

# re: The Gospel of the GUID - And Why It Matters!

I worked on several very large (hundreds-of-servers kind of large) databases, about a decade ago, and we always used a BIGINT primary key; the first longword identified which database it was in, and the second was uniquely assigned by that particular database.

If you're using application-generated GUIDs, how do you map a GUID to the particular database that it's in?  You can't use a table, or you've got a single point of failure.  You can't use a calculation, because when you create the GUID, you have no way to know that the database will still be up.  You can't create the GUID after writing the record, because the GUID has to be stored in the record when you write it.

If you're working on AT&T-sized data sets, you've surely solved this problem - how?

Saturday, November 10, 2007 5:28 PM by wwright

# re: The Gospel of the GUID - And Why It Matters!

I will responding to the MANY MANY questions, comments and insults in a post coming soon. I am sorry for the delay, it has been one of those weeks at work!

Saturday, November 10, 2007 11:38 PM by kev

# re: The Gospel of the GUID - And Why It Matters!

Isn't clustering rows by a random # a bad thing for insert performance?

Sunday, November 11, 2007 11:06 AM by Eric Newton

# re: The Gospel of the GUID - And Why It Matters!

It has been generally recommended in Sql corners to NOT cluster GUIDs... why?  Because they're so random it causes disk io to go whacky every time there's an insert... versus INTs, which increase sequentially (typically), the database engine has a much easier time inserting because it won't have to "make room" for the new room in existing db pages.

The better way to prevent performance problems is to NOT cluster on the GUID, and allow the database engine to simply insert new rows into the end of existing pages.

Just a thought...

Sunday, November 11, 2007 4:12 PM by wwright

# re: The Gospel of the GUID - And Why It Matters!

I have added a response to the numerous emails and comments to this post here.

Wednesday, November 14, 2007 1:35 PM by Brent Brown

# re: The Gospel of the GUID - And Why It Matters!

Preach it brotha'!!

Saturday, February 9, 2008 10:34 AM by Grad student

# re: The Gospel of the GUID - And Why It Matters!

You can always tell someone who never went to University, or never studies SQL, when they hatch stupid ideas like this.

Primary keys are INTs, because you're never supposed to store 2 or more "things" in the same column.

Until you have a decade or two experience under your belt, you're simply not going to understand why...

Wednesday, April 23, 2008 1:30 PM by Michael Khalsa

# re: The Gospel of the GUID - And Why It Matters!

Ints and Guids can work side by side

I use ints for the primary key, but i also include a guid which is not the primary key on sagnificant data.

Then for merges, i look at the guid. Ok it is not instant merge, but it does give a global uniqueness. What happens when merging data with the same ints but different guids is then a business rule decision.

If you have different databases that must merge frequently, and maintain their own integrity then you could use guids as the keys, but there is another way which is using complex primary keys.

Your order id is DbId-OrderId where DbId is a number you assign to a particular database

So order 1-1008, 2-1008 are unique.

This can be added later when the demand is there, a bit of work, yes, but much friendlier. This takes care of your order, invoice, commmunications, shipments, etc uniqueness

As for product uniqueness, i do not think you would actually want to use a guid as the key in this instance. merge replciation in this aspect needs to be difficult, because you want to control where new products are added and keep the same product from appearing twice with two different ids. should guids be added - yes, but as keys - no.

Anything with a web interface is going to look very bad passing around guid values in a query string, plus most apps with a web ui as part of the overall solution is not going to make your clients happy with product id = guid

At the end of the day, it depends on the app, but as gospel, for me i would say no. Perhaps for general motors - yes. Now i just need to find that new carb 234890-sdflskh-023lkhfsd-ss (to the end user that looks just as gibberish as an actual guid)

because that is not so different than the ten + digit product numbers they probaly already use

Friday, April 25, 2008 9:57 PM by wwright

# re: The Gospel of the GUID - And Why It Matters!

@Grad Student - Truly, you have a dizzying intellect.

Friday, March 13, 2009 12:17 AM by hoodaticus

# re: The Gospel of the GUID - And Why It Matters!

"I took my time leaving a comment yesterday but it seems it is not here. Was it deleted?"

Blame it on a GUID collision.

Friday, March 13, 2009 6:25 AM by wwright

# re: The Gospel of the GUID - And Why It Matters!


Sorry friend, but I have not seen a comment from you.

For the record, I don't delete comments. I only approve them. The reason is because I get so many spam attempts in my comments section that I have to.