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. 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 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 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. Dates were another turning point. 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 Up to this point, I was working with single tables. 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. This was the turning point. Instead of just summarizing data, I started analyzing patterns, for instance, ranking students based on performance. SELECT 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. 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. 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. Instead of listing every query here, I’ve shared the full scripts on GitHub so you can follow along: github link 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.