SQL Mistakes: Filtering at the Wrong Stage

📊 𝐂𝐎𝐔𝐍𝐓 𝐢𝐧 𝐒𝐐𝐋: 𝐒𝐦𝐚𝐥𝐥 𝐃𝐞𝐭𝐚𝐢𝐥, 𝐁𝐢𝐠 𝐈𝐦𝐩𝐚𝐜𝐭 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

Six weeks in. This week is where SQL stopped feeling like a retrieval tool and started feeling like an analysis tool. Here is what I worked through. Subqueries to use calculated values inside filters. JOINs to replace slow subqueries that were running thousands of times instead of once. CTEs to break complex logic into named, readable steps. Window functions to calculate running totals, rankings, and moving averages without losing individual row data. The shift I noticed: I can now write queries that answer real business questions. Top 10% of customers by spend per region. Month-over-month growth by product category. Sales rep rankings with individual and cumulative totals side by side. Three weeks ago, those questions would have stopped me. Now they are starting points. The honest gap: Knowing when to reach for a window function versus GROUP BY still takes me a beat. I understand how both work. Choosing between them based on the question needs more repetition. I am working through comparison examples this weekend to sharpen that instinct. Next week I am going into query optimization and indexing. How databases actually execute queries, not just how to write them. Then transaction management and data modification beyond SELECT. The goal is not just working SQL but production-ready SQL. If you work with SQL professionally, what is one optimization technique you wish you had picked up earlier? #SQLFromScratch #DataScience #DataAnalysis Entry 20 of 100

I once had a simple-looking problem: 👉 “𝘞𝘦 𝘩𝘢𝘷𝘦 𝘥𝘶𝘱𝘭𝘪𝘤𝘢𝘵𝘦 𝘤𝘶𝘴𝘵𝘰𝘮𝘦𝘳 𝘳𝘦𝘤𝘰𝘳𝘥𝘴. 𝘒𝘦𝘦𝘱 𝘫𝘶𝘴𝘵 𝘰𝘯𝘦 𝘳𝘰𝘸 𝘱𝘦𝘳 𝘤𝘶𝘴𝘵𝘰𝘮𝘦𝘳.” Sounds easy… until someone asks, 💬 “𝘉𝘶𝘵 𝘸𝘩𝘪𝘤𝘩 𝘳𝘰𝘸 𝘴𝘩𝘰𝘶𝘭𝘥 𝘴𝘵𝘢𝘺?” That’s when I realized: 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 removes duplicates fast, but gives you no control. 𝗚𝗥𝗢𝗨𝗣 𝗕𝗬 does the same job, just more verbose. 𝗥𝗢𝗪_𝗡𝗨𝗠𝗕𝗘𝗥() lets you decide — latest record, highest priority, or whatever business logic you need. Same data. Same result. Radically different control. In SQL, the question isn’t “𝘊𝘢𝘯 𝘐 𝘳𝘦𝘮𝘰𝘷𝘦 𝘥𝘶𝘱𝘭𝘪𝘤𝘢𝘵𝘦𝘴?” It’s “𝘋𝘰 𝘐 𝘤𝘩𝘰𝘰𝘴𝘦 𝘸𝘩𝘢𝘵 𝘴𝘵𝘢𝘺𝘴?” That’s why 𝗥𝗢𝗪_𝗡𝗨𝗠𝗕𝗘𝗥() often wins in production systems. How do you usually handle duplicates in SQL? 👇 🔔 Don't forget to follow Baburao Budireddy for more tech job updates 𝐋𝐢𝐤𝐞 👍| 𝗦𝗔𝗩𝗘 📩 | 𝐑𝐞𝐩𝐨𝐬𝐭 ♻️ | 𝐂𝐨𝐦𝐦𝐞𝐧𝐭 💬 "𝐂𝐅𝐁𝐑" #SQL #DataEngineering #Analytics #Learning #Databases #TechTips #sqlfordataengineers #sqltips

I started over with data analysis this week, but something felt different. I already knew the tools — SQL, CTEs, window functions. But every time I opened my IDE, I would get stuck. Not because I didn’t know the syntax, but because I didn’t know what problem I was solving. Then something clicked. The real difference between someone who knows SQL and someone who works as a data analyst is not the queries. It’s the thinking. So I started a real project using a shipment dataset in BigQuery. Not just writing queries, but actually asking: What is wrong with this data? What does it mean for the business? Here’s what I worked through: • Cleaned messy text fields (trimming, standardizing formats) • Handled null and inconsistent values • Validated delivery dates and flagged invalid records • Detected outliers using the IQR method • Identified duplicate records using window functions But the biggest lesson wasn’t technical. At one point, I found duplicate shipment IDs with different freight costs. My first instinct was to remove duplicates using SQL. Then I stopped. If the same shipment has two different costs, is that really a duplicate… or a data problem? Instead of deleting, I investigated. That shift changed everything. Data analysis is not about writing perfect queries. It’s about understanding what the data represents and making decisions you can justify. This week, I’m continuing this project by answering real questions: Which carriers have the most delays? Which routes are the most expensive? Where is the business losing efficiency? Let’s see where this goes. #DataAnalytics #SQL #BigQuery #LearningInPublic #DataAnalyst #DataCleaning

