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;
FIG 1. A Screenshot showing 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;
FIG 2. A 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
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

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;
_FIG 5._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
- 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:
- writing Form 3 instead of Form 3
- forgetting commas or placing them where they shouldn’t be
- Referencing the wrong table name
- typos in column or table names (this one happened a lot)
- 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)