Select Distinct
The first predicate option in the SELECT command is the keyword DISTINCT,
which eliminates duplicate rows from the result set of the query. The
duplications are based only on the output columns, not the underlying
tables. The opposite of DISTINCT is ALL. Because ALL is the default, it is typically not included.
The following example demonstrates the difference between DISTINCT and ALL. Because this select statement returns only the productname column, it's a perfect example of duplicate rows for the DISTINCT predicate:
USE AdventureWorks;
SELECT ALL p.Name
FROM Production.Product p
INNER JOIN Sales.SalesOrderDetail so
ON p.ProductID = so.ProductID
Result:
Name
--------------------------------------------------
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
Sport-100 Helmet, Red
. . .
With the DISTINCT predicate:
USE AdventureWorks;
SELECT DISTINCT p.Name
FROM Production.Product p
INNER JOIN Sales.SalesOrderDetail so
ON p.ProductID = so.ProductID;
Result:
Name
----------------------------------
Sport-100 Helmet, Red
Sport-100 Helmet, Black
Mountain Bike Socks, M
Mountain Bike Socks, L
Sport-100 Helmet, Blue
AWC Logo Cap
Long-Sleeve Logo Jersey, S
. . .
Whereas the first query returned 121,317 rows, the DISTINCT predicate in the second query eliminated the duplicate rows and returned only 266 unique rows.
Caution
SQL Server's DISTINCT is different from MS Access' distinctrow, which eliminates duplicates based on data in the source tables, not duplicates in the result set of the query.
Select DISTINCT functions as though a GROUP BY clause exists on every output column.
Of course, using DISTINCT
is based on the query's requirements, so there may be no choice; just
be aware that depending on the size and mix of the data, there may be a
performance impact.
TOP ()
By definition, SELECT
works with sets of data. Sometimes, however, it's only the first few
rows from the set that are of interest. For these situations, SQL
Server includes several ways to filter the results and find the top
rows.
As mentioned earlier, SQL Server returns all the rows from the SELECT statement by default. The optional TOP()
predicate tells SQL Server to return only a few rows (either a fixed
number or a percentage) based upon the options specified . A variable can be passed to TOP().
Note
The older syntax for TOP()
did not include the parentheses and did not accept a variable. The
newer syntax, with the parentheses, was introduced with SQL Server 2005
and is the best practice moving forward.
TOP() works hand-in-hand with ORDER BY. It's the ORDER BY clause that determines which rows are first. If the SELECT statement does not have an ORDER BY clause, then the TOP() predicate still works by returning an unordered sampling of the result set.
The AdventureWorks sample database is a good place to test the TOP() predicate. The following query finds the top 3 percent of product prices in the Product table. The Product lists all products and their corresponding prices:
USE AdventureWorks;
SELECT TOP(3) PERCENT
ProductNumber, Name, ListPrice, SellStartDate
FROM Production.Product
ORDER BY ListPrice DESC
Result:
ProductNumber Name ListPrice SellStartDate
------------- -------------------- ---------- -----------------------
BK-R93R-62 Road-150 Red, 62 3578.27 2005-07-01 00:00:00.000
BK-R93R-44 Road-150 Red, 44 3578.27 2005-07-01 00:00:00.000
BK-R93R-48 Road-150 Red, 48 3578.27 2005-07-01 00:00:00.000
BK-R93R-52 Road-150 Red, 52 3578.27 2005-07-01 00:00:00.000
BK-R93R-56 Road-150 Red, 56 3578.27 2005-07-01 00:00:00.000
BK-M82S-38 Mountain-100 Silver, 38 3399.99 2005-07-01 00:00:00.000
BK-M82S-42 Mountain-100 Silver, 42 3399.99 2005-07-01 00:00:00.000
BK-M82S-44 Mountain-100 Silver, 44 3399.99 2005-07-01 00:00:00.000
BK-M82S-48 Mountain-100 Silver, 48 3399.99 2005-07-01 00:00:00.000
BK-M82B-38 Mountain-100 Black, 38 3374.99 2005-07-01 00:00:00.000
BK-M82B-42 Mountain-100 Black, 42 3374.99 2005-07-01 00:00:00.000
BK-M82B-44 Mountain-100 Black, 44 3374.99 2005-07-01 00:00:00.000
BK-M82B-48 Mountain-100 Black, 48 3374.99 2005-07-01 00:00:00.000
BK-R89R-44 Road-250 Red, 44 2443.35 2006-07-01 00:00:00.000
BK-R89R-48 Road-250 Red, 48 2443.35 2006-07-01 00:00:00.000
BK-R89R-52 Road-250 Red, 52 2443.35 2006-07-01 00:00:00.000
The next query locates the six lowest prices in the product table:
USE AdventureWorks;
SELECT TOP(6)
ProductNumber, Name, ListPrice,
CONVERT(VARCHAR(10),SellStartDate,1) SellStartDate
FROM Production.Product
ORDER BY ListPrice DESC
Result:
ProductNumber Name ListPrice SellStartDate
-------------- --------------------- ------------- -------------
BK-R93R-62 Road-150 Red, 62 3578.27 07/01/05
BK-R93R-44 Road-150 Red, 44 3578.27 07/01/05
BK-R93R-48 Road-150 Red, 48 3578.27 07/01/05
BK-R93R-52 Road-150 Red, 52 3578.27 07/01/05
BK-R93R-56 Road-150 Red, 56 3578.27 07/01/05
BK-M82S-38 Mountain-100 Silver, 38 3399.99 07/01/05
The query looks clean and the result looks good,
but unfortunately it's wrong. If you look at the raw data sorted by
price, you can actually see five rows with a price of 3578.27 and four
rows with a price of 3399.33. The WITH TIES option solves this problem, as described in the following section.
Best Practice
By the nature of the formatting,
computer-generated data tends to appear correct. Unit testing the query
against a set of data with known results is the only way to check its
quality.
The number of rows returned by TOP() may be controlled using a variable:
SELECT TOP (@Variable)
The WITH TIES Option
The WITH TIES option is important to the TOP() predicate. It enables the last place to include multiple rows if those rows have equal values in the columns used in the ORDER BY clause. The following version of the preceding query includes the WITH TIES option and correctly results in five rows from a TOP 6 predicate:
USE AdventureWorks;
SELECT TOP(6) WITH TIES
ProductNumber, Name, ListPrice,
CONVERT(VARCHAR(10),SellStartDate,1) SellStartDate
FROM Production.Product
ORDER BY ListPrice DESC
Result:
ProductNumber Name ListPrice SellStartDate
-------------- --------------------- ------------- -------------
BK-R93R-62 Road-150 Red, 62 3578.27 07/01/05
BK-R93R-44 Road-150 Red, 44 3578.27 07/01/05
BK-R93R-48 Road-150 Red, 48 3578.27 07/01/05
BK-R93R-52 Road-150 Red, 52 3578.27 07/01/05
BK-R93R-56 Road-150 Red, 56 3578.27 07/01/05
BK-M82S-38 Mountain-100 Silver, 38 3399.99 07/01/05
BK-M82S-38 Mountain-100 Silver, 38 3399.99 07/01/05
BK-M82S-38 Mountain-100 Silver, 38 3399.99 07/01/05
BK-M82S-38 Mountain-100 Silver, 38 3399.99 07/01/05
Note
If you move from Access to SQL Server, be aware that Access, by default, automatically adds the WITH TIES option to the TOP() predicate.
Note
An alternative to TOP() is the SET ROWCOUNT command, which limits any DML command to affecting only n number of rows until it's turned off with SET ROWCOUNT 0. The issue is that ROWCOUNT isn't portable either, and it's been deprecated for INSERT, UPDATE, and DELETE in SQL Server 2008.
Selecting a Random Row
There are times when you need a single random row. You can use this technique when populating a table with random names.
Using the TOP(1) predicate returns a single row, and sorting the result set by newid() randomizes the sort. Together they return a random row each time the query executes.
There is a performance cost to using TOP(1) and newid(). SQL Server has to add a uniqueidentifier to every row and then sort by the uniqueidentifier. An elegant solution is to add a tablesample option to the table when randomly selecting a single row from a large table. Tablesample works by randomly selecting pages within the table and then returning every row from those pages from the FROM clause:
USE AdventureWorks;
SELECT TOP(1) LastName
FROM Person.Person TableSample (10 Percent)
ORDER BY NewID();
