Well, if you ever wanted to replicate the data to somewhere else that it could be written then GUIDs would be a good way to eliminate potential conflict in the allocated IDs.
The downside is that because the IDs are no longer sequential then you can't use it to ask simple questions like which client was added most recently; you'd use some sort of date column instead.
Using GUIDs makes it very difficult for an end user to consume (though you shouldn't be exposing internal IDs to your end users, anyhow.). Numbers, or strings that are partially based on the client name are easier for end users to use. However, I'm not a particular
fan of them because of the scenario where the client changes their name.
If your data is ordered by the ID then you could observe the following:
- GUIDs should give you a more even distribution across spindles.
- Sequential IDs might give you performance gains by resulting in cache hits to adjacent records. Of course this assumes that you are more likely to want to access a record added recently than one added further back.
- Queries that execute across a range of dates that a client was added will benefit from the records being adjacent - less seeks.
