Modupe Esther Popoola,MCIB’s Post

If you have ever been confused about SQL JOINS, this visual breakdown will clear everything up. INNER JOIN Only records with matching values in both tables. Think of it as the intersection. LEFT JOIN All records from the left table + matching records from the right table. Left table is complete, right table is partial. LEFT JOIN with NULL Check Only records from the left table that have NO match in the right table. Great for finding orphaned data. RIGHT JOIN All records from the right table + matching records from the left table. Mirror image of LEFT JOIN. RIGHT JOIN with NULL Check Only records from the right table that have NO match in the left table. FULL OUTER JOIN Everything from both tables. Records match when possible, NULL when no match exists. FULL OUTER JOIN with NULL Check Only records that do NOT have a match in either table. Find disconnected data. Pro tip: Most real-world queries use INNER JOIN and LEFT JOIN. The others are less common but powerful when you need them. The mistake I made: I used to write complex WHERE clauses to filter data when a simple JOIN type would do the job. Understanding JOIN types saves you from writing unnecessary logic. Which JOIN type confused you the most when learning SQL? Drop it below! #SQL #Database #BackendDevelopment #Programming #DataEngineering #SoftwareDevelopment

SQL Cheat Sheet👇 SQL isn’t just about writing queries it’s about understanding how they execute. Every query follows a flow: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT This means data is first picked, then filtered, grouped, and only at the end selected and sorted. Once you understand this sequence along with basics like JOINs and aggregations, your queries become more accurate and efficient. #SQL #DataAnalytics #DataEngineering #Learning #TechSkills

SQL looked simple to me at first, just a few commands like SELECT, WHERE, and JOIN. However I realised how deep it actually is. The more I explore, the more ways I see to structure and retrieve data depending on the problem. It’s the kind of skill that never really loses its value with practice. It feels like something that never really gets old, no matter how much you practice. #SQL #DataSkills

🚀 Day 13/30 – Subqueries in SQL Ever felt your SQL queries are getting messy? 🤯 👉 That’s where subqueries come in. 💡 Think of it like this: Solve a small problem first → use that result to solve the bigger one. 🔥 What I learned today: ✔ Subquery runs inside the main query ✔ Helps in dynamic filtering ✔ Makes complex logic simple & clean 🧠 3 Types you must know: 🔹 Scalar → single value 🔹 Nested → multiple values 🔹 Correlated → runs for each row ⚡ Real insight: If you understand subqueries well, you’ll write SQL like a pro analyst 💻 📌 Consistency > Perfection Day by day, getting better 🚀 #SQL #DataAnalytics #LearnSQL #LinkedInLearning

🌳 SQL Practice Series | Problem # 1 Binary Search Tree Node Classification I've been doing consistent SQL practice lately as part of my data analytics journey, and this one made me think. The challenge: given a BST table with nodes (N) and their parents (P), classify every node as Root, Inner, or Leaf using pure SQL. The logic breaks down simply: → Root: P is NULL no one is above it → Leaf: no other node lists it as a parent → Inner: has both a parent and children My Solution: NOT EXISTS with a correlated subquery checks whether any row references the current node as a parent. If none do it's a Leaf. Clean, readable, and it works on any size tree. How would you solve this differently? Would you go with a JOIN, a subquery, or something else entirely? Drop your approach in the comments I'd love to see different ways to think about it! #SQL#SQLPractice#DataAnalytics#HackerRank#LeetCode#DataEngineering#TechInterview#100DaysOfCode#MTSU

A SQL feature I don’t see used often: LATERAL (but very useful) While exploring some advanced SQL patterns, I came across LATERAL. It’s simple in idea, but powerful when dealing with row-wise logic. 🔹 What it does LATERAL lets a subquery refer to columns from the current row of the main query. 🔹 Example use case Get the latest order for each customer: SELECT c.customer_id, o.order_id, o.order_date FROM customers c CROSS APPLY ( SELECT order_id, order_date FROM orders o WHERE o.customer_id = c.customer_id ORDER BY order_date DESC FETCH FIRST 1 ROW ONLY ) o; 🔹 Why not a normal join? We can solve this using analytic functions or joins, but LATERAL makes it more direct for row-by-row dependent queries. 💡 What I found useful It simplifies queries where the inner logic depends on each row of the outer query — especially for “top N per group” type problems. Still exploring more use cases — Have you used LATERAL in your queries? #OracleSQL #SQL #DataEngineering #AdvancedSQL #DatabaseDevelopment

