Fixing Ambiguous SQL Query for Latest Product Review

One SQL mistake that can silently break your results: 👉 NOT IN vs NOT EXISTS Looks similar. But behaves very differently. Example: SELECT * FROM orders WHERE customer_id NOT IN (SELECT customer_id FROM customers); 💡 Seems correct, right? But here’s the problem 👇 👉 If the subquery contains even one NULL → The entire result becomes empty ❌ You get no rows Even when data exists 💡 Why? SQL doesn’t know how to compare NULL → Result becomes UNKNOWN 💡 Better approach: SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE o.customer_id = c.customer_id ); 👉 NOT EXISTS handles NULLs safely 💡 Real-world impact: Missing data in reports Incorrect filtering Hard-to-debug issues Lesson: 👉 Similar-looking queries ≠ same behavior 👉 Always think about NULLs If you understand this, you’re already ahead of many developers. Follow for more practical SQL insights. 🙂 #SQL #DataEngineering #Learning #Analytics

THIS QUERY LOOKS CORRECT. IT IS NOT. It runs. It returns numbers. But every metric is misleading. Business problem: Calculate the following metrics per region: - Total tickets - Resolved tickets - Resolution rate (%) - On-time resolution rate (%) (within 24 hours) - Average resolution time (hours) - Quality score (%) based on feedback Tables involved: tickets - ticket_id - customer_id - team_id - created_time - resolved_time customers - customer_id - region feedback - feedback_id - ticket_id - rating - feedback_time Conditions: - A ticket is considered resolved if resolved_time is not null - SLA = resolution within 24 hours from created_time - On-time % should be calculated only on resolved tickets - Each ticket can have multiple feedback entries - Only the latest feedback per ticket should be considered - Customers can change regions over time At first glance, this looks like simple aggregation. But real data breaks this logic: - Joins silently create duplicates - Percentages use the wrong denominator - Unresolved tickets distort averages - Feedback inflates counts - Region may not reflect historical state So even if your query runs, your metrics are lying. Comment the correct query. Repost if this made you think. Follow for real-world data problems. #DataRejected #SQL #DataEngineering #Analytics #DataScience #BusinessMetrics #CodingPractice

💻 𝐘𝐨𝐮𝐫 𝐒𝐐𝐋 𝐐𝐮𝐞𝐫𝐲 𝐖𝐨𝐫𝐤𝐬…  𝐁𝐮𝐭 𝐘𝐨𝐮𝐫 𝐋𝐨𝐠𝐢𝐜 𝐌𝐢𝐠𝐡𝐭 𝐁𝐞 𝐖𝐫𝐨𝐧𝐠 👀 Most SQL queries don’t fail. They run. They return results. And that’s exactly where the problem begins. 💡 𝐎𝐧𝐞 𝐨𝐟 𝐭𝐡𝐞 𝐦𝐨𝐬𝐭 𝐢𝐠𝐧𝐨𝐫𝐞𝐝 𝐦𝐢𝐬𝐭𝐚𝐤𝐞𝐬 𝐢𝐧 𝐒𝐐𝐋: 👉 𝗙𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴 𝗮𝘁 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝘀𝘁𝗮𝗴𝗲 🔍 You want to find customers who spent more than 10,000. 𝙎𝙤 𝙮𝙤𝙪 𝙬𝙧𝙞𝙩𝙚: 𝗦𝗘𝗟𝗘𝗖𝗧 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿_𝗶𝗱, 𝗦𝗨𝗠(𝗮𝗺𝗼𝘂𝗻𝘁) 𝗙𝗥𝗢𝗠 𝗼𝗿𝗱𝗲𝗿𝘀 𝗪𝗛𝗘𝗥𝗘 𝗮𝗺𝗼𝘂𝗻𝘁 > 𝟭𝟬𝟬𝟬𝟬 𝗚𝗥𝗢𝗨𝗣 𝗕𝗬 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿_𝗶𝗱; Looks correct… but it’s not ❌ 🧠 What’s going wrong? You filtered data before aggregation 𝗪𝗵𝗶𝗰𝗵 𝗺𝗲𝗮𝗻𝘀: • Smaller transactions are ignored • Total spend becomes inaccurate ✅ 𝙏𝙝𝙚 𝙘𝙤𝙧𝙧𝙚𝙘𝙩 𝙬𝙖𝙮: 𝗦𝗘𝗟𝗘𝗖𝗧 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿_𝗶𝗱, 𝗦𝗨𝗠(𝗮𝗺𝗼𝘂𝗻𝘁) 𝗔𝗦 𝘁𝗼𝘁𝗮𝗹_𝘀𝗽𝗲𝗻𝘁 𝗙𝗥𝗢𝗠 𝗼𝗿𝗱𝗲𝗿𝘀 𝗚𝗥𝗢𝗨𝗣 𝗕𝗬 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿_𝗶𝗱 𝗛𝗔𝗩𝗜𝗡𝗚 𝗦𝗨𝗠(𝗮𝗺𝗼𝘂𝗻𝘁) > 𝟭𝟬𝟬𝟬𝟬; 📉 The scary part? • Your query runs perfectly • No errors at all • But your insights are completely wrong 🚀𝗥𝗲𝗮𝗹 𝗹𝗲𝘀𝘀𝗼𝗻: - WHERE filters rows - HAVING filters aggregated results Understanding when to use them matters more than just knowing how 💬 Most SQL mistakes don’t break your query… They break your logic. #SQL #DataAnalytics #DataAnalyst #LearningSQL #TechCareers #DataThinking 🚀

