Database
113 bites tagged Database — interview questions with model answers, and 60-second explainers.
Nested Loop Join: The Brute-Force Database Join
A nested loop join is the brute-force way to match two tables. For each row in the first table, it scans every row in the second. It's simple and effective for small tables but its performance degrades quadratically on large datasets.
Heap File Organization: Fast Writes, Slow Reads
Heap file organization is like tossing records into a box in no particular order. It's great for bulk-loading data quickly, but searching requires a full table scan. The footgun is using it for frequently queried tables, which kills performance.
Row vs. Columnar Storage: Organizing Data for Speed
Row stores group data by record, like a phone book entry. Column stores group by attribute, like separate lists for all names. Use row stores for transactions (OLTP), but for analytics (OLAP), they force you to read unneeded data from disk.
Cardinality Estimation: How Databases Guess Query Costs
A database's query optimizer guesses how many rows each part of a query will return to pick the fastest execution plan. This guess, cardinality estimation, is key for choosing join strategies.
Database Statistics: The Query Optimizer's Internal Map
Database statistics are the raw data the query optimizer uses to guess the cheapest way to run your query. It uses stats like row counts and value distribution to decide between a full table scan and an index seek.
The Query Optimizer: Your Database's Internal GPS
A query optimizer is your database's internal GPS, turning your SQL "what" into the fastest "how." It chooses the best execution plan—like join order or index usage—for every query. The footgun: stale statistics can trick it into picking a slow route.
Query Execution Plan: The Database's Road Map
A query execution plan is the database's internal strategy for fetching your data. It's the recipe it creates before running your SQL. This plan determines whether to use an index or scan a whole table, directly impacting performance.
Timestamp Concurrency Control: No Locks, Just Time
Timestamp-based concurrency control bets that transaction conflicts are rare, using timestamps to order operations instead of locking data. It's used where lock overhead is high, but the footgun is that frequent conflicts can cause transaction starvation.
Strict Two-Phase Locking (S2PL): Safety Over Speed
Strict Two-Phase Locking (S2PL) forces a transaction to hold all its locks until it fully commits or aborts. This prevents cascading aborts in databases but at the cost of concurrency, as other transactions are blocked for longer periods.
Database Deadlock: The Two-Way Standoff
A deadlock is a 'Mexican standoff' where two transactions can't finish because each is waiting for a resource the other has locked. This happens in systems with concurrent writes. The database will kill one transaction, forcing your app to handle the retry.
Write-Ahead Logging (WAL): Survive Crashes by Journaling First
Think of it as a journal of intentions. Before changing data, a database writes the intended change to a log file first. This ensures that if the system crashes, it can recover by replaying the log, guaranteeing no writes are lost.
Lock Now or Check Later: Optimistic vs. Pessimistic Concurrency
Pessimistic concurrency locks data first, assuming conflict is likely ('ask permission'). Optimistic concurrency proceeds without locks and checks for conflicts before saving, assuming they're rare ('ask forgiveness'). Use pessimistic for high-contention.
Fourth Normal Form (4NF): Isolating Independent Facts
4NF prevents storing independent, multi-valued facts in one table. It applies when a key relates to two unrelated lists, like a restaurant's pizza types and its delivery areas.
Third Normal Form (3NF): Nothing But The Key
Third Normal Form (3NF) dictates that every non-key column must describe 'nothing but the key.' This prevents transitive dependencies, where one non-key column determines another.
Functional Dependency: The Rules Behind Your Data
A functional dependency is a rule: if you know column A, you uniquely know column B. It's the logic behind primary keys and is used for database normalization to prevent data duplication.
Entity-Relationship Diagrams: A Blueprint for Your Data
An Entity-Relationship Diagram (ERD) is a blueprint for a database, showing what you're storing and how it connects. It's used before writing code to design a relational database schema. The main footgun is designing the model to match the UI, not the data.
Boyce-Codd Normal Form (BCNF): Stricter Than 3NF
BCNF is a database design rule stricter than 3NF, ensuring no attribute is determined by anything but a superkey. It's used to eliminate all data redundancies from functional dependencies, but can force trade-offs with dependency preservation.
Transaction Isolation Levels: The Concurrency vs. Correctness Dial
Think of isolation levels as a database dial trading transaction correctness for raw concurrency. You tune this when balancing performance against the risk of data anomalies. The footgun: the default level isn't always the safest; you must know its guarantees.
The Relational Model: Data as Simple Tables
The relational model organizes data into simple tables (relations) of rows (tuples), forming the foundation of SQL databases. It's used for structured data where consistency is critical, like in banking.
How a SQL SELECT Query Actually Runs
A SQL SELECT query runs in a different order than you write it. It first builds the dataset with FROM/JOINs and filters it with WHERE, only then computing the final columns in SELECT. This is crucial for debugging.
Querying NoSQL: It Depends on the Data Model
Querying NoSQL isn't one-size-fits-all; the method depends on the data model (key-value, document, graph). This is used for large, unstructured datasets like social feeds. The footgun is assuming SQL works everywhere; many require a model-specific API.
Data Virtualization: One Query, Many Sources
Data virtualization creates a single logical database from many physical sources without moving the data. It's used for real-time integration across silos like SQL, NoSQL, and APIs.
OLAP Cube: Pre-Aggregating Data for Fast Analysis
An OLAP cube is like a Rubik's Cube for your data, pre-calculating answers to complex business questions. It powers BI tools, letting you 'slice and dice' sales data by region and time for fast reports. The footgun: data is typically stale, not real-time.
Global Database: One Logical DB, Multiple Regions
A global database is a single logical database that spans multiple geographic regions, providing fast local reads and disaster recovery. It's used for apps with a worldwide user base that must survive regional outages.
Get Database bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.