Nen Bakraniya’s Post

⚠️ 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

🧠 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

Working with data? Then you can’t ignore SQL Date Functions Dates are everywhere, from transactions to user activity, and knowing how to manipulate them is a must-have skill. Here are a few essential date functions every SQL professional should know: • GETDATE() / CURRENT_TIMESTAMP → Get the current date and time • DATEADD() → Add or subtract time (days, months, years) • DATEDIFF() → Find the difference between two dates • DATEPART() → Extract specific parts of a date (year, month, day, hour) • DATENAME() → Get the name of a date part such as Monday or January Example using DATENAME(): ```sql SELECT datetime_req, DATENAME(MONTH, datetime_req) AS MonthName, DATENAME(WEEKDAY, datetime_req) AS DayName FROM your_table; ``` Why does this matter? Because real-world problems often sound like: • “Show transactions from the last 7 days” • “Get users active this month” • “Break down activity by day, month, or year” If you can handle dates well, you move from writing queries to solving business problems. Keep learning. Keep building. #SQL #DataAnalytics #TechSkills #Learning #Database

🚀 Day 36/100 — SQL Indexes: Speeding Up Queries ⚡📊 Today I learned how to improve query performance using Indexes in SQL — a key concept in real-world systems. 📊 What is an Index? 👉 A data structure that improves the speed of data retrieval 👉 Works like an index in a book — helps you find data faster 📌 What I explored today: 🔹 Creating indexes 🔹 How indexes improve performance 🔹 When to use (and avoid) indexes 🔹 Impact on large datasets 💻 Example: CREATE INDEX idx_customer_id ON orders(customer_id); 📊 Without Index: ❌ Full table scan (slow) 📊 With Index: ✅ Faster data retrieval 🔥 Key Learnings: 💡 Indexes significantly improve query performance 💡 Very useful for large datasets 💡 Overusing indexes can slow down inserts/updates 🚀 Real-world use cases: ✔ High-performance applications ✔ Large databases (millions of rows) ✔ Frequently searched columns 🔥 Pro Tip: 👉 Use indexes on: Columns used in WHERE Columns used in JOIN Columns used in ORDER BY 📊 Tools Used: SQL | MySQL ✅ Day 36 complete. 👉 Quick question: Do you focus more on writing queries or optimizing performance? 🤔 #Day36 #100DaysOfData #SQL #Indexes #PerformanceOptimization #DataAnalytics #LearningInPublic #CareerGrowth #JobReady #InterviewPrep

I’ve reviewed a lot of SQL code over the years. The same 7 mistakes show up every time. In every company. At every level. 1. SELECT * — fetching 40 columns when you need 4. Every. Single. Time. 2. No indexes on JOIN keys — full table scan on every run. Your query isn’t slow. Your schema is. 3. Nested subqueries instead of CTEs — recalculated for every row. Rewrite it as a CTE. You’re welcome. 4. Never running EXPLAIN — optimising SQL without reading the execution plan is like driving blindfolded and guessing where the turns are. 5. Functions on WHERE columns — YEAR(date) = 2024 kills your index instantly. Use a date range. Two minutes to fix. Hours saved per run. 6. DISTINCT to hide bad JOINs — DISTINCT doesn’t fix duplicates. It hides them until someone asks why the revenue number looks wrong. 7. Filtering after the JOIN — joining 10 million rows then filtering to 50,000 is backwards. Filter first. Join small. I’ve committed all 7 at some point. Number 6 aged the worst. Which one made you wince? Drop your number below. #SQL #DataAnalytics #DataAnalyst #DataEngineering #OpenToWork

⚡ Performance Impact of SQL JOINs – What Every Developer Should Know SQL JOINs are powerful—but if used incorrectly, they can seriously impact your query performance. Let’s break it down in a simple way 👇 ------------------------------------------------------ 🔍 Why JOIN Performance Matters When you use JOINs, the database engine has to: • Scan multiple tables • Match rows based on conditions • Return combined results 👉 The larger the data, the heavier the operation. 🔹 INNER JOIN (Faster in Most Cases) Why? Only returns matching records → less data to process ✅ Efficient when: • Both tables are properly indexed • You only need matched data 💡 Tip: Always index the JOIN columns 🔹 LEFT JOIN (Heavier than INNER JOIN) Why? Returns ALL rows from left table + matching rows ⚠️ Can slow down when: • Left table is large • Many unmatched rows exist 💡 Use only when you truly need all records from the main table 🔹 RIGHT JOIN (Similar to LEFT JOIN) Same performance behavior as LEFT JOIN, just reversed. ⚠️ Often avoided in practice 👉 Developers prefer rewriting it as LEFT JOIN for clarity 🚨 Common Performance Mistakes 🔸 Joining without indexes 🔸 Joining large tables unnecessarily 🔸 Using SELECT * instead of specific columns 🔸 Missing proper WHERE conditions 🟢 Best Practices for Better Performance 🔸 Index your JOIN columns 🔸Filter data early using WHERE 🔸Avoid unnecessary JOINs 🔸Use INNER JOIN when possible 🔸Limit returned columns 📌 Real Impact Poorly optimized JOINs can: • Slow down your application • Increase server load • Cause timeouts in large systems 💡 Tip: Always check your query using EXPLAIN to understand how the database executes your JOIN. 📣 Question for You: Have you ever faced slow queries because of JOINs? How did you optimize them? #SQL #DatabaseOptimization #Performance #WebDevelopment #DataEngineering #LearningSQL