Most SQL mistakes don’t come from syntax.They come from not understanding the data. One thing I learned early while working on customer datasets at scale: Before writing ANY complex SQL… I always spend 5 to 10 minutes just understanding the data. Here’s my quick checklist: 👉 SELECT COUNT(*) → How big is the dataset? 👉 SELECT COUNT(DISTINCT customer_id) → Unique entities 👉 GROUP BY key columns → Any unexpected duplicates? 👉 WHERE column IS NULL → Missing data check 👉 LIMIT 10 → Sanity check rows It sounds basic, but this habit has saved me from: • incorrect aggregations • duplicate joins • wrong business conclusions • and painfully long debugging sessions In real-world analytics, wrong insights are worse than no insights. Clean thinking > complex queries. Curious , what’s one SQL habit that saved you time? #SQL #DataAnalytics #DataScienceTips #AnalyticsLife #DataEngineering #LearnSQL #WomenInTech #DataCareer

THIS QUERY LOOKS CORRECT. IT IS NOT. It runs. It returns clean percentages. But the logic is WRONG. Business problem: Calculate per team: - Resolution rate (%) - On-time resolution rate (%) (within 24h SLA) - Quality score (%) based on feedback Tables involved: tickets - ticket_id - team_id - created_time - resolved_time feedback - feedback_id - ticket_id - rating - feedback_time At first glance, this looks simple. But real data breaks this logic: - Unresolved tickets are included in calculations - SLA is applied incorrectly - Multiple feedback rows inflate quality score - Latest feedback per ticket is not considered So even if your query runs, your numbers are misleading. Think before answering: Are you using the right denominator? Are you counting only resolved tickets? Are duplicates affecting your results? Fix the logic, not just the syntax. Comment your answer. Repost if this made you think. Follow for real-world SQL problems. Subscribe to practice on our platform. #DataRejected #SQL #DataEngineering #Analytics #DataScience #InterviewPrep #CodingPractice #BusinessLogic

STOP using DISTINCT blindly. You’re losing control over your data. 🔹 Duplicates sneak into your data more often than you think: 👉 joins gone wrong 👉late-arriving data 👉retries in pipelines 👉messy ingestion 🔹 Most people fix it like this: SELECT DISTINCT id, name, city FROM customers; It works… But it’s also the least controlled approach. ✅ Here are 3 ways to remove duplicates in SQL: 1. ROW_NUMBER() (Best Way) full control over which row stays lets you keep latest / priority records production-safe 2. DISTINCT (Quick Fix) simple and fast removes exact duplicates ⚠️ no control over which row survives 3. GROUP BY (Same as DISTINCT) does the same job more verbose rarely needed for deduplication 🎯 REAL TAKEAWAY All 3 give the same result. But only one gives control. If you care about data correctness, use ROW_NUMBER() — not luck. 🔥 WHY THIS MATTERS Choosing the wrong method can: hide data issues break downstream reports silently corrupt logic And the worst part? You won’t notice until it’s too late. Which one do you use most in your projects? 🤔 #SQL #DataEngineering #AnalyticsEngineering #DataEngineer #ETL #Databricks #BigData

Salam! Window functions changed how I think about data quality. I used to spot duplicates by writing messy self-joins. I'd catch outliers with manual queries. It was time consuming and inefficient. Then I learned window functions. Now I use ROW_NUMBER() to deduplicate cleanly: SELECT order_id, customer_id, amount, created_at FROM (   SELECT      order_id,     customer_id,     amount,     created_at,     ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC) as row_num   FROM orders ) ranked WHERE row_num = 1; One pass. No self-joins. No mistakes. LAG() and LEAD() help me spot outliers: sudden spikes in order volume, unexpected gaps in transaction history, values that don't make sense compared to the row before or after. RANK() and DENSE_RANK() help me find the top customers by spend, without losing track of ties. But here's what I didn't expect: better queries didn't just make me faster. They made my data more trustworthy. Because when stakeholders ask "how did you get that number?", I can explain it cleanly. No "well, I joined the table to itself and then filtered out the nulls and then..." Window functions aren't just a SQL trick. They're a trust mechanism. What's one SQL feature you didn't appreciate until you really needed it? #DataEngineering #SQL #WindowFunctions #DataQuality #AnalyticsEngineering Wasalam!

