The Gospel of the GUID - And Why It Matters!

home
database
view story

42 Kicks

The Gospel of the GUID - And Why It Matters!(weblogs.asp.net)

submitted by rimsystems(6119) 4 years, 6 months ago

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: 20
Tweet

tags: GUID Database another

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:

More who kicked this story...

Comments:

posted by rimsystems(6119) 4 years, 6 months ago 0

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

posted by cdjaco(5) 4 years, 6 months ago 0

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

posted by yesthatmcgurk(4063) 4 years, 6 months ago 0

Sweet Jesus not this again.

posted by Malkir(96) 4 years, 6 months ago 0

"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 rimsystems(6119) 4 years, 6 months ago 0

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 gt1329a(7849) 4 years, 6 months ago 0

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 navdeepbhardwaj(25) 4 years, 6 months ago 0

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 aquinas(20) 4 years, 6 months ago 0

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 bladefist(471) 4 years, 6 months ago 0

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

posted by rickglos(0) 4 years, 6 months ago 0

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 bladefist(471) 4 years, 6 months ago 0

yea bury would be amazing.

posted by cdjaco(5) 4 years, 6 months ago 0

Agreed.

posted by crpietschmann(11.3k) 4 years, 6 months ago 0

""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(11.3k) 4 years, 6 months ago 0

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

posted by crpietschmann(11.3k) 4 years, 6 months ago 0

"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 foobar(0) 4 years, 6 months ago 0

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 macinnesm(0) 4 years, 6 months ago 0

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 offwhite(975) 4 years, 6 months ago 0

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 stimpy77(1271) 4 years, 6 months ago 0

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(1271) 4 years, 6 months ago 0

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

Most Active Users

What's this?