Correlated subqueries are not as neat, but they are very valuable (they can handle problems you can't easily approach with joins or simple subqueries). For now, just understand the syntax, and get an idea of how correlated subqueries work. As you experiment, you'll become comfortable with them.
In the correlated subquery, the inner query cannot be evaluated independently: It references the outer query and is executed once for each qualified row in the outer query. In the example in Figure 8.2, the outer table (publishers) has three rows, so the inner query will run three times.
Conceptually, the processing follows these steps:
Correlated queries require explicit naming for columns from the outer query (you can use aliases, as p.pub_id for publishers.pub_id in Figure 8.2). Columns belonging to the inner query table are implicitly qualified by it.
However, you can always specify both tables:
SQLselect pub_name from publishers where exists (select * from titles where titles.pub_id = publishers.pub_id and type = 'business' )
3.145.81.24