IMHO you are doing very good. I am not an SQL expert either:) What I do is not to let SQL server create the PK as clustered (by default it creates as clustered). Instead I create PK as nonclustered. With clustered as you say the data is sequential by the key and if you are getting multiple rows with close values then likely some of the "next or previous" data is already in the pages read and wouldn't need another I/O. The keys themselves are directly there. However I think this is also time based, as time pass and newer SQL versions come out this clustered/nonclustered thing doesn't seem as much important as it was a year ago. SQL server itself compensates such things with innovatiosn like:
partitions on the table and indexes,
include clause includes mostly needed columns directly in the index itself so like in a clustered index you don't need to go to index, once you find your data in index you don't need to go to data:)
parallel execution
...

I use index tuning wizard to find out the indexes and statistics I need to create for better performance. I didn't experience a slowdown due to GUIDs (of course I think I would see 5-10% difference if I benchmark them I think but didn't have something slowing down enough to worth measuring it).

Yet another strategy for those who doesn't like GUIDs may be having int Indentity as Primary key and a GUID as candidate key. With Entity Framework, change tracking service, local caching, azure, dryad, Oslo's ... help maybe I wouldn't care how and what the backend use for a key in very near future:)

It never ends:)

Cetin


>Thanks Cetin,
>
>I have been in the GUID camp for quite some time and never knew of the issue with clustered indexes. This has caused me to go back to the learning table again to figure this out. Since I am a developer and not a SQL Expert, I don't know many things about SQL. I am a good table designer, but that is about the extent of it.
>
>Learning about GUID and Sequential Guid has made me also need to learn about Clustered and Non-Clustered indexes. Here is what I think I have learned.
>
>Clustered indexes are good for columns where searches are performed that return multiple rows or are searching for rows between values.
>Non clustered indexes are more appropriate for querys that return a single row.
>Primary Key's automatically create a constraint with a clustered index.
>Sequential Guids have a disadvantage in they can be easily figured out by another, but I don't show them so that shouldn't be an issue.
>
>My Guid primary keys are rarely used for returning multiple rows - well probably never when it is the primary key. I do return multiple rows for child records which have a Guid but it is not a primary key.
>
>If I use a standard Guid for the primary key, can I cause the index not to be a clustered index? If I can do that, then It seems there is not an issue. I just create clustered index on those columns where they would be most appropriate and not on my primary key Guid's.
>
>Am I getting close?
>Tim
>
>>>Hi all,
>>>
>>>I just attended a SQL Saturday in Dallas this past Saturday and I got the impression GUID's were not such a great idea for PK's. I would like to understand why that is, and what is the best choice for tables with lots of records.
>>>Thanks
>>>Tim
>>
>>Tim,
>>It is about being on what camp you are in. I am in GUID camp and I think GUIDs are perfect idea for primary key fields. Search for COMB GUID and you would find Jim Wilson's (I hope I remember the name right) "sequential" GUID before NewSequentialID() existed and his article about it (along with benchmarks that shows GUID is not bad). Also you would find C# code for creating those COMB GUIDs. COMB GUIDs are important because generally the developers who use GUIDs want to know the keys before connecting to backend (say working on notebook on the field and there is no wireless support). SQL server have NewSequentialID() and newID() but you need to trip to server to get them and sort of defeats the purpose of preferrring GUIDs.
>>Cetin