well..I am guessing that if the PK s are already in order either by alphabet or price,etc i would not have to use the SORT BY in the SELECT command which I can only conclude slows the query down.
You mean ORDER BY,I don't think that using ORDER BY will give you a performance hit if you have indices on those fields,well in that case an clustered index can help you,if you want to keep the order in which the data is inserted on that PK.
Creating proper Indices helps a lot in the query performance...
Success is the ability to go from one failure to another with no loss of enthusiasm.
- Sir Winston Churchill
So, ORDER BY carries little overhead even if I have over 5000 rows? Right now, ORDER BY is very fast but I expect the database to get bigger in the future.
5000 rows is NOTHING.
if you put an index on the column you want to order by, you'll be fine.
also, nobody said that your PK needs to be clustered. If you are that concerned about perf of order by, make the PK nonclustered, and the index on your sorting column clustered, as rudra suggests.
EDIT: generally, I have found that very often it's wrong to make assumptions about where perf problems are. The only to know for sure is to measure. For sql this means use profiler and showplan. For compiled code it means profile it using some other tool. The point is you need to measure before making statements about where the perf issues lie.