ZAID MUSHTAQ’s Post

Most analysts use SQL every day — but skip the one feature that makes complex analysis 10x faster. I'm talking about window functions. For the longest time, I relied on heavy GROUP BY queries and multiple subqueries to answer simple business questions. Window functions changed everything. Here's the difference in plain English: A regular aggregation collapses your rows. A window function looks across rows — without losing the row-level detail. Think of it like this: You want each employee's salary AND the average salary of their department — in the same row. GROUP BY can't do that. A window function does it in one line. 3 window functions worth mastering first: ▸ ROW_NUMBER() — rank records within a group (e.g., latest order per customer) ▸ LAG() / LEAD() — compare current vs. previous rows (e.g., month-over-month growth) ▸ SUM() OVER() — running totals without collapsing your data Once you understand PARTITION BY and ORDER BY inside the OVER() clause — you unlock a completely new level of SQL thinking. The syntax looks intimidating. The logic is actually intuitive. Which window function do you use the most — or wish you'd learned sooner? Drop it below 👇 #SQL #DataAnalytics #DataEngineering #CareerGrowth #TechSkills

Accuracy gets you in the door. Performance keeps you in the room. A couple of weeks ago, I ran a poll asking what actually makes a "good" SQL query and the responses confirmed something I've been learning the hard way. When I first picked up SQL, I had one goal: get the right answer. Query runs? Results look correct? Move on. But real-world data humbled me quickly. A sloppy query on 1,000 rows? Nobody notices. That same query on 10 million rows? It chokes your pipeline, burns through resources, and kills trust in your work. The truth is, anyone can write SQL that works. The real skill is writing SQL that works effeciently. Filtering early instead of late. Letting indexes do the heavy lifting. Never force a query to scan what it doesn't need. This isn't just about saving a few seconds, it's about saving your organisation real time and real money. Right answers are expected. Optimised answers are respected. Thank you to everyone who participated in the poll and shared their perspective. These small conversations push me to think deeper every time. What's the one SQL lesson that changed the way you write queries? I'd love to hear it. #SQL #DataAnalytics #DataAnalyst #QueryOptimisation #LearningInPublic #DataCommunity #Analytics #CareerGrowth #SQLTips

Day 4/30 of SQL Challenge Today I learned: -> LIMIT Key idea: LIMIT is used to control how many rows are returned in a query result. Example: SELECT * FROM products LIMIT 5; What I understood: When working with large datasets, we don’t always need all the data. LIMIT helps us quickly preview or focus on a smaller portion. Small insight: LIMIT is often used with ORDER BY to get top or bottom results. Example: SELECT name, price FROM products ORDER BY price DESC LIMIT 3; This returns the top 3 most expensive products. Practice thought: What if I want to skip some rows and then get results? Example: SELECT * FROM products LIMIT 5 OFFSET 5; This skips the first 5 rows and returns the next 5. Note: OFFSET is used to skip some data. In another day we just learn the OFFSET. #SQL #LearningInPublic #Data #BackendDevelopment #DataEngineer #DataAnalyst

𝗧𝘄𝗼 𝗦𝗤𝗟 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀. 𝗢𝗻𝗲 𝘀𝗺𝗮𝗹𝗹 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲. 𝗕𝘂𝘁 𝗶𝘁 𝗰𝗮𝗻 𝗰𝗵𝗮𝗻𝗴𝗲 𝘆𝗼𝘂𝗿 𝗿𝗲𝘀𝘂𝗹𝘁𝘀 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲𝗹𝘆. After finishing my 21 Days of SQL challenge, I decided to continue sharing small SQL insights that are easy to miss but important to understand. Today’s tip 👇 COUNT(*) vs COUNT(column) At first glance, these two look almost the same. But they behave very differently when NULL values are present. COUNT(*) Counts every row in the table, regardless of NULL values. SELECT COUNT(*) FROM orders; COUNT(column) Counts only rows where the specified column is NOT NULL. SELECT COUNT(discount) FROM orders; So if the discount column contains NULL values, those rows will not be counted. 💡 Why this matters In real datasets, NULL values are very common. Using the wrong count method can lead to incorrect analysis and misleading results. Key takeaway COUNT(*) → counts rows COUNT(column) → counts non-NULL values Small SQL details like this make a big difference in data analysis. Curious to know 👇 Did you know this difference before, or did it surprise you? #SQL #DataAnalytics #LearningInPublic #SQLTips #DataAnalyticsJourney

