The Gospel of the GUID - And Why It Matters!

Why not join our community?, there are 12 users online

home
database
view story

DotNetKick.com is an open-source project. Please report any bugs and let us know your great suggestions. Currently running svn revision 620 (rss)

Kick Spy!, Kick Zeitgeist and Kick Widgets

42
kicks

kick it

The Gospel of the GUID - And Why It Matters!

published 8 months ago, submitted by

rimsystems 8 months, 1 day ago

weblogs.asp.net — There is only one commandment in the Gospel of the GUID: Thou shalt always use a GUID to uniquely identify a row in a table.

20 comments | category:

Database | Views: 2 | Get KickIt image code

tags: GUID, Database | tag it

Everyones tags:

Your tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

rimsystems - dawtips -

GTech33 -

JudahGabriel -

ussherm -

yesthatmcgurk -

EtienneTremblay -

jstangroome - senfo - Reman -

rprouse - poulrh - styx31 - braddunbar -

tiernano - wwb_99 - mghaoui - monty - blisteringlunatic - mmalloy - csharpnjava - BrianRichards - jburger - MHamilton -

powerrush - Golo - jakub.sturc - kwiksand -

justin_etheredge - munchr - zvikara - ashithmr -

bentracy -

crpietschmann - bsimser - jamesstaylor - pmbrown -

reteep - xerratus - NathanBaulch - chaks7 -

CVertex

Comments:

Another story I don't really agree with, but I'd like to see a discussion about it.

posted by

rimsystems 8 months, 1 day ago

Hmmm...*always*? Even for limited-set items such as gender, continent, blood type....? Seems like overkill to me.

posted by

cdjaco 8 months, 1 day ago

Sweet Jesus not this again.

posted by

yesthatmcgurk 8 months, 1 day ago

"I don't think I trust that they won't be duplicated."
I didn't see an answer for this one in the article. Does duplication actually happen?

posted by Malkir 8 months ago

I tried posting a comment about this on the article's site, but I want to know the author's solution to the segmented paging problem (the reason MS introduced NewSequentialID() in SQL2005). That's the big show stopper for me.

posted by

rimsystems 8 months ago

It seems like all of the supporting reasons are variations on horrible screw ups. How about putting this effort into not screwing up in the first place?

At my place of primary employment, the entire company (99% non-technical) is versed in and talks constantly in terms of the integer IDs in our system. I cannot even imagine how quickly I would be slapped down for suggesting we replace those with GUIDs, when management saw what a GUID actually was.

posted by

gt1329a 8 months ago

I think as per the example of synchronization, its good idea to have GUID as Primary Key. But when you have a large data where speed is required, the INT is better option. As generating a GUID and matching (as has been said in article) are both costlier in terms of computation. Also an index on GUID will be bigger making search slightly slow.

posted by navdeepbhardwaj 8 months ago

Regarding making a round trip to the database: what kind of database would one be using that doesn't support identity fields or sequences that you have to make a round trip to the database to get the next id? Please tell me you're not doing a select max(id)+1 from table. Hello race conditions.

"Reason 3: Type/Table Ignorance" Yeah, now you also don't get any foreign key constraints / cascading deletes on your "ParentGUID".

posted by aquinas 8 months ago

how did this get kicked so many times? there are 50 other more informative, better articles on this site w/ 1 kick.

posted by bladefist 8 months ago

Data Warehousing is one area that this 'commandment' would not apply. Take what you read with a grain of salt. This article is not worth that many kicks. It would be nice to have a 'bury' option.

posted by rickglos 8 months ago

yea bury would be amazing.

posted by bladefist 8 months ago

Agreed.

posted by

cdjaco 8 months ago

""I don't think I trust that they won't be duplicated." I didn't see an answer for this one in the article. Does duplication actually happen?"

Um... Realistically, No. The probability of a duplicate GUID being generated does exist, but it's so slim that it's not a problem.

posted by

crpietschmann 7 months, 29 days ago

Integers have a maximum value, but you'll never run out of GUIDs

posted by

crpietschmann 7 months, 29 days ago

"Hmmm...*always*? Even for limited-set items such as gender, continent, blood type....? Seems like overkill to me." - cdjaco

Yeah, I have to agree with that. Take Gender for example; why event use a Gender table? The only values that exist and will ever exist are M and F.

posted by

crpietschmann 7 months, 29 days ago

Guids generated on a machine with a network card will be unique, since they are based on the MAC address of the network card, and those are guaranteed to be unique.

As for the issue with a number identifier and Guids, just have an identity column along with a guid column. What's the problem? And use a bigint instead of int.

posted by foobar 7 months, 29 days ago

I wrote a lengthy reply on his blog the other day explaining why each of his "reasons" were inaccurate. I guess it was "censored".

posted by macinnesm 7 months, 29 days ago

Yeah, I vote to add bury with this blog entry as an example. Some points are OK, but it seems a few of us posted comments on the blog but they were censored out. The best part of blogs is a response to the points that are made so a reader can have some level of confidence that they are getting the full story.

posted by

offwhite 7 months, 29 days ago

GUIDs as primary key default with clustered indexing just like with integers. Since GUIDs are randomly generated, though, (to say nothing of the fact that GUIDs are never guaranteed to be uniqueue) this results in inevitable fragmentation hell. With a lot of records, you end up with a VERY slow table.

I posted this on the blog page's comments but it went into a black hole or was deleted.

posted by stimpy77 7 months, 29 days ago

uniqueue == unique... I'm tired ..

posted by stimpy77 7 months, 29 days ago