From SQL Queries to Analysis: Answering Real Questions with Data

At this point, you already know what tables represent and how to write basic queries. The next step is where SQL becomes genuinely powerful: using data to answer real questions.

A lot of beginners hit a wall here. They can write SELECT, WHERE, and maybe even GROUP BY, but the moment someone asks a business question, they do not know where to begin. Usually the problem is not missing syntax. It is missing structure.

When someone asks, "Which category is selling best?" the real challenge is translating that sentence into a metric, a dimension, and a query plan. That is the skill this post is meant to build.

Why is analysis different from basic querying?

A query can simply retrieve rows. Analysis usually asks you to define what matters.

Compare these:

• Query question: which orders exist in the orders table?
• Analysis question: which product category is performing best?
• Query question: which orders belong to customer 1?
• Analysis question: which customers are the most active?

The difference is that analysis introduces two important ideas:

• A metric is what you want to measure, such as order count, units sold, or revenue.
• A dimension is the angle you want to group by, such as category, customer, or date.

Once you can identify the metric and dimension, many beginner SQL analysis tasks become much easier to design.

Translate the business question before writing SQL

Suppose someone asks, "Which category is selling best this week?"

Before writing code, break it down in plain language:

1. What does "selling best" mean here? Units sold, revenue, or number of orders?
2. Since the question asks about category, the result has to be grouped by category.
3. Quantity lives in the order items table, while category lives in the products table, so those tables need to be joined.

In this article, we will define "selling best" as total units sold. That turns the business question into a very clear SQL target: join order items to products, group by category, sum quantity, and sort from highest to lowest.

The first analysis question: which category sells best?

Here is the core query:

SELECT
  p.category,
  SUM(oi.quantity) AS total_units
FROM b3_items AS oi
JOIN b3_products AS p
  ON oi.product_id = p.product_id
GROUP BY p.category
ORDER BY total_units DESC;

Nothing in that query is random. It is a direct translation of the question:

• Dimension: p.category
• Metric: SUM(oi.quantity)
• Data source: order items joined to products
• Relationship: product_id
• Result order: highest total first

One of the most common beginner mistakes in analysis is trying to jump straight to a finished answer. A steadier approach is to confirm three things first: did I choose the right tables, did I define the right dimension, and did I define the right metric? If those are correct, the SQL is usually much easier to finish.

Run a full analysis workflow in the Playground

The interactive example below continues the same ecommerce story from the first two posts. Run the default query first and see which category comes out on top. Then change the metric from SUM(quantity) to COUNT(*) and compare the meaning of the result. Those two queries sound similar, but they answer different questions.

You can keep going with questions like these:

SELECT
  c.customer_name,
  COUNT(o.order_id) AS total_orders
FROM b3_customers AS c
JOIN b3_orders AS o
  ON c.customer_id = o.customer_id
GROUP BY c.customer_name
ORDER BY total_orders DESC;

SELECT
  order_date,
  daily_sales,
  SUM(daily_sales) OVER (ORDER BY order_date) AS running_sales
FROM b3_daily_sales
ORDER BY order_date;

The first asks, "Which customers are most active?" The second asks, "How is sales accumulating over time?" They look different, but both follow the same pattern: define the metric, define the dimension, then write the query to match.

This animation makes that second idea easier to see: each row stays visible, but the running total grows as SQL moves down the ordered rows. That is exactly why window functions feel different from GROUP BY.

One small step further: ranking and running totals

Window functions can look intimidating at first, but you do not need to master everything at once. A helpful beginner definition is this: a window function calculates extra context without collapsing the current rows into one summary row.

That is exactly what the running total example does. Each date remains its own row, but SQL also calculates the cumulative sales up to that date. Aggregation changes the grain of a result. Window functions often preserve the current grain while adding a new perspective.

That distinction alone is a strong starting point for beginners.

Common beginner mistakes in SQL analysis

The first mistake is writing SQL before defining the metric. If someone asks, "Which category is best?" you still need to decide whether best means units sold, revenue, or number of orders.

The second mistake is forgetting the grain of the result. If your query groups by category, then each row describes a category-level answer. You cannot use that output to make a claim about individual products without changing the query.

The third mistake is assuming analysis must be complicated. In practice, many useful business questions start with a simple grouped query. If you can reliably answer who has the most orders, which category sold the most units, or how a metric changes day by day, you are already doing meaningful analysis.

Wrap-up: the value of SQL is in the answer, not the syntax

By now, this beginner series should feel like a progression: first understand the structure of tables, then learn how to query them, and finally use them to answer questions.

That progression matters because SQL is not really about producing a block of code that looks impressive. It is about producing answers that are clear, correct, and explainable.

If you can define the question, pick the right metric and dimension, and express that logic in SQL, you are building the skill that makes SQL useful in real work.

Related Articles

• Writing Your First Real SQL Query: From SELECT to GROUP BY for the beginner querying foundation that this article builds on.
• Mastering SQL GROUP BY: From Basics to Advanced Aggregations for a deeper look at grouped summaries once basic analysis questions start to repeat.
• Understanding Window Functions: A Practical Guide for the next analytical step after grouped summaries and running totals.

If you want to revisit the querying foundation, go back to Writing Your First Real SQL Query: From SELECT to GROUP BY.