After writing FROM orders AS o, why does referring to orders.total in the same query fail?

## Correlation names replace, they do not add In `FROM orders AS o`, `o` is a **correlation name** (the standard's term for a table alias). The rule is that it becomes the *exposed name* of that table reference: for the rest of the query the table is known as `o`, and only as `o`. So: ```sql SELECT orders.total -- error: nothing in scope is called orders FROM orders AS o WHERE o.status = 'PAID'; ``` Engines phrase the error differently — a missing FROM-clause entry, an unbound multi-part identifier — but they all agree on the rule. It is not a lint warning or a style preference; the old name is genuinely gone. ## Why the rule is this way Think of the `FROM` clause as declaring variables that range over rows. Each entry gets exactly one name, and column references are qualified by that name. If the base table name stayed available alongside the alias, a self-join would be incoherent: which of the two occurrences would `employees.name` mean? Making the alias replace the name gives every occurrence exactly one unambiguous handle: ```sql SELECT e.name AS employee, m.name AS manager FROM employees AS e JOIN employees AS m ON m.id = e.manager_id; ``` Here `employees` is not a usable qualifier at all, and that is precisely the point. ## Scope of a correlation name A correlation name is visible in **every clause of the query in which it is declared** — the join's `ON`, `WHERE`, `GROUP BY`, `HAVING`, the `SELECT` list and `ORDER BY` — because `FROM` is the first clause resolved. This is worth contrasting explicitly with select-list aliases, which are created much later and are visible only to `ORDER BY`. Candidates who say "aliases are not visible in `WHERE`" have merged the two kinds of alias; table aliases certainly are. ## Uniqueness within a FROM clause Two entries in the same `FROM` clause may not share a correlation name: ```sql -- error: the name o is specified more than once FROM orders AS o JOIN order_lines AS o ON o.id = o.order_id; ``` That is a direct consequence of the model — if the name did not identify one table reference, no qualified reference could be resolved. ## Schema qualification stops too Once aliased, the fully qualified form is gone as well: after `FROM sales.orders AS o`, neither `orders.total` nor `sales.orders.total` resolves. The alias is the whole handle. ## AS is optional, and its omission has a cost The standard makes `AS` optional for table aliases, so `FROM orders o` is identical to `FROM orders AS o`. The same is true for column aliases, and there the omission causes a classic bug: ```sql SELECT first_name last_name FROM users; -- one column, aliased last_name SELECT first_name, last_name FROM users; -- two columns ``` A dropped comma turns a column into an alias of the previous one, and the query still runs. Writing `AS` everywhere makes that mistake visible at a glance, which is why most style guides require it. ## Choosing alias names Since the alias becomes the only handle, its readability matters more than its brevity. Single letters are fine for two-table queries; in a six-table report, `oi` for `order_items` and `sh` for `shipments` read far better than `a` through `f`, because a reader who forgets what `d` was must scroll back to the `FROM` clause for every reference. Aliases should also stay stable across the codebase — using `c` for `customers` everywhere means a reviewer reads qualified references without re-deriving them. ## What interviewers listen for The crisp answer is one sentence — the alias replaces the table name for the scope of the query — followed by the reason it must, which is that self-joins need one distinct handle per occurrence. Adding that correlation names, unlike select-list aliases, are visible in every clause shows the candidate has the scoping model rather than a memorised error message.