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