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

submitted by rimsystemsrimsystems(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: |Views: 20

tags: another

new 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:
Comments:

posted by rimsystemsrimsystems(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.

Reply

posted by cdjacocdjaco(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.

Reply

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

Sweet Jesus not this again.

Reply

posted by MalkirMalkir(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?

Reply

posted by rimsystemsrimsystems(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.

Reply

posted by gt1329agt1329a(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.

Reply

posted by navdeepbhardwajnavdeepbhardwaj(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.

Reply

posted by aquinasaquinas(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".

Reply

posted by bladefistbladefist(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.

Reply

posted by rickglosrickglos(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.

Reply

posted by bladefistbladefist(471) 4 years, 6 months ago 0

yea bury would be amazing.

Reply

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

Agreed.

Reply

posted by crpietschmanncrpietschmann(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.

Reply

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

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

Reply

posted by crpietschmanncrpietschmann(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.

Reply

posted by foobarfoobar(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.

Reply

posted by macinnesmmacinnesm(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".

Reply

posted by offwhiteoffwhite(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.

Reply

posted by stimpy77stimpy77(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.

Reply

posted by stimpy77stimpy77(1271) 4 years, 6 months ago 0

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

Reply

information Login or create an account to comment on this story