Beginning SQL

Beginning SQL Beginning SQL

marjan.fesb.hr
from marjan.fesb.hr More from this publisher
20.07.2013 Views

Chapter 9 284 The query would work fine; however, the number of members born before that date is very small, whereas plenty of people live in New State. This means that State = New State will occur a number of times and the database system will go on to check the second condition, DateOfBirth < ‘1940-01-01’. If you swap the conditions around, the least likely condition (DateOfBirth < ‘1940-01-01’) is evaluated first: SELECT FirstName, LastName FROM MemberDetails WHERE DateOfBirth < ‘1940-01-01’ AND State = ‘New State’; Because the condition is mostly going to be false, the second condition will rarely be executed, which saves time. It’s not a big deal when there are few records, but it is when there are a lot of them. ❑ When using OR, put the condition most likely to be true first. Whereas AND needs both sides to be true for the overall condition to be true, OR needs only one side to be true. If the left-hand side is true, there’s no need for OR to check the other condition, so you can save time by putting the most likely condition first. Consider the following statement: SELECT FirstName, LastName FROM MemberDetails WHERE State = ‘New State’ OR DateOfBirth < ‘1940-01-01’; If New State is true, and it is true more often than DateOfBirth < ‘1940-01-01’ is true, then there’s no need for the database system to evaluate the other condition, thus saving time. ❑ DISTINCT can be faster than GROUP BY. DISTINCT and GROUP BY often do the same thing: limit results to unique rows. However, DISTINCT is often faster with some database systems than GROUP BY. For example, examine the following GROUP BY: SELECT MemberId FROM Orders GROUP BY MemberId; The GROUP BY could be rewritten using the DISTINCT keyword: SELECT DISTINCT MemberId FROM Orders; ❑ Restrict join results. The less information the database has to pull out, the better. This is particularly true with joins, which are very expensive time-wise. Put the restrictive condition on the outer table of the join. The outer table is the table on the right of the INNER JOIN keyword. For example, in the following code, the table with the restriction — a condition in the WHERE clause restricting results — is the MemberDetails table, which is the outer table in the join: SELECT MemberDetails.MemberId, FirstName, LastName FROM Orders INNER JOIN MemberDetails ON Orders.MemberId = MemberDetails.MemberId WHERE MemberDetails.DateOfBirth BETWEEN ‘1900-01-01’ AND ‘1970-12-31’;

Chapter 9<br />

284<br />

The query would work fine; however, the number of members born before that date is very<br />

small, whereas plenty of people live in New State. This means that State = New State will<br />

occur a number of times and the database system will go on to check the second condition,<br />

DateOfBirth < ‘1940-01-01’. If you swap the conditions around, the least likely condition<br />

(DateOfBirth < ‘1940-01-01’) is evaluated first:<br />

SELECT FirstName, LastName<br />

FROM MemberDetails<br />

WHERE DateOfBirth < ‘1940-01-01’ AND State = ‘New State’;<br />

Because the condition is mostly going to be false, the second condition will rarely be executed,<br />

which saves time. It’s not a big deal when there are few records, but it is when there are a lot of<br />

them.<br />

❑ When using OR, put the condition most likely to be true first. Whereas AND needs both sides to<br />

be true for the overall condition to be true, OR needs only one side to be true. If the left-hand<br />

side is true, there’s no need for OR to check the other condition, so you can save time by putting<br />

the most likely condition first. Consider the following statement:<br />

SELECT FirstName, LastName<br />

FROM MemberDetails<br />

WHERE State = ‘New State’ OR DateOfBirth < ‘1940-01-01’;<br />

If New State is true, and it is true more often than DateOfBirth < ‘1940-01-01’ is true, then<br />

there’s no need for the database system to evaluate the other condition, thus saving time.<br />

❑ DISTINCT can be faster than GROUP BY. DISTINCT and GROUP BY often do the same thing:<br />

limit results to unique rows. However, DISTINCT is often faster with some database systems<br />

than GROUP BY. For example, examine the following GROUP BY:<br />

SELECT MemberId<br />

FROM Orders<br />

GROUP BY MemberId;<br />

The GROUP BY could be rewritten using the DISTINCT keyword:<br />

SELECT DISTINCT MemberId<br />

FROM Orders;<br />

❑ Restrict join results. The less information the database has to pull out, the better. This is particularly<br />

true with joins, which are very expensive time-wise. Put the restrictive condition on the<br />

outer table of the join. The outer table is the table on the right of the INNER JOIN keyword. For<br />

example, in the following code, the table with the restriction — a condition in the WHERE clause<br />

restricting results — is the MemberDetails table, which is the outer table in the join:<br />

SELECT MemberDetails.MemberId, FirstName, LastName<br />

FROM Orders INNER JOIN MemberDetails<br />

ON Orders.MemberId = MemberDetails.MemberId<br />

WHERE MemberDetails.DateOfBirth BETWEEN ‘1900-01-01’ AND ‘1970-12-31’;

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!