I’ve been spending a lot more time in SQL lately. Not in a tutorial way but more in the day-to-day work of digging through tables, joining datasets, and figuring out where things don’t quite line up. A lot of quality and compliance work ends up living there: validating records, tracing data back to its source, and making sure what’s being reported actually reflects reality. It’s less about writing complex queries for the sake of it, and more about asking the right questions of the data; and knowing where to look when something feels off. That layer between raw data and final reporting is where I’ve been getting really comfortable. Here's what makes it so interesting: It's where meaning gets made. Raw data needs analysis because a timestamp is just a number. A user_id is just a string. That middle layer is where you decide: this event means a conversion, this combination of fields means a churned customer, this threshold means anomalous. You're not just moving data, you're encoding business logic into durable, reusable form Quiet work, but it sharpens how you think. #SQL #DataIntegrity #QualitySystems #HealthcareOps #Analytics

THIS QUERY LOOKS CORRECT. IT IS NOT. Most people think this query is correct. It runs. It returns results. But the logic is completely broken. Business problem: Find the latest product review for each customer based on their most recent completed order. Tables involved: orders - order_id - customer_id - order_date payments - payment_id - order_id - status - payment_date reviews - review_id - order_id - review_text - review_date At first glance, the logic seems simple: Join orders → payments → reviews and pick the latest order per customer. But real data doesn’t behave like that. - One order can have multiple payments - One order can have multiple reviews (edits / updates) - Joins create duplicate rows - “Latest” becomes ambiguous if not handled carefully So even if your query runs, you might be picking the wrong review. Think before answering: Are you selecting the latest order? Or the latest review? Or a random row created by joins? Fix the logic, not just the syntax. Comment your answer. Repost if this made you think. Follow Harish Chatla more real-world data problems. Subscribe to practice on our platform. #DataRejected #SQL #DataEngineering #DataAnalytics #DataScience #LearnByDoing #TechCareers #Analytics #CodingPractice

Day 03/30🚀 𝗦𝗤𝗟 𝗞𝗲𝘆𝘀 & 𝗖𝗼𝗻𝘀𝘁𝗿𝗮𝗶𝗻𝘁𝘀 — The Backbone of Reliable Data Most people learn SQL like this: 👉 SELECT, JOIN, WHERE… But in real systems? 👉Keys and constraints decide whether your data can be trusted or not. 🔑 𝗦𝗤𝗟 𝗞𝗘𝗬𝗦 (Define Relationships & Uniqueness) 🔹 𝗣𝗥𝗜𝗠𝗔𝗥𝗬 𝗞𝗘𝗬 (PK) 👉 Uniquely identifies each record 👉 Cannot be NULL or duplicate 🔹 𝗙𝗢𝗥𝗘𝗜𝗚𝗡 𝗞𝗘𝗬 (FK) 👉 Links one table to another 👉 Maintains referential integrity 💡 Think: Orders must belong to a valid customer 🔹 𝗨𝗡𝗜𝗤𝗨𝗘 𝗞𝗘𝗬 👉 Ensures all values are unique 👉 Allows NULL (depends on DB) 💡 Think: Email ID should not repeat 🔹 𝗖𝗢𝗠𝗣𝗢𝗦𝗜𝗧𝗘 𝗞𝗘𝗬 👉 Combination of columns to create uniqueness 💡 Think: (order_id + product_id) 🔹 𝗖𝗔𝗡𝗗𝗜𝗗𝗔𝗧𝗘 𝗞𝗘𝗬 👉 All possible columns that can act as PK 🔹 𝗦𝗨𝗣𝗘𝗥 𝗞𝗘𝗬 👉 Any combination that uniquely identifies a row 🛑 𝗦𝗤𝗟 𝗖𝗢𝗡𝗦𝗧𝗥𝗔𝗜𝗡𝗧𝗦 (Enforce Rules on Data) 🔹 𝗡𝗢𝗧 𝗡𝗨𝗟𝗟 👉 Column cannot store NULL values 🔹 𝗨𝗡𝗜𝗤𝗨𝗘 👉 Prevents duplicate values 🔹 𝗖𝗛𝗘𝗖𝗞 👉 Ensures values meet a condition 💡 Example: age > 0 🔹 𝗗𝗘𝗙𝗔𝗨𝗟𝗧 👉 Assigns default value if none is provided ✅𝗘𝘅𝗮𝗺𝗽𝗹𝗲: CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_id INT, email VARCHAR(100) UNIQUE, amount DECIMAL CHECK (amount > 0), status VARCHAR(20) DEFAULT ‘PENDING’, FOREIGN KEY (customer_id) REFERENCES customers(customer_id) ); 💡𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿𝘀? Without keys & constraints: ❌ Duplicate data ❌ Broken relationships ❌ Invalid values ❌ Unreliable dashboards With them: ✔ Clean data ✔ Trustworthy systems ✔ Strong data models 👉Keys define structure. Constraints enforce discipline. #SQL #DataEngineering #DatabaseDesign #ETL #DataQuality #LearningInPublic

