Some tasks can be performed in two ways, both by joins and subqueries. Under what situations should we opt for subqueries?
Write your query using a subquery instead of a join when it is easier for you to understand what the purpose or intent of the query is. Remember, you not only have to write it, you may have to come back six months later and figure out what it's doing! I'll demonstrate with two examples:
Do you prefer:
select a.foo, a.bar from table1 a inner join table2 b on a.id = b.id and b.qux = '937' group by a.foo, a.bar
select foo, bar from table1 where id in ( select id from table2 where qux = '937' )
Do you prefer:
select a.foo, a.bar from table1 a left outer join table2 b on a.id = b.id and b.qux = '937' where b.id is null
select foo, bar from table1 where not exists ( select 1 from table2 where id = table1.id and qux = '937' )
Ordinarily, when writing SQL, you should not be concerned with performance. Instead, you should focus all your intellect on ensuring that you get the correct results, and let the database optimizer figure out how to satisfy the query. So the first consideration is whether the join and subquery techniques actually do both produce the same correct results in either example.
The other consideration is maintainability. The first example returns rows from table1 with matching qualified rows in table2, while the second example returns only rows without qualified matches. Now consider how you would have to modify each query in both examples to add another condition, to return only those rows from table1 that also have a qualifying matching row in table3. You may discover that the join technique is severely limiting.
For More Information
- Dozens more answers to tough SQL questions from Rudy Limeback.
- The Best SQL Web Links: tips, tutorials, scripts, and more.
- Have an SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical SQL questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, SQL Server, DB2, object-oriented and data warehousing gurus are waiting to answer your toughest questions.