Joins and Subqueries - sql

Question

I am aware that correlated subqueries use "where" clause and not joins.
But I wonder if "where" clause and inner join can have the same outcome then why can't we use these queries with joins?
For example,
SELECT FirstName, LastName, (SELECT COUNT(O.Id) FROM [Order] O WHERE O.CustomerId = C.Id) As OrderCount
FROM Customer C
Now, why can't we write down this like below?
SELECT FirstName, LastName, (SELECT COUNT(O.Id) FROM [Order] O Inner Join
C On O.CustomerId = C.Id) As OrderCount
FROM Customer C
I know very well about SQL and worked quiet on that but I am just looking for a clear technical explanation.
Thanks.

Answer 1

This is your query:
SELECT
FirstName,
LastName,
(
SELECT COUNT(O.Id)
FROM [Order] O
INNER JOIN C On O.CustomerId = C.Id
) AS OrderCount
FROM Customer C;
It is invalid, because in the sub query you are selecting from C.
This is a bit complicated to explain. In a query, we deal with tables and table rows. E.g.:
select person.name from person;
FROM person means "from the table person". person.name means "a person's name", so it is referring to a row. It would be great if we could write:
select person.name from persons;
but SQL doesn't know about singular and plural in your language, so this is not possible.
In your query FROM Customer C means "from the customer table, which I'm going to call C for short". But in the rest of the query including the sub query it is one customer row the C refers to. So you cannot say INNER JOIN C, because you can only join to a table, not a table row.
One might try to make this clear by using plural names for tables and singular names as table aliases. If you'd make it a habit, you'd have FROM Customers Customer in your main query and INNER JOIN Customer in your inner query, and you'd notice from your habits, that you cannot have a singular in the FROM clause. But well, one gets quickly accustomed to that double meaning (row and table) of a table name in a query, so this would just be kind of over-defensive, and we'll rather use alias names to get queries shorter and more readable, just as you are doing it with abbreviating customer to c.
But yes, you can use joins instead of sub queries in the SELECT clause. Either move the sub query to the FROM clause:
SELECT
c.firstname,
c.lastname,
COALESCE(o.ordercount, 0) AS ordercount
FROM customer c
LEFT JOIN
(
SELECT customerid, COUNT(*) AS ordercount
FROM [order]
GROUP BY customerid
) o ON o.customerid = c.id;
Or join without a sub query:
SELECT
c.firstname,
c.lastname,
COUNT(o.customerid) AS ordercount
FROM customer c
LEFT JOIN [order] o ON o.customerid = c.id
GROUP BY c.firstname, c.lastname;

Answer 2

The two queries are functionally equivalent. SQL (in the context of queries) is a declarative language, which means it works by DEFINING WHAT you want to achieve, not HOW to achieve it. So, at the abstract algebrical level, between the two queries there is absolutely no difference. (*)
However, because SQL does not work in the metaphysical realm of algebra but in the real world where the declarative language of SQL needs to be transposed in a procedural sequence of operations: it is much easier for me to decide the two queries are equivalent than for the RMDB of your choice. Computing the closure of the SQL declarative query can be incredibly computationally difficult. This is done by what is usually called the "query optimizer", which has not only the function of "understanding" the relational algebra but also of finding the probabilistically best way to implement it procedurally. Therefore, depending on the accuracy of the optimizer, the intricacy of your schema and query and the amount of computational resources the optimizer allocates on closing and optimizing the execution plan, the actual execution plans for the two otherwise equivalent queries can be different. You will still get the same results (as long as you stay in the declarative realm and don't use any NOW(), RAND() or other volatile state semantics), but one plan way may be faster, another may be slower. Also the order of results may be different, where ORDER BY is missing or equivocal.
Note: your join can be rewritten this way because it involves an aggregate on a side join. Not all joins can be transposed using subqueries, but there are plenty of situations of other queries that are equivalent although expressed differently. My answer is absolutely generic for any mathematically equivalent queries. See also explanation below.
(*) Queries equivalence also depends on schema. One usual enemy of common sense is NULL values: while a join will filter out null values if there is any condition on them, aggregates will behave in variuos other ways: SUM will be null, MAX/MIN will ignore nulls, COUNT will count anything, COUNT(DISTINCT) nobody knows what will do, etc.