Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 3: The Foundation Statements of T-SQL
52
This will produce the following results:
Name ProductNumber ReorderPoint
------------------------------ ---------------- ------------
Adjustable Race AR-5381 750
Bearing Ball BA-8327 750
...
...
Road-750 Black, 48 BK-R19B-48 75
Road-750 Black, 52 BK-R19B-52 75
(504 row(s) affected)
As it happened, our query result set was sorted in ProductID order. Why? Because SQL Server decided
that the best way to look at this data was by using an index that sorts the data by ProductID. That just
happened to be what created the lowest-cost (in terms of CPU and I/O) query. Were we to run this exact
query when the table has grown to a much larger size, SQL Server might have choose an entirely different
execution plan, and therefore might sort the data differently. We could force this sort order by changing
our query to this:
SELECT Name, ProductNumber, ReorderPoint
FROM Production.Product
ORDER BY Name;
Note that the WHERE clause isn’t required. It can either be there or not depending on what you’re trying
to accomplish. Just remember that if you do have a WHERE clause, it goes before the ORDER BY clause.
Unfortunately, that previous query doesn’t really give us anything different, so we don’t see what’s
actually happening. Let’s change the query to sort the data differently — by the ProductNumber:
SELECT Name, ProductNumber, ReorderPoint
FROM Production.Product
ORDER BY ProductNumber;
Now our results are quite different. It’s the same data, but it’s been substantially rearranged:
Name ProductNumber ReorderPoint
-------------------------------------- ------------------------- ------------
Adjustable Race AR-5381 750
Bearing Ball BA-8327 750
LL Bottom Bracket BB-7421 375
ML Bottom Bracket BB-8107 375
...
...
Classic Vest, L VE-C304-L 3
Classic Vest, M VE-C304-M 3
Classic Vest, S VE-C304-S 3
Water Bottle - 30 oz. WB-H098 3
(504 row(s) affected)