📊 𝐂𝐎𝐔𝐍𝐓 𝐢𝐧 𝐒𝐐𝐋: 𝐒𝐦𝐚𝐥𝐥 𝐃𝐞𝐭𝐚𝐢𝐥, 𝐁𝐢𝐠 𝐈𝐦𝐩𝐚𝐜𝐭 Counting seems like the easiest operation in SQL. But this is exactly where many analyses quietly go wrong. 𝐂𝐎𝐔𝐍𝐓(*) 𝐜𝐨𝐮𝐧𝐭𝐬 𝐚𝐥𝐥 𝐫𝐨𝐰𝐬. 𝐂𝐎𝐔𝐍𝐓(𝐜𝐨𝐥𝐮𝐦𝐧) 𝐜𝐨𝐮𝐧𝐭𝐬 𝐨𝐧𝐥𝐲 𝐧𝐨𝐧-𝐍𝐔𝐋𝐋 𝐯𝐚𝐥𝐮𝐞𝐬. At first, the difference feels small. In real data, it’s not. 💡𝐖𝐡𝐚𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐡𝐚𝐩𝐩𝐞𝐧𝐬? In most datasets, missing values (NULLs) are common. When you use COUNT(column), SQL automatically ignores those NULLs. • You’re no longer counting rows. • You’re counting available values. And that difference matters more than it seems. ⚠️𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐜𝐫𝐞𝐚𝐭𝐞𝐬 𝐩𝐫𝐨𝐛𝐥𝐞𝐦𝐬 • KPIs get undercounted • Conversion rates become inaccurate • Data completeness is misunderstood 𝐄𝐱𝐚𝐦𝐩𝐥𝐞: If 100 users exist but only 80 have values, COUNT(column) = 80 👉 It may look like only 80 records exist — but that’s not true. 🚀𝐖𝐡𝐚𝐭 𝐚 𝐠𝐨𝐨𝐝 𝐚𝐧𝐚𝐥𝐲𝐬𝐭 𝐝𝐨𝐞𝐬 • Understands the data before counting • Checks for NULL values explicitly • Chooses COUNT logic based on the problem #SQL #DataAnalytics #DataAnalyst #LearningSQL #SQLConcepts #DataCleaning

THIS QUERY LOOKS CORRECT. IT IS NOT. It runs. It returns numbers. But every metric is misleading. Business problem: Calculate per team: - Total tickets - Resolved tickets - Resolution rate (%) - On-time resolution rate (%) (within 24 hours) - Average resolution time (hours) - Quality score (%) based on feedback Tables involved: tickets - ticket_id - team_id - created_time - resolved_time feedback - feedback_id - ticket_id - rating - feedback_time At first glance, this looks like simple aggregation. But real data breaks this logic: - One ticket can have multiple feedback entries - Joins inflate counts silently - On-time % should be based only on resolved tickets - Average resolution time should exclude unresolved tickets - Quality % should use only the latest feedback per ticket So even if your query runs, your metrics are lying. Think before answering: Are you counting tickets… or counting duplicated rows? Are your percentages using the correct denominator? Fix the logic, not just the syntax. Comment your answer. Repost if this made you think. Follow Harish Chatla for real-world SQL problems. Subscribe to practice on our platform. #DataRejected #SQL #DataEngineering #Analytics #DataScience #SLA #DataQuality #InterviewPrep #CodingPractice

I used to think duplicates in a dataset were just something to clean up. Add a DISTINCT, move on, problem solved. But that approach started to feel wrong after a while. In most cases, those “duplicates” weren’t random. They were coming from how the data was structured or how it was being joined. Multiple rows often meant something real was happening in the data. A one-to-many relationship. Changes over time. Records that were valid in different contexts. Using DISTINCT made the output look cleaner, but it also removed that context. I’ve seen cases where the numbers looked correct after removing duplicates, but the underlying issue in the logic was still there. Over time, I’ve started treating duplicates less as something to remove and more as something to understand. That shift in thinking took some time. Once you understand why the extra rows exist, the right solution becomes clearer. Sometimes it’s fixing the join. Sometimes it’s selecting the right record. Sometimes it’s aggregating correctly. But it’s rarely just filtering rows out. #DataEngineering #SQL #DataQuality