We have a system that uses UniqueIdentifier as the primary key of each of the tables. It has been brought to our attention that this is a bad idea. I have seen similar post
Personally, I'd use an int or bigint for the PK, but just put in another "Guid" column for those situations where you need an unguessable "key" for that record, and generate the Guid when you insert the row.
There are pros and cons:
This article covers everything.
GUID Pros
GUID Cons
It will be bad if you will need to do joins over large sets (let's say 100,000ths). Been there, suffered that.
Later Edit : I also encountered an even worse screw-up (can't call it "approach") : storing GUIDs in char(36) columns!!
A GUID is a powerful datatype for identifying a row, since it is almost guarenteed to be unique, this allows a lot of flexibiliy for example you can generate the Guid in the application tier which can greatly simplify saving your relationships.
As was said the big downside is the page splits which will occur if your PK is a clustered index; however, you can solve this by two ways. You could use the NewSequentialId() or you can set the PK to be non-clustered. I'd recommend you build your database based on your data requirements, and if you need a GUID use it, and then optimize around it. And validate its performance in your environment.
I wrote a post about this last week with some code to show you what happens: Some Simple Code To Show The Difference Between Newid And Newsequentialid
Basically if you use newid() instead of Newsequentialid() you get horrible page splits if your PK is a clustered index (which it will be by default)
Jimmy Nilsson wrote a fantastic article about GUIDs vs. INTs and combined GUIDS. Conclusions...don't fear the GUID...well composite guids anyway.