Top useless SQL Concepts 🥱

that u prob wont use IRL often

Got BDE?⚡️

Hi BDEs! This one might be a little controversial… but I’ll see you in the comments 🥊😂 btw i asked my bff Chat to make me an image of 2 data analysts fighting and i can’t believe it made them both men despite knowing I AM A WOMAN!! ok… ⬇️

Useless SQL Concepts you’ll NEVER use IRL 🤫

There’s a weird disconnect between how SQL is taught in courses and what you actually use in real life…

Sometimes you take a course (or more likely, see a LinkedIn post) and they hit you with pretty niche SQL skills. Recursive CTEs. Natural joins. Theoretical stuff you’ll prob never use… but hey, they look impressive 😏

And then you get your first real job as a data analyst and realize…

Nobody is asking for any of that. Not one single person !!!

Finance bros are not asking recursive problems LOL, they just want their revenue numbers. Most everyday business problems have simple-ish solutions as long as you have ✨accurate and clean✨ data to support them.

Usually stakeholders want:

• A quick customer order count by region

• A dashboard that shows revenue by week

• Why do these two reports say different things?

So let’s talk about the SQL stuff I thought I’d be using daily but haven’t touched outside of a course, LinkedIn post, or technical interview.

Disclaimer: These skills of course have their use cases. I am not saying they should NEVER be used or are NEVER needed. But… in general, I think they’re overhyped considering the amount they’re used. Wanted to get that out of the way before the data engineer bros with quick fingers come at me 😏

1. Recursive CTEs:

   They’re cool in theory especially if you want to do some heavier duty programming (come at me, SWEs 😉) but never have I ever had a bro from sales ask me business problem requiring this complexity… They can be useful if you’re working on recursive hierarchies, but 99.999% of the business questions I’ve solved didn’t require recursion. I think they’re great to learn and expand your skills, but you probably won’t use them very often to solve everyday business questions.

   WITH RECURSIVE employee_hierarchy AS (
       SELECT employee_id, manager_id, 1 AS level
       FROM employees
       WHERE manager_id IS NULL
   
       UNION ALL
   
       SELECT e.employee_id, e.manager_id, eh.level + 1
       FROM employees e
       JOIN employee_hierarchy eh ON e.manager_id = eh.employee_id
   )
   SELECT * FROM employee_hierarchy;

2. Natural Join:

   They’re fancy but just a gimmick. Why are we letting SQL guess and assume what keys to join on because we're lazy? Not only is not specifying your joining keys super lazy (if I didn’t already make that clear before), but it also opens up a lot of possibility for error. In the real world, column names aren’t always consistent, self-explanatory, and clean. This can make natural joins a ✨blindfolded join✨. Plus, who wants to decipher this while reviewing your code?! Just don’t.

   -- let SQL make assumptions and decide how to join
   SELECT 
      *
   FROM 
      users
   NATURAL JOIN 
      orders;
   
   
   -- explicitly specifying the joining keys
   SELECT *
   FROM 
      users u
   JOIN 
      orders o 
      ON u.user_id = o.user_id;

3. Right Join:

   No one actually uses right joins because they’re not useful. Only data psychos use them. (ok fine, I use them once in a blue moon when I accidentally put my tables in the wrong order and I'm too lazy to switch them... but NEVER for a production query). In my Intermediate SQL course🔗, I only spend 3 minutes teaching them, and I spend the whole time making fun of them and undermining them. As they should be ✌️

   -- if you accidentally put the wrong table on the left side... you can switch your left join to a right join instead of moving the tables 😂
   
   SELECT 
      o.order_id, 
      u.name
   FROM 
      orders o
   RIGHT JOIN 
      users u 
      ON u.user_id = o.user_id;

4. Cross Join:

   Nothing will ruin your optimization and explode your data warehouse like accidentally doing one of these bad boys when you don’t mean to. They can be useful for generating dummy data or creating all the combinations on purpose, but 99.999% of the time I’ve seen a CROSS JOIN in the wild, it was because someone forgot a join condition. And that someone might’ve been me a few times… 🤫 OOPS!

   BUT I think I’m going to stop throwing shade at cross joins and write about the actual use cases for next week’s newsletter. Are they the MOST important or useful SQL skill? Absolutely not. But they do have good use cases which I’ll show some love to next week!

   SELECT 
       p.product_id, 
       p.name AS product_name, 
       d.promo_day
   FROM 
       products p
   CROSS JOIN 
       promo_days d;

5. DENSE_RANK() and RANK():

   Ah yes, the fancy and less useful cousins of ROW_NUMBER(). I’m sure I’ll get hate for this one… Listen, I LOVE a good window function. But in the real world? I'm not usually handling multi-tiered tiebreakers. I’m just trying to get a top 1 product per user. Or most recent transaction. Or best performing ad. And for those types of business problems? ROW_NUMBER() is good enough 99% of the time. BUT I will say that it’s 100% worth learning the different ranking functions and their calculations because you most likely will see them in technical interviews. It’s one of the most common interview questions, so study all 3!

SELECT 
   user_id, 
   revenue,
   DENSE_RANK() OVER (ORDER BY revenue DESC) AS dense_rank,
   RANK() OVER (ORDER BY revenue DESC) AS rank,
   ROW_NUMBER() OVER (ORDER BY revenue DESC) AS row_number
FROM 
   user_revenue;

The Real Flex? 💪🏼

Writing SQL that’s fast, accurate, AND solves the right problem with the least amount of complexity. Sure, there are times you may need dense_rank() or recursive CTEs in the real world. Maybe even a cross join— there’s a time and a place for everything.

But my advice? Skip the edge cases, and focus on the 20% that drives 80% of your work. Learn what actually moves the needle, transforms data efficiently, and is easy to maintain longterm. That has the biggest impact in business.

✅ That’s what gets you hired.

✅ That’s what makes you the go-to data person everyone trusts.

✅ That’s what gets you promoted.

Get GOOD at the fundamentals—and you'll be unstoppable.

Go queen, go! 💅🏼 👸

If you’re ready to level up in SQL: build your first Data Analytics project in only 30 min for free (even if you’re a complete newbie with no experience):

See ya soon, data baddies 💅🏼

Jess Ramos 💕

---

⚡️ Social Highlights:

jessramosdata

A post shared by @jessramosdata

---

⚡️If you’re new here:

💁🏽‍♀️ Who Am I?

I’m Jess Ramos, the founder of Big Data Energy and the creator of the BEST SQL course and community: Big SQL Energy⚡️. Check me out on socials: 🔗LinkedIn, 🔗Instagram, 🔗YouTube, and 🔗TikTok. And of course subscribe to my 🔗newsletter here for all my upcoming lessons and updates— all for free!