Mode disclosure
All modes use one coherent workspace; only disclosure and guidance change. Learn mode keeps theory, concept names, full schema help, progressive hints, and solution review available.
Keys, Relationships, Cardinality, and Join Planning / predict result
RD-A01 - Plan a join path and intermediate grains in an unfamiliar schema
RD-A01 - Plan a join path and intermediate grains in an unfamiliar schema. Plan a join path and predict row multiplication before writing JOIN syntax.
- Result grain
- one row per category including null category
- Exact columns
- category; revenue
SQL editor shortcuts: Ctrl or Command Enter runs the query, Ctrl or Command Shift Enter checks it, Alt H opens the next hint, Ctrl or Command slash toggles a line comment, Ctrl or Command Shift F formats the SQL, and Escape closes transient UI.
Cursor at line 1, column 1.
Scenario
Retrieve the skill without relying on the lesson label.
Keys, Relationships, Cardinality, and Join Planning / predict result
One-sentence task
RD-A01 - Plan a join path and intermediate grains in an unfamiliar schema. Plan a join path and predict row multiplication before writing JOIN syntax.
Learn mode disclosure
Theory, concept names, full schema help, and progressive hints are available.
Structured output contract
- Result grain
- one row per category including null category
- Exact columns
- category; revenue
- Source population
- Use the prompt setup plus FROM, JOIN, WHERE, and subquery predicates as the source population. Visible rows are only examples.
- Grouping
- Group only at the requested output grain: one row per category including null category.
- Ordering
- order by revenue descending then category
- Validation
- select-only; hidden deterministic variants.
Relevant tables
Time and difficulty
- Estimated time
- 5 minutes
- Difficulty
- 4/5
Objective and concepts
State the requested SQL output contract for keys, relationships, cardinality, and join planning using source grain, columns, ordering, and edge-case evidence.
Glossary links
Concept material
SQL Trail treats every query as an evidence trail: identify source grain, transform rows deliberately, then compare output to a shared contract.
A passing query must handle hidden nulls, ties, boundaries, and no-match rows when the contract makes them relevant.
Syntax card
SELECT <requested_columns>
FROM <source_table>
WHERE <source_population_filter>
GROUP BY <result_grain_columns>
ORDER BY <deterministic_tie_breakers>;- <requested_columns> means the exact output columns, aliases, and order from the visible contract.
- <source_population_filter> means the row population definition, not a copied visible-row value.
- <deterministic_tie_breakers> means all ordering and tie rules needed for repeatable output.
Why this works
Join planning starts by naming each table key and the foreign keys that connect child rows back to parent tables.
Edge cases
Hidden variants preserve nulls, ties, duplicates, boundaries, no-match rows, and alternate row order when those risks apply.
PostgreSQL note
The local engine uses PostgreSQL-compatible syntax, including explicit NULL predicates, deterministic ORDER BY clauses, and transactional grading.
Worked example
SELECT table_name, primary_key, foreign_keys FROM (VALUES ('customers', 'customer_id', 'none'), ('orders', 'order_id', 'customer_id -> customers.customer_id'), ('order_items', 'order_item_id', 'order_id -> orders.order_id; product_id -> products.product_id'), ('products', 'product_id', 'category_id -> categories.category_id')) AS key_map(table_name, primary_key, foreign_keys) ORDER BY table_name;Assumptions, dialect notes, and common traps
- Duplicate policy
- Preserve duplicate facts unless the prompt explicitly asks for distinct tuples or set semantics.
- Null policy
- Preserve NULL, empty string, zero, and false as distinct values unless the contract says to display a fallback.
- Tie-breakers
- Use every ordering rule in the contract and end tied business metrics with deterministic secondary keys when needed.
- Zero-related entities
- Do not invent zero rows unless the contract asks for preserved parents, missing entities, or complete periods.
- Numeric tolerance
- Round only at the requested final stage; hidden checks use the contract precision rather than visible formatting luck.
PostgreSQL-compatible local checks
Queries run in a local PGlite worker with PostgreSQL-style syntax and transactional grading.
- Similar names are not relationships: Columns are joined because their names or types look compatible, not because a foreign key path exists. Repair: Start from primary keys and foreign keys before choosing any join condition.
- Parent rows repeat through children: A customer or order is expected to stay unique after joining to one-to-many child rows. Repair: Predict how many child rows each parent can produce before trusting row counts.
- Bridge tables can own facts: The bridge is treated as pure plumbing and quantity is looked up on a dimension table. Repair: Name the bridge grain and keep bridge facts such as quantity on that row grain.
- Cartesian products are row-count evidence: A huge joined row count is treated as business volume instead of a missing relationship condition. Repair: Compare actual rows with parent times child rows and add the missing ON predicate.
Opened hints
No hints opened yet.