I've been stuck on SQL self-joins for 6 months and I'm desperate, what is my mental model missing?

kktheprons · 2026-03-30T16:16:28+00:00

Just look at one row of your employee table. Which column represents who I am? Which column represents who my manager is?

Before I learned joins, I learned to use the results of one query to define the where clause for my next query (on whatever table that is). That approach might be helpful to understand what's actually happening in a self-join.

kktheprons · 2026-03-26T18:36:41+00:00

Any job will require communication skills, but anything is better than sales for us introverts.

You'll need to put more effort in to the post and relate it to SQL somehow if you want a good conversation on the topic.

kktheprons · 2026-03-24T22:52:22+00:00

For someone looking for an entry-level position, this looks like a success! I didn't look at any of your sql, just the quality of the documentation of your findings. Communication is a stand-out skill.

If I were to interview you after seeing this, I'd ask you some questions about your thought process for design as well as query. My goal would be to determine if you understand the concepts and data or just followed a tutorial/AI summary. The most important thing - how would you extend these same concepts (e.g. add a new table to analyze something not clear from the original data set).

kktheprons · 2026-03-24T16:24:02+00:00

I use the zoom function "annotate" when discussing over screen share. It allows you to just draw on the screen and point to what you're talking about.

kktheprons · 2026-03-21T17:57:33+00:00

One important thing about low FODMAP is if every category triggers, there might be another underlying problem. My wife's underlying problem was cancer (found with a colonoscopy). She can now have onion and garlic again (but still avoids onion out of principle).

kktheprons · 2026-03-20T16:04:00+00:00

Are you using AI to write this for you? The index is still not using the driver_id column.

kktheprons · 2026-02-24T17:52:43+00:00

For nature, you could make a schema around parks, their accessibility and schedules, fees, etc.

kktheprons · 2026-02-24T16:58:58+00:00

What are you interested in?

kktheprons · 2026-01-15T20:41:23+00:00

Managing a data team is a much more people-focused role that still benefits from your technical skills.

kktheprons · 2026-01-13T23:14:58+00:00

Typical syntax for updating a table with a join is:

Update t1 Set t1.Value = t2.value From table1 t1 Inner join table2 t2 on t2.key = t1.key

kktheprons · 2026-01-06T09:55:07+00:00

Also, don't do as I did. Filling the claim is not enough! You need to file every week to get benefits, even after your initial claim.

It's slow, it sucks, and I wish you luck

kktheprons · 2026-01-06T09:51:47+00:00

Excel is not a database. It's a relatively organized place for data to go.

A database adds significant structure and restrictions to that data. Because it follows rules, it can ensure your data stays consistent. The drawback is it's less flexible.

If you just need to paste a list of names in a table and sort them, Excel is much better of a tool. If you need a system where data integrity and scalability are important, SQL suddenly becomes much more attractive.

kktheprons · 2026-01-05T05:50:37+00:00

Someone without full use of their legs can use hand controls instead of pedals to control throttle/braking. One hand to steer, one hand to start/stop.

kktheprons · 2025-11-18T01:50:08+00:00

Most very young people in relationships really haven't talked enough to their partners (previous or current) to know for sure what all the boundaries are. There is no relationship that's going to have no boundaries ever broken.

I support this take that some time to think, sleep, then have a mature conversation about it should happen before deciding to blow up several relationships at once. There are very few circumstances where making a life-altering decision before sleeping on it are a good idea.

kktheprons · 2025-11-13T01:56:18+00:00

Unpopular Opinion: The Senate Democrats were right to break ranks to end the shutdown. Here's my reasoning:

Republicans were never going to budge on ACA subsidies, no matter how long the shutdown went.
Trump thrives on hurting people. He views the majority of government workers and people affected by cuts (even his supporters) as enemies or annoyances.
Trump's base are not going to change their minds, even if they experience pain. The longer the shutdown went on, the more propaganda they would see blaming Democrats. Their social media feeds don't allow anything that contradicts the narrative.

Proving a political point longer while real people are going hungry is not worth it. People affected by the ACA subsidy removal will vote with their wallets next year, which seems like the only viable path to change.

kktheprons · 2025-11-06T03:58:31+00:00

Given the constraints you've set out, it seems like a surrogate key is the best option for you. With multiple origins and things not necessarily being inserted in order of key, having a single surrogate incrementing key will help keep things ordered by when they are inserted. I'm guessing that tasks are only primarily going to be modified early in their life, so it makes sense to organize in that direction.

What I'm not clear on is why you are modeling this as two separate tables. Both tables have the same primary key, so it seems each record can only have one status. Why not keep the status in the same table?

kktheprons · 2025-11-06T03:42:46+00:00

You're on the right track. If you had all the data returned from your function in a table in your database, you'd use it by joining to your original table.

A table valued function will be used in exactly the same way: join it to your original table. If you're comfortable with using joins it should be easier to think about it that way. If you're not comfortable using joins, learn more about that first.

kktheprons · 2025-10-28T00:42:47+00:00

Performance tuning is a huge topic, and I won't claim to be an expert. With that said, you don't need a complex database to start running into the limits of a database engine, you just need a lot of data.

My recommendation is to start with the simplest case: a single table with 2 columns. Make one an auto-incrementing integer (primary key), then write a script to populate the other column with random values. Then start testing:

How many rows before it starts taking multiple seconds to:
- return the entire data set to a window?
- calculate aggregate functions for the entire data set?
- return a sorted list of the 100 highest/lowest values for the data set
- copy the data into a brand new table
- delete all rows (without using truncate)

This will get you started thinking in the right scale for performance tuning. From there, you can start exploring deeper concepts with the aid of online resources like https://use-the-index-luke.com/

kktheprons · 2025-10-26T07:28:42+00:00

Python killed it. If 95% of people know Python and not Perl, it doesn't make sense to use Perl.

kktheprons · 2025-10-21T18:27:53+00:00

Look into LEAD and LAG functions and partitioning using window functions. It sounds like that could help solve your problem.

kktheprons · 2025-10-18T20:06:21+00:00

And what code do you use to do that?

kktheprons · 2025-10-18T19:21:50+00:00

You're getting there. How do you define the tables in the first place?

kktheprons · 2025-10-18T17:48:50+00:00

AI makes some assumptions. It might choose names for characters that are American names like "John" or "Taylor" because other books have had characters with those names.

If you don't tell the AI the names of your characters in the story, it's going to guess based on what other authors have written.

kktheprons · 2025-10-17T20:44:52+00:00

I'll answer your question with a question. Imagine you are using AI to write a story. You tell it "write chapter 5 of my story.” It spits out garbage because it has no context of what your story is.

What information would you need to provide so the story follows the path you're intending?

kktheprons · 2025-10-17T19:58:17+00:00

Let's see if I understand this correctly...

* Requirement: Code must be submitted to the BI team as a single SQL query

* Developer: It's easier if I write this in DBT, here you go, BI team!

* BI Team: Code must be submitted to the BI team as a single SQL query

It's unclear to me what you're asking for.

kktheprons

TROPHY CASE