🚀 Week 7 Reflection: From Writing Queries to Thinking Like the Optimizer Week 7 of my Data Analytics journey was a major turning point. This phase pushed me beyond “getting results” to truly understanding how and why SQL works under the hood. This week, I deepened my skills in Advanced SQL Queries and Optimization, focusing on turning complex business questions into efficient, scalable queries. 🔍 Key Highlights from the Week ✅ Mastered Complex Joins & Subqueries (INNER, LEFT, RIGHT, FULL OUTER) to analyze relationships across multiple tables ✅ CTEs (Common Table Expressions) - Simplified complex queries and improved code readability ✅ Set Operations - Mastered UNION, INTERSECT, and EXCEPT for powerful data comparisons ✅ Conditional Logic - Applied CASE statements and conditional aggregation for dynamic insights ✅ Used GROUPING SETS, ROLLUP & CUBE to generate powerful summaries and super-aggregates ✅ Explored Window Functions (ROW_NUMBER, RANK, LEAD, LAG) for ranking, trend analysis, and time-based comparisons ✅ Leveraged String & Date Functions for data cleaning, formatting, and feature extraction ✅ Learned CASE statements & Conditional Aggregation for smarter, rule-based analysis ✅ Understood Indexing trade-offs and how indexes impact query performance ✅ Interpreted execution plans using EXPLAIN & ANALYZE to identify bottlenecks and optimize queries 💡 Biggest Takeaway: Writing SQL is one thing. Writing efficient, readable, and performance-aware SQL is what makes a data analyst truly valuable. Each assignment felt closer to real-world scenarios—optimizing reports, analyzing customer behavior, ranking transactions, and improving query execution speed. 📈 Week 7 reinforced an important lesson: Good data analysis isn’t just about answers—it’s about how efficiently you arrive at them. On to the next phase of the journey 🚀 #DataAnalytics #AdvancedSQL #3MTT #DeepTechReady #DataScience #MALhub #TechSkills #LearningJourney #DataAnalyst #TechInNigeria #GoogleOrg

𝙎𝙌𝙇 𝘾𝙤𝙙𝙚 𝙤𝙥𝙩𝙞𝙢𝙞𝙯𝙖𝙩𝙞𝙤𝙣: Your SQL code is slow but you don't know how to optimize. follow below steps to optimize the code. 👉 Filter as early as possible. Always use WHERE clause to remove unnecessary rows before the data moves to the next stage of processing. 👉 Aggregate before joining. If you’re joining two large tables just to get a sum or average, perform the GROUP BY on the smaller table first. 👉 USE Proper Joins key. Ensures your joins are performed on columns that are indexed and have matching data types. Sticks to primary and foreign key for the fastest execution path. 👉 Select only required columns. Stop using SELECT * in production code. Explicitly naming your column reduces the data. 👉 Avoid functions on filter columns Avoid wrapping indexed columns in functions (like WHERE YEAR (date_column) = 2026. Instead, use a range like WHERE date_column >= ‘2026-01-01’ to keep your index active. I've written one example of optimized and non-optimized code into the comment section. check it out. --- 📌 Save this post (you’ll need it later) 🔁 Share with your network -- To clear the interview, I’ve curated a list of the Top 50 Most Asked SQL Interview Questions to help you prepare smarter, not harder. you can use SQL10 for 10% discount. https://lnkd.in/gWYfBjuJ #SQL #Data #DataAnalyst #DataEngineering #Learning #Coding #Analytics #CodeOptimization

🚀 Advanced SQL Patterns I’ve Used in Real Projects (No Code) Once you move beyond basics, SQL is no longer about writing queries— it’s about solving business problems using patterns. Here are some powerful ones I’ve used 👇 1. Cohort Thinking (Not just totals) Instead of looking at total users, break them by when they joined. 👉 This helps answer: “Are new users behaving better or worse than old ones?” 2. Funnel Breakdown (Step-by-step drop-offs) Don’t just track final conversions. 👉 Break the journey: Visit → Signup → Purchase 👉 Identify exactly where users drop 3. De-duplication Logic Real-world data is messy. 👉 Same user, multiple records 👉 You need logic to always pick the right record (latest / highest value) 4. Trend Comparison (Not just numbers) Numbers alone don’t tell much. 👉 Always compare: today vs yesterday, this week vs last week 👉 Helps catch sudden spikes/drops early 5. Segmentation Mindset Averages can be misleading. 👉 Break data by city, device, user type 👉 Most insights come from differences between segments 6. Cumulative Thinking (Growth view) Instead of daily numbers, track running totals 👉 Helps understand overall growth and momentum 7. Building Data Pipelines in Steps Complex problems = multiple steps 👉 Break into smaller parts instead of writing one big query 👉 Makes analysis clearer and easier to debug 💡 Biggest shift for me: I stopped thinking → “What query should I write?” And started thinking → “What question am I solving?” If you want to get better at SQL: 👉 Focus on patterns + problem-solving, not just syntax #SQL #DataAnalytics #AnalyticsThinking #LearnSQL #CareerGrowth