DEV Community

Cover image for How I Started Thinking in SQL (Not Just Writing Queries)
joseph mwangi
joseph mwangi

Posted on

How I Started Thinking in SQL (Not Just Writing Queries)

When I first started learning SQL, everything felt mechanical.

  • Write a query.
  • Run it.
  • Get results. But something was missing.

I wasn’t really understanding the data, I was just retrieving it.
So I decided to go beyond the basics. Instead of stopping at simple queries, I explored how SQL can actually transform, analyze, and connect data. That shift completely changed how I approach data.

In this article, I’ll be walking you through that journey using two simple datasets I worked with:

1. a school database
2. a hospital database

Making Data Readable

(String Functions)

Raw data is rarely ready to use.

For example, student names and cities looked fine, but they weren’t consistent or presentation-ready, and that’s where string functions came in.

SELECT 
  CONCAT(UPPER(first_name), '-', UPPER(last_name)) AS full_name,
  LOWER(city) AS city
FROM students;
Enter fullscreen mode Exit fullscreen mode

FIG 1. A Screenshot showing formatted names output

Screenshot formatted names output

With a few transformations:

  • names became consistent
  • cities standardized
  • output became clean and readable

Understanding the Story Behind Numbers

Marks were just numbers in a column until I analysed using aggregate functions, and I quickly understood performance:

SELECT
  ROUND(AVG(marks), 2) AS average_marks,
  MAX(marks) AS highest_marks,
  MIN(marks) AS lowest_marks
FROM exam_results;
Enter fullscreen mode Exit fullscreen mode

FIG 2. A Screenshot showing aggregate results

Screenshot showing aggregate results

Now I could answer real questions:

  • What’s the average score?
  • Who performed best?
  • How wide is the gap?

This is where SQL started feeling like a decision-making tool, not just a query language.

Making Sense of Dates

Dates were another turning point.
Instead of just seeing 2008-03-12, I learned how to extract meaning from it that is;

  • the day someone was born
  • the month
  • the year

Then I calculated ages and suddenly, the data became more human.
FIG 3. screenshot showing days, months, and year extracted from a date

screenshot showing days, months, and year extracted from a date

Formatting exam dates into readable formats like:
Friday, 15th March 2025

made me appreciate how small transformations can greatly improve clarity.

FIG 4. A Screenshot showing formatted dates into readable formats
Screenshot showing formatted dates into readable formats

Connecting Data with Joins

Up to this point, I was working with single tables.
But real-world data is connected.

Using joins, I combined data from multiple tables in the hospital dataset:

SELECT 
  p.full_name AS patient,
  d.full_name AS doctor,
  a.diagnosis
FROM appointments a
INNER JOIN patients p ON a.patient_id = p.patient_id
INNER JOIN doctors d ON a.doctor_id = d.doctor_id;

Enter fullscreen mode Exit fullscreen mode

_FIG 5._Screenshot showing Inner_join output

Screenshot showing Inner_join output

This allowed me to see:

  • who treated whom
  • What diagnosis was given I stopped seeing tables but started seeing relationships.

Analytical part of SQL (Use of Window Functions)

This was the turning point.

Instead of just summarizing data, I started analyzing patterns, for instance, ranking students based on performance.

SELECT
student_id,
marks,
RANK() OVER (ORDER BY marks DESC) AS rank_position
FROM exam_results;

FIG 6. A Screenshot showing ranking results

Screenshot: ranking results
Now I could:

  • compare students
  • Identify top performers
  • understand performance distribution

This is where SQL moved from basic querying to real analysis.

Small Mistakes That Taught Me Big Lessons

Some of my biggest lessons from running the queries came from very small, but costly mistakes:

  1. writing Form 3 instead of Form 3
  2. forgetting commas or placing them where they shouldn’t be
  3. Referencing the wrong table name
  4. typos in column or table names (this one happened a lot)
  5. But one of the most important lessons was understanding SQL’s order of execution.

Even though we write queries starting with SELECT, SQL actually processes them in this order:

FROM ➡️WHERE➡️GROUP BY➡️HAVING ➡️SELECT➡️DISTINCT➡️ORDER BY➡️LIMIT

If you don’t follow this order, you can get wrong results, even if your query runs without errors.

A simple way to remember:

Funny Writers Group Hard Stories During Orderly Lessons

That realization changed how I debug queries, and I stopped guessing and started thinking step by step.

Want to Explore the Full Work?

Instead of listing every query here, I’ve shared the full scripts on GitHub so you can follow along:
github link

Final Thoughts

At the beginning, SQL felt like something I had to learn. Now, it feels like something I use to think.I no longer just ask:

“What query should I write?”

I ask:

What is this data trying to tell me?”

That shift made all the difference.

If you're learning SQL, don’t stop at writing queries but focus on understanding the data behind them. Because that’s where the real value is.

Top comments (0)