Jason Lees-299789 (9/15/2010)

---

Like Nils, I dont quite understand the reason for the article, in 95% of cases the sort operation is the least of your worries in a plan, especially when you've joined 2 or 3 tables together to bring back an amalgamaged dataset, such as Stock levels by product, and unfilled orders.

I'm not a fan of the Non-clustered Index with all other columns in an Include, one or two columns that are commonly associated with the business key, eg Indexed on ProductNumber, with the ProductName and ProductCode as include columns is reasonable.

Nils Gustav Stråbø (9/15/2010)

---

Brian, I'm have to apologize to you because for some reason my eyes and brain didn't see that you kept the ORDER BY clause. For some reason I thought that the article explained a way to get rid of the ORDER BY, but when I read it again I don't know where that idea came from

Again, I'm sorry. Its a good article !

alen teplitsky (9/15/2010)

---

there were a few times i changed the sort order of indexes to make things a bit faster. when you can't spend $6000 on extra storage because all the internal hard drive bays are full but you need to optimize I/O performance you look at every little thing.

i'm waiting for the SSD server drives to get cheaper to try them out by putting tempdb on them