🚀 Day 32/100 — SQL Subqueries: Thinking Inside Queries 🧠💻 Today I learned Subqueries, a powerful concept in SQL used to solve complex problems step by step. 📊 What is a Subquery? 👉 A query inside another query ➡️ Used to break down complex problems into simpler parts 📌 What I explored today: 🔹 Subqueries in SELECT 🔹 Subqueries in WHERE 🔹 Subqueries in FROM 🔹 Nested queries for filtering 💻 Example Scenario: 👉 Find customers who made orders above the average order value 📌 Example Query: SELECT customer_id, order_amount FROM orders WHERE order_amount > ( SELECT AVG(order_amount) FROM orders ); 📊 How it works: 👉 Inner query → calculates average 👉 Outer query → filters higher-than-average orders 🔥 Key Learnings: 💡 Subqueries help solve complex business questions 💡 Makes SQL more flexible and powerful 💡 Commonly asked in interviews 🚀 Real-world use cases: ✔ Filtering based on averages ✔ Comparing values within datasets ✔ Dynamic data selection 🔥 Pro Tip: 👉 Use subqueries when: You need step-by-step filtering OR when JOINs become complex 📊 Tools Used: SQL | MySQL ✅ Day 32 complete. 👉 Quick question: Do you prefer solving problems using JOINs or Subqueries? 🤔 #Day32 #100DaysOfData #SQL #Subqueries #DataAnalytics #LearningInPublic #CareerGrowth #JobReady #InterviewPrep

📅 SQL Date & Time Functions (Simple Explanation) Working with dates and time is very common in SQL. These functions help you get, format, and calculate date values easily. 👉 1. GETDATE() Returns the current date and time Example: SELECT GETDATE() 👉 2. CURRENT_TIMESTAMP Also gives current date and time (same as GETDATE) 👉 3. GETUTCDATE() Returns current UTC date and time (global time) 👉 4. DATEADD() Adds or subtracts time from a date Example: Add 5 days → DATEADD(DAY, 5, GETDATE()) 👉 5. DATEDIFF() Finds difference between two dates Example: DATEDIFF(DAY, '2024-01-01', '2024-01-10') → 9 days 👉 6. DATENAME() Returns name of date part (like month or day) Example: DATENAME(MONTH, GETDATE()) → April 👉 7. DATEPART() Returns numeric value of date part Example: DATEPART(YEAR, GETDATE()) → 2026 👉 8. FORMAT() Formats date in different styles Example: FORMAT(GETDATE(), 'dd-MM-yyyy') 👉 9. ISDATE() Checks if value is a valid date Example: ISDATE('2026-04-27') → 1 (Valid) --- 💡 Why these are important? Used in reports 📊 Helps filter data by date 📅 Useful in real-time applications ⏱️ --- #SQL #DataAnalytics #SQLServer #Learning #TechBasics #Database #ITSkills

🛠️ I’ve been organizing my notes on SQL fundamentals, and I wanted to share this cheat sheet covering three areas that drastically impact database performance and report readability: 🧱 1. Data Types: The Foundation of Performance Choosing the wrong data type doesn't just look messy; it wastes storage and hurts query speed. INT / DECIMAL: For strict math and IDs. (Using DECIMAL(p,s) is crucial for financial exactness!) VARCHAR vs. CHAR: VARCHAR is for flexible text (names), while CHAR is best for fixed-length codes (like country codes) to maintain data integrity. BOOLEAN: The cleanest way to flag statuses (True/False). ⏱️ 2. Date & Time Functions: The Analytics Engine Most business reporting relies on time-based filtering. Mastering these functions automates your trend analysis: CURRENT_DATE / NOW(): Keeps your dashboards dynamic so you never have to hardcode today's date. DATEDIFF(): Essential for calculating metrics like "Time to Resolution" or "Customer Lifespan." DATE_ADD / DATE_SUB: Perfect for creating rolling windows (e.g., pulling data for the last 7 or 30 days). ✨ 3. Aliases (AS): The Presentation Layer Complex queries often result in messy output headers. Column Aliases instantly translate backend jargon into stakeholder-ready labels (e.g., salary AS monthly_salary). Table Aliases (e.g., FROM employees AS e) keep your multi-table joins clean and easy to troubleshoot. 💡 Key Takeaway: Always use the right data type to protect performance, rely on date functions for real-world reporting, and use aliases to make your code readable for the next developer! What is one date function you find yourself using in almost every report? Let’s discuss below! 👇 #SQL #DataEngineering #DatabaseManagement #PerformanceOptimization #TechCommunity #ContinuousLearning

If you're a hiring manager posing SQL query questions to be asked by someone else, consider, rather than merely listing the columns in a table, adding a few rows of sample data. As a candidate being told that the objective is to return monthly revenue per month from a table consisting of four columns: customer_id, start_date, end_date, revenue doesn't give the aspirant sufficient insight to provide a complete answer: are start_date and end_date sufficient to define the month (eg: start_date '2026-04-01' and end_date '2026-04-30') or are they coupled to the customer account date (eg: start_date '2020-01-01' and end_date '2030-12-31' or NULL). Dummy data in a hypothetical like this empowers the aspirant to be able to see quickly how to proceed with answering - is it safe to return DATETRUNC('month', start_date) AS 'mm/yy', SUM(revenue) WHERE DATETRUNC('month', start_date) = DATETRUNC('month', end_date) or does there need to be some parsing required to ensure whether the monthly value for any particular date is between start and end? What about if there's only a single row per customer_id? Writing a recursive stored procedure *might* be adequate for that last case if the source table is updated on a known cadence. If the requested monthly output falls within the start and end dates, or if it's after the start in cases with a NULL end there's a clear way to proceed, but without having some insight into how the data looks, any query produced is going to be suspect at best without a little more insight.