Streamhub's BI team is configuring a reporting framework that segments metrics by named calendar windows (Q1, holiday season, etc.).
Write a query to return every reporting period's numeric ID, display name, and the month numbers that define its start and end.
Assumptions:
- The
periodstable contains the calendar windows Streamhub uses to bucket metrics. - Each row has an
id, aname, astart_month, and anend_month(both expressed as month numbers, 1–12).
Output:
- One row per period, with columns
id,name,start_month, andend_month.
Schema · analytics 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
id,
name,
start_month,
end_month
FROM
periodsThe shape
FROM periods reads the lookup table that defines Streamhub's reporting windows, and the four columns in the SELECT list hand back the full definition of each window: its identifier, its display label, and the month boundaries that mark where it begins and ends.
Clause by clause
SELECT id, name, start_month, end_monthreturns four columns per row, in source order. The identifier comes first so the reporting framework can reference each period unambiguously, then the human-readable name (Q1, holiday season, and so on), then the two integer month numbers that define the window. The month numbers land as integers, between1and12, exactly as the prompt describes.FROM periodsis the row source — the configuration table that defines how the reporting framework slices the calendar. There's noWHEREclause because the framework needs the full set of period definitions; filtering would mean some windows wouldn't render, and the bucketing logic downstream would have gaps.
Why this and not hardcoding the windows
The periods could in principle be hardcoded in every report that needs to bucket metrics — write WHERE month BETWEEN 1 AND 3 for Q1, repeat that pattern wherever quarter logic appears. That works on day one and breaks the moment the business decides Q1 actually ends in February for fiscal reasons, or that the holiday season this year starts on a different date than last year. Every report would have to be tracked down and updated by hand.
A periods table is the alternative. The window definitions live in one place; reports read from the table; updating the business calendar means updating one row, and every report that joins against periods reflects the change automatically. Reading the table directly is how the framework exposes those definitions to whatever code generates the reports.
The trap
Treating a small, slow-changing lookup table as too simple to bother with. The periods table only has a handful of rows, and a learner might assume the query should be more complicated than SELECT … FROM periods because the problem is marked Hard. It isn't. The hardness is recognising what role the table plays — the source of truth for how the rest of the analytics stack groups time — not the syntax of the query that reads it. Simple shape, load-bearing data.
You practiced reading a configuration-style table — small, stable rows that drive how other queries group time. Many analytics systems have a periods table or equivalent for this exact purpose.
