Just curious, were these GUIDs in this table combed GUIDs? Also, it sounds like since this was a log table, and not one for entities (that need to be UPDATEd as much as INSERTed), that also has to be a consideration.

When we used combed GUIDs on a particularly large Oracle installtation (~1TB, most in one table), we didn’t run into any problems. Then again, it’s Oracle.

Just last week I had to deal with a table that used guids for the PK, and the table was so burdened that it finally became unresponsive during inserts. The table had approx 120 million records in it (giant log table), but each insert was causing hundreds of disk hits because the clustered index was gigantic. We recreated the table with a new indentity column (int) and left the guid column on there without constraints. The table started behaving correctly again.

Relevant links:
Celko on PKs
http://www.intelligententerprise.com/channels/business_intelligence/showArticle.jhtml?articleID=201806814
Atwood on Celko on PKs
http://www.codinghorror.com/blog/archives/000817.html

The last time I created a database I mixed guids with natural keys. The guids have not caused me any problems. The natural keys have been a headache, as I didn’t plan them correctly (is that EVER possible?).

I think unless I have strict requirements for speed and size I’m going to be sticking with guids from now on.

You are absolutely correct Identities in a multi-server environment or a synchronised off-line environment where users can write to the database off-line are unusable. The possibility of synchronsation and replication should be consdered carefully before thinking about using identities.

Good – I’m not a DBA either!

There’s another reason why I don’t like the identity column also. It’s too easy to put a number in and just get something back. When integrating with other systems that use INT identifiers, I always wind up having to do an extra verification, just to make sure I got back what I meant to ask for.

Yes, there’s definitely a greater chance of collision. It’s a risk. But when using identity columns with increasing numbers, collision is guaranteed (in replication scenarios).

If all of the GUIDs are comb’ed, then the chance of a collision is the chance that two GUIDs are created with the same value _in the same time window_. I’d have to remember back to my stats class to figure out the probability…

That’s why we use the combed GUIDs. We’ve seen similar performance to LONGs in SQL Server (similar, but not equal). IIRC, MS is putting some more effort into the GUID keys to up their performance.

We did try GUIDs in Oracle once. We wound up having to sequence the bytes a little differently to get a similar effect.

In the Oracle installs with TB’s of data, they were doing other things to help with performance, such as creating clusters based on dates, etc. Of course, that was because we made the mistake of letting the business use our OLTP DB as their reporting DB, but that’s another story…

One point worthy of mention. You talk about the “COMB” GUIDs in close proximity to talking about GUIDs being globally unique. A simply mathematical exercise will show that there is MORE chance of the COMB GUIDs being non-unique on the global scale than those generated by other methods. The linked article makes the point of it being difficult to create a million GUIDs in less than 1/300th of a second. However, on a global scale or, in fact, in a large organisation with many hundreds of replicated servers, the overall grid may produce many more GUIDs in this amount of time. This would still give a low chance of collision but not as low as a good GUID algorithm.

It is interesting to note that Microsoft’s preferred algorithm is simply a completely random number (or as random as a computer can be).