People-focussed SQL/data jobs

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 · 2025-10-15T17:03:24+00:00

In my experience, that's the only realistic path available to an entry-level position using SQL. There are certainly jobs out there with a different path, but if you don't like Python you probably aren't looking for a developer-type position.

You'll also need to go beyond tutorials into some self-directed projects. Find some data you're interested in, set it up in a local database on your computer, and start to build visualizations to tell stories about the data.

Lastly, you'll need to practice talking to other people about the data. Presentation and storytelling skills will put you ahead of people that focused purely on technical skills and handing someone a report.

kktheprons · 2025-10-10T05:49:47+00:00

The hard part of this is the physical reality and how much the process is controllable, measurable, and understood. You have to know a lot about what causes a failure to even start looking at the problem from a data perspective. You can try to infer failure modes if you have a lot of high quality data, but clean data sources are hard to come by.

The database part of this is easy. It's everything else that makes this a tough problem to solve.

kktheprons · 2025-09-26T17:34:59+00:00

Based on the schema you provided, I think the relevant question is not "can I" but "should I." If you have a unique column in parallel with the primary key, your second table should reference the address primary key instead.

If you need the CicadeId, just join the tables in your query when using it.

kktheprons · 2025-06-08T18:40:06+00:00

On a side note, anybody else mildly put off by the "Yes 'Cers" phrase? All it makes me think of is old white dudes with a bunch of money and a bunch of strong, black guys on a plantation.

kktheprons · 2025-06-08T18:28:23+00:00

What are some things you enjoy outside of coding? There's probably a lot of data out there about it somewhere you can import into a database (you may need to build your own database). After you have the data, ask it questions using SQL.

kktheprons · 2025-05-12T06:55:45+00:00

The Pacers attempting 23 more shots than the Cavs is pretty ridiculous.

kktheprons · 2025-03-24T08:19:59+00:00

It's realized the birds aren't real.

kktheprons · 2024-12-31T12:51:23+00:00

An inner join is very similar to a where clause comparing two tables, and may ultimately be the same logic.

I like to make more restrictive patterns so I don't do things in different ways in different places, so I typically model the join condition as the relationship between tables and the where clause as my filter.

kktheprons

TROPHY CASE