Understanding nested select for ORM - sql

Question

I'm reading the article explaining the nested-loop-join algorithm and I don't exactly understand the actual working principle of nested selects. Here is an example provided by the article:
The examples search for employees whose last name starts with 'WIN'
and fetches all SALES for these employees.
And the queries representing the nested-loop join are these:
select employees0_.subsidiary_id as subsidiary1_0_
-- MORE COLUMNS
from employees employees0_
where upper(employees0_.last_name) like ?;
select sales0_.subsidiary_id as subsidiary4_0_1_
-- MORE COLUMNS
from sales sales0_
where sales0_.subsidiary_id=?
and sales0_.employee_id=?;
select sales0_.subsidiary_id as subsidiary4_0_1_
-- MORE COLUMNS
from sales sales0_
where sales0_.subsidiary_id=?
and sales0_.employee_id=?;
As you can see, the two last queries are perfectly the same. This is what I confused by. Why isn't just generating the first two queries not enough? Why do we have to generate the third one?

Answer 1

Bear in mind that the code you pasted is the referenced article example of what not to do – an anti-pattern.
That said, the queries are parameterized, and therefore not actually identical. The two initial ? chars in each query are parameters will be replaced by a different value for subsidiary_id in each iteration of the for loop.

Answer 2

It is not necessary to generate the third query. If you write SQL queries manually you can load all sales for all retrieved employees as a single query. But the "N+1 query" anti-pattern arises when the program code looks like in the article:
for (Employees e: emp) {
// process Employee
for (Sales s: e.getSales()) {
// process sale for Employee
}
}
In that code e.getSales() method loads data for one employee. This method does not have enough information to load sales data for all other employees too, because the ORM does not have full list of employees for which it is necessary to load sales data. So, ORM is forced to load sales data of each employee in a separate query.
Some ORMs can avoid "N+1 query" problem automatically. For example, in PonyORM (written in Python) the code from the article will looks like this:
# the first query loads all necessary employees
employees = select(e for e in Employee if e.lastName.startswith('WIN'))
for e in employees:
# process Employee
for sale in e.sales:
# process sale for Employee
When program starts loop over employee query, PonyORM loads all the necessary employees at once. When the sales items for the first employee are requested, PonyORM loads it for this employee only (because ORM doesn't know our intention and supposes that maybe we need sales data for the first employee only). But when sales data of the second employee are requested, PonyORM notices the "N+1 query" anti-pattern, sees that we have N employee objects loaded in memory, and loads sales for all remaining employees in a single query. This behavior can be considered as a heuristic. It may load some extra sales objects if our for-loop contains break operation. But typically this heuristic leads to better performance, because it can drastically reduce the number of queries. Typically it is not a problem to load some extra data, it is much more important to reduce the number of roundtrips to the server.