Keith,
This new clustered index is a composite of the PK column and a FK. I agree with your original assessment of the index's column structure. That's my issue, as well... and the one I'll be bringing up with our "guru" since the FK column doesn't seem to add anything to the uniqueness of records due to our business rules (it's a combination of PK OrderID and FK order import BatchID... but the OrderID is already guaranteed to be unique, so what does the BatchID bring to the "table" that it should be part of the clustered index?). IOW, excellent candidate for an index, but why clustered?

The system is OLSP (Online schizophrenic processing) but it's good people. Like most systems -- I suspect -- it's OLTP but the ratio is skewing weekly toward OLAP. "Someday" we'll have those new dedicated servers.

Thanks for your time and help,
---J

>Jason,
>
>The books you read were correct about indexing for speed. My flippancy was more along the lines of a unique clustered composite index - which is usually an indicator that the columns in the key should actually be foreign keys. I.e. because those columns are (i'm assuming) readable text, and because combined they uniquely identify the row, they should be in one or more separate tables. Bleh, it's not easy to put into words.
>

>This is really dependant on whether your system is closer to OLTP or OLAP. OLTP is all about da' inserts, OLAP is all about da' sorts. If all of your joins are on PKs and FKs (I hope they are), then clustered PKs can speed up queries greatly. If most of your queries are flat, then sort order becomes the primary concern.