>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
>

There is no such thing as common sense. It's really uncommon sense that we want. Many people will tell you dynamic sql is bad, but very few tell you that is wrong and that dynamic parameterized sql is perfectly acceptable.
http://www.sommarskog.se/dynamic_sql.html

Many say GUID is bad. MS added the NewSequentialID based on Jimmy Nilsson's article
http://www.informit.com/articles/article.aspx?p=25862

From Wikipedia

"In Microsoft SQL Server, the leaf node of the clustered index corresponds to the actual data, not simply a pointer to data that resides elsewhere, as is the case with a non-clustered index. Each relation can have a single clustered index and many unclustered indexes."

I take that to mean that when I say "get me the data for the record with pk=guid1", it reads that record directly - in one step, rather than the two steps of first finding the pointer for the record with lastname = 'Smith' and then getting the record via that pointer.

How do you decide what is the "natural" order for the table - and thereby decide which column should be the clustered index? I don't bother with that question. Sequential GUID or Int is the clustered index - the natural order being the entry order everytime. The 249 other non-clustered keys get me the data, one or multiple records, any way the user wants.

Since I often use a list/grid of records, the user is basically providing the GUID, so a single step to get the record looks good to me.