Forem: Wahu Elizabeth

Understanding Subqueries vs CTEs in SQL (With Examples)

Wahu Elizabeth — Wed, 22 Apr 2026 10:34:02 +0000

When working with SQL, especially in data analysis, you’ll often need to break down complex queries into manageable pieces. Two powerful tools that help with this are subqueries and Common Table Expressions (CTEs).

This article explains what they are, how they differ, and when to use each—using clear examples.

What is a Subquery?

A subquery is simply a query nested inside another SQL query. It runs first and passes its result to the outer query.
Example:

SELECT name
FROM employees
WHERE salary > (
 SELECT AVG(salary)
 FROM employees
 );

What’s happening here?

The inner query calculates the average salary
The outer query returns employees earning above that average

Types of Subqueries

1. Scalar Subquery
Returns a single value.

 SELECT name
 FROM employees
 WHERE salary > (SELECT AVG(salary) FROM employees);

2. Row Subquery
Returns a single row.

 SELECT *
 FROM employees
 WHERE (department_id, salary) = (
 SELECT department_id, MAX(salary)
 FROM employees
);

3. Column Subquery
Returns a single column.

SELECT name
FROM employees
WHERE department_id IN (
SELECT id FROM departments
 );

4. Correlated Subquery
Depends on the outer query and runs repeatedly.

SELECT name
FROM employees e1
WHERE salary > (
  SELECT AVG(salary)
  FROM employees e2
  WHERE e1.department_id = e2.department_id
  );

When Should We Use Subqueries?
Subqueries are useful when:

You need a quick, one-time calculation.
The logic is simple and doesn’t need reuse.
You want to filter data based on aggregated values.

However, they can become hard to read and slow when nested deeply.

What are CTEs (Common Table Expressions)?

A CTE is a temporary result set defined at the start of a query using the WITH keyword. It acts like a named query you can reference later.
Example:

 WITH avg_salary AS (
   SELECT AVG(salary) AS avg_sal
   FROM employees
 )
SELECT name
FROM employees, avg_salary
WHERE employees.salary > avg_salary.avg_sal;

Types and Use Cases of CTEs

1. Simple CTE
Used to simplify complex queries.

WITH high_earners AS (
     SELECT name, salary
     FROM employees
     WHERE salary > 50000
  )
SELECT * FROM high_earners;

2. Recursive CTE
Used for hierarchical data (e.g., organizational charts).

WITH RECURSIVE employee_hierarchy AS (
  SELECT id, name, manager_id
  FROM employees
  WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.manager_id
  FROM employees e
  INNER JOIN employee_hierarchy eh
  ON e.manager_id = eh.id
  )
  SELECT * FROM employee_hierarchy;

3. Multiple CTEs
You can define multiple CTEs in one query.

WITH dept_avg AS (
    SELECT department_id, AVG(salary) avg_sal
    FROM employees
    GROUP BY department_id
),
filtered AS (
    SELECT e.name, e.salary, e.department_id
    FROM employees e
    JOIN dept_avg d
    ON e.department_id = d.department_id
    WHERE e.salary > d.avg_sal
    )
    SELECT * FROM filtered;

When Should You Use CTEs?

CTEs are ideal when:

Your query is complex and needs structure
You want to reuse logic
You need better readability and debugging
You’re working with hierarchical data (recursion)

Subqueries vs CTEs: Key Comparison

Which One Should You Use?

Use subqueries when:

The query is simple
You only need a quick filter or calculation

Use CTEs when:

The query is complex
You want cleaner, more maintainable code
You need recursion or multiple steps

Final Thoughts
Both subqueries and CTEs are essential SQL tools. The choice between them often comes down to clarity vs simplicity.

If your query is growing complicated or hard to read, that’s usually a sign you should switch to a CTE.

Still learning...

From Scratch to Queries: Building a School Database with SQL – My Nairobi Academy Project.

Wahu Elizabeth — Tue, 14 Apr 2026 15:06:44 +0000

Transitioning from viewing data as simple lists to managing it within a relational database is a milestone for any developer. This week, I took on the task of building a foundational system for** Nairobi Academy**. The goal was to move beyond theory and implement a functional database that tracks students, courses, and enrollments.

Here is a breakdown of the SQL fundamentals used to bring this project to life.

Understanding the Language: DDL vs. DML
Before writing a single line of code, it is essential to distinguish between the two primary "modes" of SQL:

DDL (Data Definition Language): Think of this as the blueprint phase. DDL commands define the structure of the database. When you create a table or change its columns, you are using DDL.

DML (Data Manipulation Language): This is the action phase. Once the structure exists, DML allows you to interact with the actual data—adding new students, updating grades, or removing records.

The Difference: DDL changes the container (the table), while DML changes the content (the rows).

Building the Framework: CREATE, INSERT, UPDATE, and DELETE
In the Nairobi Academy project, these four commands formed the core lifecycle of our data:

CREATE: I used this DDL command to establish our tables. For example, creating the Students table required defining data types like INT for IDs and VARCHAR for names.

