Almost every back-end system stores data in a relational database, and the language for talking to it is SQL. Knowing how to build a CRUD, understanding JOINs and having a grasp of transactions is knowledge you use every day — and one that invariably shows up in technical interviews.

Tables and rows: the relational model

A relational database organizes data into tables, like spreadsheets. Each table has columns (fields) and rows (records). A users table has columns such as id, name, email, and each user is a row. The id is usually the primary key: it uniquely identifies each row.

CRUD: the four operations

CRUD stands for Create, Read, Update, Delete — and each one maps to a SQL command:

-- Create
INSERT INTO users (name, email)
VALUES ('Ana', 'ana@example.com');

-- Read
SELECT id, name FROM users WHERE id = 1;

-- Update
UPDATE users SET name = 'Ana Paula' WHERE id = 1;

-- Delete
DELETE FROM users WHERE id = 1;

The WHERE clause is critical: it filters which rows the operation affects. An UPDATE or DELETE without a WHERE hits the entire table — a dangerous, classic mistake.

JOIN: combining tables

Related data lives in separate tables. Imagine users and orders, where each order has a user_id. To list the user's name along with their orders, we use a JOIN:

SELECT u.name, o.amount
FROM users u
INNER JOIN orders o ON o.user_id = u.id;

INNER JOIN returns only the rows that match on both sides (users who have orders). LEFT JOIN returns all users, even without orders — in that case the order columns come back as NULL. In interviews you're often asked to explain the difference:

Transactions and ACID

A transaction groups several commands as a single unit: either everything happens, or nothing does. The classic example is transferring money — debiting one account and crediting another have to happen together:

BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- if anything fails before this, it does a ROLLBACK

A transaction's guarantees boil down to the acronym ACID: Atomicity (all or nothing), Consistency (the database ends up in a valid state), Isolation (concurrent transactions don't interfere with each other) and Durability (after the commit, data persists even if the power goes out).

WHERE defines the reach of your operation and transactions define the reach of your safety. Forgetting either one is where incidents are born.

Indexes: why some queries fly

An index is like a book's index: instead of reading page by page, you go straight to the spot. Without an index, searching WHERE email = 'ana@example.com' forces the database to scan the entire table (a full scan). With an index on the email column, the lookup is nearly instant. The cost: indexes take up space and make writes slightly slower, so you don't index everything.

Conclusion

SQL is a skill that pays compound interest: CRUD with WHERE for day-to-day work, JOINs to connect data, transactions to guarantee integrity and indexes for performance. Master these four pillars and you cover the vast majority of database tasks — and interview questions.