SQL does not run in the way you write it. It runs in its own hidden way 🚨 Most Developers Get This WRONG About SQL 🚨 You write: "SELECT * FROM table WHERE condition GROUP BY column…" 👉 The actual execution order is completely different: 1️⃣ FROM / JOIN 2️⃣ WHERE 3️⃣ GROUP BY 4️⃣ HAVING 5️⃣ SELECT 6️⃣ DISTINCT 7️⃣ ORDER BY 8️⃣ LIMIT / OFFSET 💡 This is why: - You can’t use aliases in WHERE - HAVING works on aggregated data, not WHERE - Performance issues happen when filtering is misplaced Understanding this changed how I write queries forever. Stop memorizing syntax. Start thinking like the SQL engine. 🎯 Next time your query behaves weirdly, ask yourself: “Am I writing this in the way SQL actually executes it?” #sql #Database #RelationalDatabase #dataengineering #sqlqueries #sqlinterviewpreparation #SoftwareEngineering #sqlinterview #NoSqlDatabase #dataset #LearnWithGaneshBankar

SQL Mistake #3: Tiny errors… BIG impact 😭 Today I learned how 2 small mistakes completely broke my SQL query 👇 ❌ Mistake 1: Trailing comma before FROM sum(case when state='approved' then amount else 0 end) as approved_total_amount, FROM Transactions 👉 That extra comma made SQL expect another column… and instead it found FROM 💀 ❌ Mistake 2: COUNT with ELSE 0 COUNT(CASE WHEN state = 'approved' THEN 1 ELSE 0 END) 👉 I thought I was counting only approved rows… But: COUNT() counts non-NULL values 0 is NOT NULL 😭 → So it counted ALL rows ✅ Fix: COUNT(CASE WHEN state = 'approved' THEN 1 END) sum(case when state='approved' then amount else 0 end) as approved_total_amount FROM Transactions 💡 Lessons I’ll never forget: Don’t put a comma after the last column COUNT ignores NULL, not 0 These mistakes didn’t test my SQL knowledge… They tested my attention to detail. Documenting my SQL mistakes daily so I never repeat them again 🚀 #SQL #DataAnalytics #LearningInPublic #MistakesToMastery #100DaysOfSQL

Day 27 of my SQL Night Learning Journey 🌙 Today, I learned about the SELECT INTO statement, and it made things feel a lot more practical. In simple terms, SELECT INTO helps you create a new table from an existing one while copying the data into it at the same time. Think of it like: “Take this table, duplicate it, and save it as a new one.” This is especially useful when: You want to create a backup of your data You need a temporary table to run the analysis without touching the original data One important thing I learned: The new table copies the columns and data types, but it does NOT automatically include things like: Primary keys Indexes NOT NULL constraints So it’s not a perfect clone, but it gets the job done for most use cases. A simple example that stood out to me: Creating a backup of a table by copying everything into a new one. Little by little, SQL is starting to feel less intimidating and more like a tool I can actually use 🛠️ #SQL #LearningInPublic #DataAnalytics #BeginnerFriendly #TechJourney #Consistency #WomenInTech

⚡ SQL Days 27 & 28: Subquery Mastery These two days focused on moving from basic syntax to advanced logic building, learning to break complex problems into nested steps. 🧠 Logic Flow Inner Query: Runs first to find a specific value (e.g., the average price). Outer Query: Uses that value to filter the final results. 🛠️ The 3 Essential Types Single-Row: Returns one value. Use with =, >, <. Multi-Row: Returns a list. Use with IN, ANY, or ALL. Correlated: Runs once for every row in the outer query. Powerful for row-by-row comparisons but can be slower. 💡 Key Takeaways Performance: If a subquery is too slow, consider using a JOIN. Inside-Out: Always test the inner query first to ensure the data types match. Day 29 Loading... #SQLJourney #Subqueries #DataLogic #SQLTips