DataslopeYour First Analytical Query
Reading a result set like an analyst, not an application. SELECT, WHERE, and ORDER BY revisited as tools for exploration rather than retrieval.
You know SELECT, WHERE, and ORDER BY already. This page is not about
new syntax — it is about re-seeing those familiar tools through an
analyst's eyes. The same SELECT that fetches a record in an app becomes,
with a shift in intent, the first move of an exploration.
Reading a table is the analyst's "hello world"
Before summarizing anything, an analyst usually takes a quick look at a
few rows just to learn the columns and their flavor. LIMIT makes this
cheap even on a huge table — you peek, you do not pull everything.
That single SELECT * answers "what columns exist and what do typical
values look like?" — the very first question of any exploration.
WHERE as a slice, not a search
In an application, WHERE id = 4 finds one specific row. In analysis,
WHERE usually carves out a slice of the data you want to study —
Seattle trips, long trips, this month. You are not hunting a needle;
you are choosing a subset to summarize.
The mental phrasing is "narrow the data to the part I care about, then
look." WHERE is how an analyst zooms in.
ORDER BY to surface the interesting rows
Sorting is not cosmetic in analysis — it is how you bring the extremes
to the top. "Longest trips", "biggest spenders", "slowest pages": every
one is an ORDER BY followed by a glance at the head of the result.
This three-step rhythm — slice, sort, peek — is the analyst's equivalent of a first glance. It answers "what stands out?" before you commit to heavier summarizing.
Computed columns: asking a new question of each row
Analysts constantly invent columns that are not stored. "Fare per
minute", "price with tax", "is this a long trip?" — all computed on the
fly. This is where SELECT stops retrieving and starts deriving.
The column fare_per_min exists only inside this query — it is a
question, not stored data. Inventing measures like this is most of what
analytical SELECT lists are for.
The same keywords, a new purpose
| Keyword | Application meaning | Analytical meaning |
|---|---|---|
SELECT | Fetch stored columns to display | Derive measures and pick dimensions |
WHERE | Find a specific record | Carve out a slice to study |
ORDER BY | Present rows in a tidy order | Surface the extremes worth noticing |
LIMIT | Paginate results for a UI | Peek cheaply without pulling everything |
Nothing here is new SQL. What is new is the intent — and intent is what separates analytical queries from application ones.
Check your understanding
In analytical SQL, what is the most common purpose of WHERE?
To find one specific row by its primary key for display.
To carve out a slice of the data — a subset to explore or summarize.
To permanently delete rows that do not match.
To create new columns.
Why do analysts pair ORDER BY with LIMIT so often during exploration?
Because DuckDB requires LIMIT on every query.
To surface the most extreme rows (largest, smallest) and peek at just the top without pulling everything.
To randomly shuffle the rows.
To permanently sort the stored table.
A query includes ROUND(fare / minutes, 2) AS fare_per_min. What is fare_per_min?
A column physically stored in the trips table.
A derived column that exists only in this query's result — a measure the analyst invented.
A new permanent table.
An error, because you cannot divide two columns.
You can now look like an analyst. Next: how to get data into DuckDB —
and how to conjure test data out of thin air with range().
Why DuckDB?
How organizations drowning in data found a fast, zero-setup analytical engine. What makes DuckDB different from traditional databases, and why it fits modern analysis workflows so well.
Loading and Generating Data
Where analytical data comes from — tables, literal VALUES, files, and DuckDB's range() generator — plus CREATE TABLE AS, the analyst's favorite way to capture a result.