SQL Corgs Explain Inner Joins
Joins are essential. The SQL Corgs introduce you to INNER joins in this animated short. When you need to combine data from multiple tables, INNER joins are your go-to tool: they only return rows where there’s a match in both tables.
Watch as Freyja and Stormy demonstrate how matching on color brings their favorite toys together, with sample code you can run yourself.
Awkward Unicorn Explains Database Normalization
Why do we “normalize” relational databases, and what are the basics? Awkward Unicorn explains, with a little help from their friends.
Database normalization helps you organize data efficiently, reduce redundancy, and prevent update anomalies. It’s one of those foundational concepts that makes everything else in database design make more sense.
SQL Basics (SELECT, FROM, WHERE) with Freyja the Corgi
Freyja the corgi shares her tips for learning SQL: SELECT, FROM, and WHERE. These three keywords form the foundation of almost every query you’ll write. SELECT tells you what columns to return, FROM specifies which table to query, and WHERE filters the rows.
Once you’ve got these down, you’re well on your way to writing effective SQL queries. Now that I’m getting the hang of this, I think I’m going to do a whole series of shorts on SQL syntax essentials, plus tips and tricks!
Rita the Raccoon Writes SQL
I learned to make short form videos with my drawings this week, and, well… things are about to get weirder. Meet Rita the Raccoon, who’s here to help explain SQL concepts in a way that’s both educational and delightfully unexpected.
This is the first in what I hope will be a fun series of animated SQL tutorials featuring my favorite characters.
Nested Loops
Nested loop join operators tend to look quite innocent in an estimated query execution plan. But life ain’t always so simple. These operators can be fast when working with small datasets, but they can also cause serious performance problems when plans get reused inappropriately or when they’re not optimized.
Understanding when nested loops work well (and when they don’t) is key to troubleshooting slow queries.
Meet the SQL Server Query Optimizer
Meet the SQL Server Query Optimizer, the brain behind every query execution plan. This clever optimizer analyzes your queries and decides the best way to execute them, choosing join operators, index usage, and execution strategies.
Thanks to Erik Darling for pointing out that it needed a little teeth.
Plan Caching in SQL Server v1
I drew out a first visualization of how the shared plan cache in SQL Server is used when you run a query. When SQL Server executes a query, it creates an execution plan and stores it in the plan cache for reuse. This caching mechanism helps performance by avoiding the overhead of recompiling similar queries, but it can also lead to plan reuse problems when the cached plan isn’t optimal for new parameter values.
I’m pretty sure I’ll refine and and elaborate on this in the future, so let’s call this the v1.
Compare SQL Server Isolation levels
Most modern hardware supports RCSI and Snapshot isolation beautifully. These isolation levels help your database scale by allowing readers and writers to work concurrently without blocking each other unnecessarily.
Read Committed Snapshot Isolation (RCSI) provides statement-level consistency, while Snapshot Isolation extends that to transaction-level consistency. Both are excellent choices for modern workloads where you need high concurrency without sacrificing data correctness.
Indexed Views Koala
Indexed views are amazing: they’re like an auto-updating table based on the definition of the view. Whenever rows change in the tables defined in the view, those changes are also applied to the indexed view. This makes them perfect for pre-aggregating data or creating materialized views that stay in sync automatically.
However, that automatic updating comes with a cost: modifications to the underlying tables can become slower because the indexed view must be updated as part of the same transaction.
Exploring optimized locking
SQL Server has a new feature that’s currently only available in Azure SQL Database: Optimized Locking. This capability reduces lock contention by optimizing how locks are acquired and released, potentially improving concurrency for workloads with many concurrent transactions.
It’s a very interesting capability that looks like it could potentially be a great fit for all sorts of SQL Server implementations in the future.