INSERT: Once the tables were ready, I populated them with student records and course details. This is where the database actually starts to look like a school roster.

UPDATE: Data is rarely static. When a student changed their contact information or a course name was adjusted, UPDATE allowed me to modify existing rows without deleting them.

DELETE: This was used to remove records that were no longer relevant, such as a student who withdrew from a specific semester.

Precision with the WHERE Clause
A database with thousands of rows is useless if you can't find exactly what you need. The WHERE clause is the ultimate filter. During the project, I utilized several operators to refine my queries:

= and >: Used for direct matches or finding students above a certain age.

BETWEEN: Perfect for finding enrollments within a specific date range.

IN: Allowed me to filter students belonging to a specific list of departments (e.g., 'Science', 'Arts').

LIKE: A powerful tool for pattern matching, such as finding all students whose names start with "J" using LIKE 'J%'.

Transformation with CASE WHEN
One of the most interesting parts of the assignment was using the CASE WHEN statement. This functions like "if-then" logic within a query. Instead of just pulling raw numbers, I used it to transform data on the fly.

For example, I used CASE WHEN to categorize student marks:

If a score was above 80, the query returned 'Distinction'.

If it was between 60 and 79, it returned 'Pass'.

This allows the database to provide meaningful insights rather than just raw data points.

Reflection: Challenges and Wins
This week was an eye-opener. The most challenging aspect was ensuring "Referential Integrity"—making sure I didn't delete a student who was still enrolled in a course, which would cause a conflict in the database.

The most interesting part? Seeing how a few lines of SQL can transform a massive pile of disorganized information into a structured, searchable system. Building the Nairobi Academy project made the abstract concept of "data" feel tangible and manageable.

Next step: Mastering Joins to connect these tables even more deeply.

I really enjoyed this.

My First Experience Using Excel for Real-World Data Analysis.

Wahu Elizabeth — Thu, 26 Mar 2026 16:13:39 +0000

Before starting this project, I honestly knew almost nothing about Excel. I had heard about it, seen people use it, but I never really understood how powerful it is. As just a girl trying to figure things out, I was honestly a bit nervous and overwhelmed at first. But at the same time, I was open to learning and ready to take on the challenge. Like many beginners, I saw it as just a tool for storing data in rows and columns. However, through hands-on practice, I quickly realized that Excel is far more powerful—it is a complete data analysis tool used by professionals across industries.

This article shares how Excel is applied in real-world data analysis, based on my experience building a product performance dashboard.

What is Excel?
Microsoft Excel is a tool used to organize, clean, analyze, and present data. It works using rows and columns, and it has features like formulas, PivotTables, charts, and slicers that help turn raw data into meaningful information. Even in 2026, Excel remains one of the most widely used tools for data analysis due to its accessibility and versatility

At first, it looked complicated—but as I started using it, I slowly began to understand how everything connects.

🌍 Real-World Use

I learned that Excel is used almost everywhere—in business, marketing, finance, and even e-commerce. For example, a company like Jumia can use Excel to analyze:

Product prices
Discounts
Customer reviews
Ratings

This helps them make decisions like:
Which products to promote
Whether to increase or reduce prices
Which products need improvement

Seeing this made me realise that Excel is not just about numbers—it actually helps businesses grow.

🛠️ What I Learned (As a Beginner)

Even though I started from zero, I managed to learn and use several important Excel tools:

🔹 Data Cleaning
This was one of the hardest parts at first, but also the most important.
I used:
Text to Columns
Find & Replace
Functions like LEFT(), VALUE(), and ABS()
This helped me:
Remove “KSh” and commas
Convert text into numbers
Fix negative review values
Extract ratings from text

🔹 Data Enrichment
I created new columns using formulas:
Discount Amount
Rating Category (Poor, Average, Excellent)
Discount Category (Low, Medium, High)
At first, formulas looked scary—but once I understood them, they became really useful.

🔹 PivotTables
This was honestly one of the most powerful tools I learned. It made analyzing data much faster and easier.
I used PivotTables to:
Find averages
Identify top products
Group data into categories

🔹 Charts & Visuals
I created:
Bar charts for top products
Donut charts for categories
Scatter plots to see relationships
This is where everything started to make sense visually.

🔹 Slicers & Interactivity
This part felt really cool 😄
I added slicers so the dashboard can filter data instantly.
It made everything interactive and more professional.

🔹 Conditional Formatting
I used colors to highlight:
High discounts (green)
Low ratings (red)
This made important insights easy to spot.

💡 Personal Reflection

This experience completely changed how I see data.
At the beginning, I was confused and honestly a bit stressed because everything felt new. But as I kept practicing, I started understanding patterns and relationships.
Now I can look at data and think:
Why is this happening?
What does this mean?
What decision can be made from this?

For example, I noticed that:
Medium discounts sometimes have better ratings
High discounts don’t always mean more reviews

That really surprised me.

I’m still a beginner, and I know I have a lot to learn but now I feel more confident. This is just the start of my journey into data analysis, and I’m excited to keep improving.