Nen Bakraniya’s Post

I used to write SQL like I was fighting the database. Nested subqueries. Temp tables everywhere. Self-joins that made my future self want to cry. Then I learned ROW_NUMBER(). Let me show you what I mean. Say you have a table with millions of transaction records and you need the most recent transaction per customer. Before (the ugly way): SELECT * FROM transactions t WHERE t.date = ( SELECT MAX(date) FROM transactions WHERE customer_id = t.customer_id ) This works. It also runs like it's powered by a hamster on a wheel. On 10M+ records, I once waited 14 minutes for this to finish. Went and made coffee. Came back. Still running. After (window function): SELECT * FROM ( SELECT *, ROW_NUMBER() OVER ( PARTITION BY customer_id ORDER BY date DESC ) AS rn FROM transactions ) ranked WHERE rn = 1 Same result. Ran in under 40 seconds. That's not a minor improvement. That's the difference between "the report is almost ready" and actually having an answer before the meeting starts. The thing nobody tells you about SQL: the jump from intermediate to advanced isn't about learning more functions. It's about stopping the brute force approach and letting the database do what it was designed to do. One function. That was the turning point for me. What's the SQL trick that changed your workflow? Drop it below — I'm always collecting these. — #SQL #DataAnalyst #DataAnalytics #PowerBI #OpenToWork

I used to think SQL Joins were confusing… until I stopped looking at them as code. And started seeing them as people. Imagine this: You have two lists — 👨💼 Employees 🏢 Departments Now the question is… who do you want to see? 👉 INNER JOIN Only those employees who actually belong to a department. (No department? No entry.) Harsh… but clean. 👉 LEFT JOIN “All employees matter.” Even if they don’t have a department yet — they still show up. 👉 RIGHT JOIN “All departments matter.” Even if no one is assigned to them — they’re still visible. 👉 FULL OUTER JOIN “Let’s not miss anything.” Everyone and everything shows up — even if they don’t match. And that’s when it clicked for me: SQL Joins aren’t technical… they’re just decisions. Decisions about what you want to include… and what you’re okay leaving out. Once you get that — SQL becomes a lot less scary. #SQL #DataAnalytics #BusinessAnalysis #LearningJourney

Learned SQL Views today — one of the most powerful features in SQL Server. 👁️ Created a View (vwEmployeeInformation) that combines data from 3 tables using INNER JOIN: ✔️ Employees → Employee name & salary ✔️ Department → Department name ✔️ Designations → Job title What is a VIEW? A virtual table that doesn't store data — it just presents joined data in a clean, readable format. Query it just like a regular table. Why it matters: Instead of writing complex JOINs every time, just call the View. Clean, reusable, and easy to maintain. One step deeper into backend development. 🚀 #SQL #SQLServer #Views #INNERJOIN #Database #BackendDevelopment #LearningInPublic #CSE

🚀 Day 3/30 — SQL Server Revision Journey Today was all about one of the most important concepts in SQL: JOINS 📌 What I covered: 🔹 INNER JOIN (matching data from multiple tables) 🔹 LEFT JOIN (keeping all records from left table) 🔹 RIGHT JOIN (keeping all records from right table) 🔹 LEFT & RIGHT ANTI JOIN (finding missing data) 💡 Key learning: Understanding joins is not just about syntax — It's about asking the right questions: 👉 Which data exists in both tables? 👉 Which records are missing? 👉 How do we combine datasets for better insights? For example: ✔️ INNER JOIN → Find matching records (e.g., employees with departments) ✔️ LEFT JOIN → Identify missing relationships ✔️ ANTI JOIN → Find unmatched or missing data (very useful in real analysis) 💻 Also solved intermediate-level SQL problems on HackerRank to strengthen practical understanding. This helped me move from: 👉 Writing queries → Solving real problems 📊 Consistency + Practice = Progress 📍 Next: Subqueries & Advanced Filtering #SQL #DataAnalytics #LearningJourney #SQLServer #HackerRank #OpenToWork

⚠️ DAY 9/15 — SQL TRAP: IN vs EXISTS Your query returns 0 rows. No error. No warning. One NULL in the list is silently killing all your results. 👇 🎯 The Situation: You want to find all employees whose department exists in the departments table. You use IN. Looks perfect. Runs fine. Result → 0 rows. 😵 But the departments ARE there! Alice, Bob, Dave all have valid departments! What just happened? 🧠 Here's the silent killer: Look at the departments table. One row has DEPT_ID = NULL for HR. When IN sees that NULL in the list — it compares every employee's dept_id against it. NULL comparison = UNKNOWN. Always. Now SQL is unsure about EVERY row. So it returns NOTHING. Zero rows. Silently. 😬 One NULL in the subquery. Entire result — wiped out. ✅ The Fix — Use EXISTS instead: EXISTS doesn't compare values in a list. It simply asks row by row — "Does a matching row exist? Yes or No?" NULLs in the subquery? EXISTS doesn't care. It just checks for a match and moves on. Result → Alice, Bob, Dave returned correctly ✅ 💡 Real Life Example: IN = checking if your name is on a guest list If the list has one smudged unreadable name — IN panics and says "I can't confirm ANYONE" ❌ EXISTS = a security guard checking each person one by one One smudged entry doesn't stop everyone else from entering ✅ 📌 Save This Rule: → Using IN with a subquery? → Check if NULLs can exist in that list → Subquery might return NULLs? → Always use EXISTS instead → IN works fine with fixed value lists like IN (10, 20, 30) → EXISTS is always NULL-safe for subqueries → When in doubt → EXISTS is the safer choice 🔑 One Line to Remember: IN + NULL in list = 0 rows silently EXISTS + NULL = works perfectly fine Same goal. Very different behaviour with NULLs. Follow for Day 10 tomorrow 🚀 #SQL #SQLForBeginners #DataAnalytics #LearnSQL #SQLTips #DataEngineering #InterviewPrep

