Table Aliases
In a join, the names of the tables come up again and again: in ON, and in front of each column that both tables have. Queries get long. That's why you can give a table a short name, an alias, right after its name in FROM or JOIN. This is the query from the previous exercise, with aliases:
SELECT g.title, r.stars, r.comment
FROM reviews AS r
JOIN games AS g ON r.game_id = g.id
ORDER BY g.title, r.customer_id;| title | stars | comment |
|---|---|---|
| Bakery Story | 4 | Cute and calm. |
| Cube Logic | 3 | NULL |
| Cube Logic | 5 | Perfect for the bus. |
| … | … | … |
r now stands for reviews and g for games in the whole query, even in SELECT, which comes before FROM: the database reads the whole query before it runs it. An alias is usually the first letter of the table's name, or a few letters, so that it's clear which table is which. For tables, AS is optional: FROM reviews r JOIN games g ON … means the same, and you'll often see it written that way.
g.title is a qualified column name: the alias of the table (or its name, when it has no alias), a dot, and the name of the column. In the result, the column is called just title. Once a table has an alias, use the alias everywhere: the table's own name doesn't work in that query anymore, and reviews.stars would end with the error no such column: reviews.stars.
Qualified names are a must when both tables have a column with the same name. order_items and games both have a price, and if you write just price, the database doesn't know which one you mean:
SELECT title, price, quantity
FROM order_items AS i
JOIN games AS g ON i.game_id = g.id;Error on line 1: ambiguous column name: priceAmbiguous means “it could mean more than one thing”. SQLite doesn't guess, and that's good: it makes a big difference whether you get the price the customer paid (i.price) or the game's price in the catalog (g.price). The same goes for id, which orders, customers and games all have. A column that's in only one of the tables, such as title, works without the alias, but in a query with a join, it's a good habit to qualify every column. Whoever reads the query (you, a month from now) sees at once where each column comes from.
When you want the same column from both tables, rename them with AS, as you learned in lesson 2, so that the result doesn't have two columns with the same name:
SELECT o.id AS order_id, c.id AS customer_id, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
ORDER BY o.id;| order_id | customer_id | name |
|---|---|---|
| 1 | 1 | Emma Clark |
| 2 | 2 | Liam Turner |
| … | … | … |
Note ORDER BY o.id: just id would be ambiguous there too.
Instructions
The query in the editor should list the orders with their status and the customer's email, but it ends with an error. Run it and read the error. Then fix it: the id should be the order's, so write orders.id instead, in SELECT and in ORDER BY. The result then starts like this:
| id | ordered_at | status | |
|---|---|---|---|
| 1 | 2024-01-20 | paid | emma.clark@mail.com |
| 2 | 2024-02-14 | paid | liam.t@mail.com |
| 3 | 2024-02-29 | paid | olivia@brownfamily.net |
| … | … | … | … |
Now make the query shorter with aliases: o for orders and c for customers. Use them everywhere in the query, ON included. The result stays the same.
Below it, write a query that shows each item of every order with both prices: the order_id, the title of the game, its price in the catalog as list_price, and the price the customer paid as paid. Use the aliases i for order_items and g for games, and sort the rows by order_id from the highest, then by title. Order 28, from the Black Friday sale, shows the difference:
| order_id | title | list_price | paid |
|---|---|---|---|
| 30 | Bakery Story | 15 | 15 |
| 30 | Moon Farm | 20 | 20 |
| 29 | Knight's Oath | 60 | 60 |
| 28 | Shadow Ninja | 25 | 15 |
| 28 | Zombie Town | 30 | 20 |
| … | … | … | … |
Start programming for free
3/12