📊 Day 6/100: THE "SELECT" COMMAND Yesterday, we talked about queries, the questions we ask our data Mastering how and when to use the SELECT command is crucial, non-negotiable and a game changer in your journey as an analyst. with that being Today, let’s dive into the most important SQL command which is the SELECT command If SQL were a language, SELECT would be your voice. It allows you to retrieve data from a database. Simple, yet powerful. 🔹 Basic syntax: SELECT column_name FROM table_name; 🔹 Example: SELECT name, sales_amount FROM orders; This means: ➡️ “Show me the name and sales amount from the orders table.” 💡 Why SELECT matters: - It’s the foundation of data analysis - Every insight starts with retrieving the right data - It’s used in almost every SQL query (yes, almost ALL). #SQL #LearningInPublic #100Daysofanalysis #DataAnalyst #SelectCommand

If your SQL uses DISTINCT to fix duplicates, you might be hiding a bigger problem. DISTINCT is one of the most misused keywords in SQL. Yes — it removes duplicates. But here’s the problem: Duplicates usually don’t come from nowhere. They come from your logic. Most times, it’s caused by: • Wrong JOIN conditions • 1-to-many relationships • Poor understanding of the data So when you write: SELECT DISTINCT * FROM table; You’re not fixing the issue. You’re masking it. A better approach is: 1.Understand why duplicates exist 2.Fix the JOIN or aggregation 3.Control the data at the source Because clean output doesn’t always mean correct logic. #SQL #DataAnalysis #Analytics #DataEngineering #LearningInPublic

Day 28/30 Today’s sql class was a reminder that data analysis is not just about writing queries,it’s about making decisions through structure. On the surface, this looks like SQL. Tables, queries, outputs. But what we worked on was deeper than that. We took raw data and applied logic to categorize it, defining what is cheap, moderate, or expensive. And that right there is the work. Because data on its own doesn’t carry meaning. The analyst gives it meaning. How you group it. How you define it. How you choose to interpret it. That’s what shapes the insight. At the end of the day, business decisions are not made from raw tables, they’re made from structured, interpreted insight. Still building. Still refining. Still showing up. #Day28 #SQL #DataAnalytics #LearningInPublic #DataThinking #CareerGrowth

🚀 𝗠𝗮𝘀𝘁𝗲𝗿 𝗦𝗤𝗟 𝗪𝗶𝗻𝗱𝗼𝘄 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 If you're working with SQL and still relying heavily on GROUP BY, it's time to level up your skills. Window Functions allow you to perform calculations across rows without collapsing your dataset. This means you can: ✔ Rank data ✔ Calculate running totals ✔ Compare rows within the same result set All while keeping your original data intact. 🔍 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗕𝗲𝘁𝘄𝗲𝗲𝗻 𝗥𝗔𝗡𝗞(), 𝗗𝗘𝗡𝗦𝗘_𝗥𝗔𝗡𝗞() & 𝗥𝗢𝗪_𝗡𝗨𝗠𝗕𝗘𝗥() These are the most commonly used window functions for ranking 👇 👉 𝗥𝗢𝗪_𝗡𝗨𝗠𝗕𝗘𝗥() Assigns a unique number to each row. Even if values are the same, the numbering will be different. 👉 𝗥𝗔𝗡𝗞() Gives the same rank to duplicate values, but skips the next rank. Example: 1, 2, 2, 4 👉 𝗗𝗘𝗡𝗦𝗘_𝗥𝗔𝗡𝗞() Also gives the same rank to duplicates, but does NOT skip ranks. Example: 1, 2, 2, 3 💡 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗨𝘀𝗲 𝗪𝗵𝗮𝘁? Use 𝗥𝗢𝗪_𝗡𝗨𝗠𝗕𝗘𝗥() → when you need unique ordering (no duplicates) Use 𝗥𝗔𝗡𝗞() → when gaps in ranking are acceptable Use 𝗗𝗘𝗡𝗦𝗘_𝗥𝗔𝗡𝗞() → when you want continuous ranking #SQL #WindowFunctions #DataAnalytics #LearnSQL #SQLInterview #DataAnalyst #DataEngineering

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

🚀Day 87 of My 100 Days Data Analysis Journey This is what SQL looks like when everything finally connects. Not scattered commands. Not random syntax. But a clear system that controls how data is filtered, grouped, combined, and understood. At a glance, this breaks SQL into its core building blocks: WHERE, defines what matters GROUP BY & HAVING, turns raw data into meaningful segments ORDER BY, brings structure and clarity to results JOINS, connects multiple tables into one complete view FUNCTIONS, summarize data into insights ALIAS (AS), improves readability and interpretation Then comes precision: LIKE, IN, BETWEEN, EXISTS AND, OR, NOT Each one is small on its own. Together, they form a system that answers complex questions. The real shift happens here: SQL stops being something to memorize and becomes something to think with. That is where real analysis begins. #DataAnalytics #SQL #LearningInPublic #100DaysOfCode #DataSkills #TechJourney