Phase 1 · SQL FoundationsModule 4~48 min read

SELECT Lists, Aliases & Expressions

Choose output columns deliberately, calculate derived values, assign readable aliases, and understand expression evaluation.

What you'll learn

Choose output columns deliberately, calculate derived values, assign readable aliases, and understand expression evaluation. The lab uses PostgreSQL while identifying the semantics that transfer to other relational systems.

By the end of this lesson, you'll be able to:

  • Apply SELECT list to a realistic data question
  • Apply Column qualification to a realistic data question
  • Apply Aliases to a realistic data question
  • Apply Arithmetic expressions to a realistic data question

Core mental model

SQL is declarative: describe the result or invariant you need, then let the database choose a physical execution strategy. Use this table to connect syntax to design decisions.

ConceptWhat it meansDecision rule
ProjectionChoosing the columns and expressions in the resultReturn only what the consumer needs
AliasA result-column or relation nameUse short table aliases and descriptive output aliases
DISTINCTDuplicate elimination over the entire selected rowUse only when the required result is genuinely a set

Professional workflow

Work from a defined question and result grain, then verify correctness before performance.

  1. State the SELECT-list contract question and the exact grain of the expected result.
  2. Inspect table definitions, keys, constraints, representative values, and row counts.
  3. Write the smallest correct query with explicit columns, aliases, and predicates.
  4. Test missing, duplicate, boundary, and NULL cases before trusting the result.
  5. Inspect the execution plan or affected rows when cost or data change matters.
  6. Save the query with its assumptions, parameters, verification, and recovery notes.

Make results explainable

Keep each query in a saved SQL file with a short statement of its purpose, expected grain, assumptions, and verification query.

Guided SQL lab

Create a readable price projection

Qualified inputs and descriptive aliases make the output contract obvious.

book_prices.sql
SELECT
  b.id AS book_id,
  b.title,
  b.price AS list_price,
  round(b.price * 0.90, 2) AS sale_price,
  b.title || ' — ' || b.isbn AS catalog_label
FROM course.books AS b;

Production practice

Contract

Define the expected row grain, inputs, output columns, invariants, and failure or empty-result behavior before writing SQL.

Verification

Use representative fixtures and independent row-count, uniqueness, NULL, and boundary checks; compare plans when cost matters.

Operations

Save reviewed SQL with explicit schema names where appropriate, bounded scope, least privilege, observability, and a recovery path for changes.

Common failure mode

Using DISTINCT to hide duplicate rows often masks an incorrect join or misunderstood result grain.

Independent workshop

Build a review-ready SELECT-list contract lab against the course commerce dataset.

Your finished workshop must include:

  • SELECT list
  • Column qualification
  • Aliases
  • Arithmetic expressions
  • Concatenation
  • Verification notes and edge-case evidence

Definition of done

Run the expected case and at least two edge cases, verify row counts and grain, and add comments explaining any vendor-specific behavior.

Recap & quick check

Key takeaways

  • Projection: Return only what the consumer needs
  • Alias: Use short table aliases and descriptive output aliases
  • DISTINCT: Use only when the required result is genuinely a set

Quick check

1. Which rule best applies to Projection?

2. Which rule best applies to Alias?

3. Which rule best applies to DISTINCT?

Next: Filtering with WHERE & Boolean Logic