Ninth in a series of posts in response to Tim Ford's #EntryLevel Challenge.

Subqueries are queries within a query – one SELECT nested within another. They can take the place of column and table references, helping you to formulate queries that otherwise would be more difficult or less efficient to express using join operations. 

As Columns

Following is an example of a subquery filling a position typically occupied by a column name or expression. The goal of the query is to list the number of products per subcategory.

SELECT ps.name,
    (SELECT COUNT(*)
    FROM Production.Product p
    WHERE p.ProductSubcategoryID = ps.ProductSubcategoryID) AS sub_count
FROM production.ProductSubcategory ps

The output looks as  follows:

In an interview for the NoCOUG Journal (http://www.nocoug.org/Journal/NoCOUG_Journal_200608.pdf#page=4), Steven Feuerstein was asked: “SQL is a set-oriented non-procedural language; i.e., it works on sets and does not specify access paths. PL/SQL on the other hand is a record-oriented procedural language, as is very clear from the name. What is the place of a record-oriented procedural language in the relational world?”

Steven replied: “Its place is proven: SQL is not a complete language. Some people can perform seeming miracles with straight SQL, but the statements can end up looking like pretzels created by someone who is experimenting with hallucinogens. We need more than SQL to build our applications, whether it is the implementation of business rules or application logic.

It requires a vast amount of work to organize a tech­nical conference and publish a printed journal every quarter. No sooner has a conference ended and a journal mailed than it is time to start work on the next conference and the next journal. NoCOUG has no funding from Oracle Corporation and a miniscule budget compared to the national and inter­national user groups, but the NoCOUG volunteers have always managed to pull it off, quarter after quarter for 30 long years.(read more)