DAY 2 — The Tool vs The Thinking Nobody talks about the 20 minutes before the query. Everyone learns SQL. The syntax, the joins, the aggregations — honestly you can pick that up in a week on YouTube. What takes much longer is sitting with a messy dataset and asking — wait, what am I actually trying to find out here? Because in my experience the query was never the hard part. The hard part was figuring out which metric actually mapped to the real business problem. Noticing a number looked off and not just accepting it. Then explaining what you found to someone who has never written a line of SQL in their life and making them care about it. That last one? Nobody prepares you for that. I’ve worked across 5 business functions analyzing operational data and the moments that actually moved the needle had nothing to do with how clever the query was. They came from asking the right question before touching the keyboard. Tools are learnable. The thinking behind them is the actual skill. What’s something in your field that looks simple on the surface but is way deeper once you’re actually in it? Genuinely curious. #DataAnalytics #SQL #BusinessAnalysis #OpenToWork #Houston

The easiest way I learned SQL Most people jump straight into calculations. That’s where things get messy. Here’s what actually worked for me: Step 1: Ask yourself — do I need multiple tables? If yes → JOIN them first. Don’t touch calculations yet. Step 2: Now look at the data you’ve built. Then decide — do you need SUM, AVG, COUNT? Step 3: If your query starts looking like a paragraph… Use a CTE. Break it down. Clean it up. Because the truth is: SQL isn’t hard. Bad order of thinking makes it hard. Structure first. Logic second. Calculations last. Try this once, you’ll feel the difference. #SQL #DataAnalytics #LearningSQL #lookingforjob #Tech

🧠 SQL Functions — The Complete Cheat Sheet Every Analyst Needs! SQL isn't just SELECT and WHERE. The real power lies in its built-in functions. 👇 1️⃣ Aggregate Functions Summarize your data in one line → COUNT() · SUM() · AVG() · MAX() · MIN() 2️⃣ String Functions Clean, format & transform text → UPPER() · LOWER() · CONCAT() · SUBSTRING() · LENGTH() 3️⃣ Date Functions (MySQL Syntax) Work with time like a pro → NOW() · DATE_ADD() · DATEDIFF() · YEAR/MONTH/DAY 4️⃣ Mathematical Functions Precise calculations, zero effort → ROUND() · CEIL() · FLOOR() · ABS() 5️⃣ Conditional Functions Add logic directly into your queries → COALESCE() · CASE WHEN 🎯 Use these functions to: ✅ Summarize data ✅ Format & clean strings ✅ Handle NULLs gracefully ✅ Calculate time differences ✅ Add if/else logic in queries 💡 Master these 20 functions and you can handle 80% of real-world SQL problems. Save this post 🔖 — your future self will thank you! ♻️ Repost to help someone learning SQL today! #SQL #SQLFunctions #DataAnalytics #DataAnalyst #LearnSQL #SQLTips #DatabaseManagement #SQLInterview #DataEngineering #Analytics #TechLearning #SQLForBeginners #DataScience #CaseWhen #StringFunctions #DateFunctions #ShankarMaheshwari #UpskillDaily #DataCommunity #CareerGrowth

Today I spent some time revisiting the difference between NOT IN and NOT EXISTS in SQL to strengthen my understanding. At a basic level, both are used to filter out records, and they often look interchangeable. But when I explored a bit more, I realized they behave differently in certain cases. One important thing I noticed is how NULL values can affect the result. If the subquery used in NOT IN contains NULL, it can lead to unexpected results or even return no data. On the other hand, NOT EXISTS works differently and checks row by row, which makes it more reliable in such scenarios. Takeaways: NOT IN works fine when you are sure there are no NULL values NOT EXISTS is safer when dealing with real-world data Small differences in SQL logic can have a big impact on results This helped me understand how important it is to not just write queries, but to think about how they behave with actual data. Still learning and improving step by step. #SQL #DataEngineering #Database #LearningInPublic #OpenToWork

Day 29 – EXISTS Operator There's a SQL operator most beginners completely skip. It's not SELECT. Not WHERE. Not even JOIN. It's EXISTS and once you learn it, you'll use it every week. EXISTS is like a bouncer checking a VIP list. "Is this person on the list?" YES or NO. That's literally all it returns. It doesn't care about names, amounts, dates. Just: does a matching row exist? SELECT c.name FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id) For each customer, EXISTS checks the orders table stops the moment it finds one match. Much faster than IN on large tables. And its twin — NOT EXISTS — is even more useful: It finds what's MISSING. Customers with zero orders. Employees who didn't submit timesheets. Products with no reviews. One golden rule you must know: NOT EXISTS > NOT IN If even ONE NULL exists in a NOT IN subquery it returns ZERO rows silently. NOT EXISTS never has this problem. #SQL #LearnSQL #SQLforBeginners #DataAnalytics #TechCareer #DataScience