SQL Practice: Binary Search Tree Node Classification

SQL Performance — What I Learned After Fixing a Slow Query In my previous post, I shared how a query that looked correct was actually slow. This time, I focused on what actually improved performance. The difference was not syntax. It was how much data I was processing What I changed: Applied filters early Instead of filtering at the end, I reduced data at the source Avoided SELECT * Only selected required columns Aggregated before JOIN Reduced row count before combining tables Checked execution plan Identified where most time was being spent What surprised me: The query logic didn’t change much. But performance improved significantly. Key insight: In SQL: Performance = Data scanned + Data shuffled Not just query correctness Takeaway: If your query is slow: Don’t focus only on writing correct SQL Focus on reducing the data early #SQL #DataAnalytics #DataEngineering  #QueryOptimization #BigData  #AnalyticsEngineering #SQLPerformance

SQL is the language of data, but are you using its "hidden" logic? 🔍 Writing queries is one thing; understanding the engine is another. Here are 4 things about SQL that changed how I think about data: - The Execution Order Lie: We write SELECT first, but SQL executes it almost last. It starts with FROM and WHERE. This is why you can’t use a column alias in your filter—the engine hasn't "seen" the alias yet! - The NULL Trap: In SQL, NULL = NULL is False (technically Unknown). NULL is a state, not a value. If you use NOT IN on a list containing a NULL, your whole query might return zero results. - SARGable Queries: If you use a function on a column in your WHERE clause (like WHERE YEAR(date) = 2025), you might be killing your performance. It prevents the database from using indexes. Use a date range instead. - Window Functions > Group By: SUM() OVER() is often more powerful than a standard GROUP BY. It allows you to keep your row-level detail while adding aggregate context in the same view. SQL isn't just about getting the data; it’s about getting it efficiently. 🚀 What’s one SQL "gotcha" that caught you off guard when you first started? ⬇️ #SQL #DataAnalytics #DataEngineering #CodingTips #Database #PowerBI

SQL Execution Order (not how we write it, but how it actually runs) Most of us write queries like this: SELECT → FROM → WHERE → GROUP BY → ORDER BY But internally, SQL processes it very differently. SQL executes in this order: FROM JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY LIMIT Here’s a simpler way to think about it FILTER → SHOW → SORT → LIMIT What this actually means • FILTER → FROM, JOIN, WHERE, GROUP BY, HAVING (Define data + reduce it step by step) • SHOW → SELECT, DISTINCT (Choose what you want to display) • SORT → ORDER BY (Organize the result) • LIMIT → LIMIT / TOP (Control how much data you return) Once we start thinking in execution order, we stop “trial and error” and start writing SQL with confidence. If you’re working with SQL daily, this mental model makes a huge difference. #SQL #DataAnalytics #LearnSQL #SQLTips #DataEngineering #Analytics

DAY 46 — Lessons Learned Using SQL in Real Projects After working with SQL across multiple datasets, here are key lessons: 1️⃣ Always start with the business question 2️⃣ Keep queries simple and readable 3️⃣ Validate results at every step 4️⃣ Understand your joins deeply 5️⃣ Document your logic SQL is not just a technical skill. It is a thinking process. The goal is not to write complex queries. It is to produce reliable, meaningful insights. #ShinaAwopejuBusinessAnalysisJourneyWith10alytics #BusinessAnalysisWith10alytics #DataAnalysis #SQL

Understanding the difference between WHERE and HAVING is key to writing efficient SQL queries—filter early, aggregate smartly, and analyze better. #DataAnalytics #SQL #BusinessIntelligence #DataAnalyst #AnalyticsLearning #DataScience #SQLQueries

I wrote a SQL query to filter high-revenue countries… and it failed. The logic looked correct. But SQL threw an error. Here’s what I tried: 👉 Filtering total revenue using WHERE Something like: WHERE SUM(order_total) > 10000 And SQL didn’t accept it. That’s when I realized: 👉 I was filtering at the wrong stage of the query. In SQL, execution doesn’t happen the way we read the query. It actually works like this: FROM WHERE GROUP BY HAVING SELECT ORDER BY 💥 The mistake: WHERE runs before aggregation So it can’t use functions like SUM(), COUNT(), etc. ✅ The fix: Use HAVING for aggregated conditions: 👉 HAVING SUM(order_total) > 10000 💡 What I learned: WHERE filters rows HAVING filters grouped results Sounds simple… but easy to mess up in real queries. Now I think of it like this: 👉 WHERE → “filter raw data” 👉 HAVING → “filter summarized data” 📌 Lesson: If your query involves aggregation and filtering… Always ask: 👉 Am I filtering before grouping or after? This small distinction can save you from a lot of confusion. #SQL #DataEngineering #SQLTips #Analytics #LearnSQL #DataAnalytics #QueryOptimization #TechLearning #Debugging

This SQL question looks easy until you try to solve it I recently worked on an interesting problem: “Flag customers whose orders increase every month this year.” At first, it seems straightforward, but the real challenge lies in the logic. The goal is not just to find any increase, but to ensure consistent month over month growth. The key idea is to compare each month with the previous one and then verify that all comparisons show an increase. The core condition looks like this: HAVING COUNT(*) = COUNT(CASE WHEN cnt > prev_cnt THEN 1 END) This ensures that every month passes the increase check with no drops or exceptions. What I practiced through this: - Using DATE_TRUNC for monthly aggregation - Applying LAG for time based comparison - Writing conditional logic with HAVING - Focusing on logical correctness, not just working queries - You can find the full breakdown with sample data and outputs below I would be interested to know how others would approach this problem. #SQL #DataAnalytics #LearningInPublic #InterviewPrep

✅ Solved a SQL problem on StrataScratch — Day 54 of my SQL Journey 💪 User activity looks simple… until you try to measure it correctly ⏱️ Today’s problem was about calculating average session time — But sessions weren’t explicitly given. They had to be built from events. The approach: • Identified session boundaries using page_load and page_exit • Used MIN() and MAX() with CASE WHEN to capture valid timestamps • Calculated session duration using TIMESTAMPDIFF() • Filtered out invalid sessions (where load happens after exit) • Averaged session time per user What I practised: • Event-based session reconstruction • Conditional aggregation using CASE WHEN • Time difference calculations in SQL • Data cleaning before aggregation What stood out — Metrics don’t exist in raw data. You have to build them. A “session” isn’t stored anywhere… It’s something you define from behaviour. That’s where analysis actually begins. Consistent learning, one query at a time 🚀 #SQL #StrataScratch #DataAnalytics #LearningInPublic #SQLPractice

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 "GROUP BY" Trap: Why your query is throwing an error? 🛑📊 One of the most common hurdles in SQL isn’t just writing the query—it’s understanding the logic behind grouping data. Have you ever tried to SELECT a column alongside a SUM() or COUNT() and got a "not a GROUP BY expression" error? The Golden Rule: If a column is not inside an aggregate function (like SUM, AVG, COUNT), it MUST be included in the GROUP BY clause. Think of it this way: If you ask for the total sales (SUM) per "Region", the database creates one bucket for each region. If you also try to select "Customer Name" without grouping it, the database gets confused: "Which specific customer should I show for this entire region's total?" Key Takeaways for Clean Queries: ✅ GROUP BY: Defines your "buckets" (e.g., Department, Year, Category). ✅ WHERE: Filters individual rows before they are grouped. ✅ HAVING: Filters the groups after the math is done. Understanding this distinction is the bridge between just "writing code" and truly performing data analysis. #SQL #DataAnalytics #Database #CodingTips #SQLDeveloper #TechCommunity #SQLProgramming