Level 1 · Look at the product catalog

A database stores data in tables. A table looks like a spreadsheet: each row is one thing (here, one product) and each column is one fact about it (its name, category, price). The Harbor & Pine database has eight tables: customers, products, orders, order_items, returns, employees, web_sessions and marketing_spend.

To read from a table you write a SELECT statement:

SELECT *
FROM products;

Read it out loud: “select everything from products”. SELECT lists the columns you want, * is a shortcut for “all columns”, and FROM names the table. The semicolon ends the statement. SQL keywords are not case-sensitive, so select * from products works too, but writing keywords in capitals is the common convention and makes queries easier to scan.

What you will see

The products table has one row per item in the catalog, with columns such as product_id, name, category, subcategory, unit_price, unit_cost, launched_on and is_active. Take a moment to look at the values. Notice that some unit_cost cells are empty: that is a NULL, which means “unknown”, not zero. NULLs will come up again and again, because they behave differently from every other value.

When analysts use SELECT *

SELECT * is perfect for exploring a table you have never seen. It is a bad habit in anything you save or share:

• On wide tables with millions of rows it reads far more data than you need, which is slow and, in cloud warehouses like BigQuery or Snowflake, costs real money because you pay per column scanned.
• If someone adds a column to the table later, your report silently changes shape.
• It hides intent. A reviewer cannot tell which columns your logic depends on.

A common workflow is: SELECT * with a row limit to explore, then replace the star with the columns you actually need. You will learn LIMIT in chapter 3; in most databases SELECT * FROM products LIMIT 10; shows only the first ten rows.

Common mistakes

• Forgetting FROM. SELECT * alone has nothing to read from.
• Misspelling the table name. Table names must match exactly; product is not products.
• Expecting rows in a particular order. Without ORDER BY, a database may return rows in any order, and that order can change between runs. Never rely on it.