Quase todo sistema back-end guarda dados em um banco relacional, e a linguagem para conversar com ele é o SQL. Saber montar um CRUD, entender JOINs e ter noção de transações é conhecimento que você usa todos os dias — e que invariavelmente aparece em entrevistas técnicas.
Tabelas e linhas: o modelo relacional
Um banco relacional organiza dados em tabelas, como planilhas. Cada tabela tem colunas (campos) e linhas (registros). Uma tabela usuarios tem colunas como id, nome, email, e cada usuário é uma linha. O id costuma ser a chave primária: identifica unicamente cada linha.
CRUD: as quatro operações
CRUD significa Create, Read, Update, Delete — e cada uma mapeia para um comando SQL:
-- Create
INSERT INTO usuarios (nome, email)
VALUES ('Ana', 'ana@exemplo.com');
-- Read
SELECT id, nome FROM usuarios WHERE id = 1;
-- Update
UPDATE usuarios SET nome = 'Ana Paula' WHERE id = 1;
-- Delete
DELETE FROM usuarios WHERE id = 1;A cláusula WHERE é crítica: ela filtra quais linhas a operação afeta. Um UPDATE ou DELETE sem WHERE atinge a tabela inteira — um erro perigoso e clássico.
JOIN: combinando tabelas
Dados relacionados ficam em tabelas separadas. Imagine usuarios e pedidos, onde cada pedido tem um usuario_id. Para listar o nome do usuário junto com seus pedidos, usamos JOIN:
SELECT u.nome, p.valor
FROM usuarios u
INNER JOIN pedidos p ON p.usuario_id = u.id;O INNER JOIN traz só as linhas que casam dos dois lados (usuários que têm pedidos). O LEFT JOIN traz todos os usuários, mesmo sem pedidos — nesse caso as colunas de pedido vêm como NULL. Em entrevista é comum pedir para explicar a diferença:
| Tipo | Traz | Uso típico |
|---|---|---|
| INNER JOIN | Só linhas que casam dos dois lados | Usuários que fizeram pedidos |
| LEFT JOIN | Todas da esquerda + casadas da direita | Todos os usuários, com ou sem pedido |
Transações e ACID
Uma transação agrupa vários comandos como uma unidade: ou tudo acontece, ou nada acontece. O exemplo clássico é transferir dinheiro — debitar de uma conta e creditar em outra precisam acontecer juntos:
BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;
COMMIT; -- se algo falhar antes, faz ROLLBACKAs garantias de uma transação resumem-se na sigla ACID: Atomicidade (tudo ou nada), Consistência (o banco sai em estado válido), Isolamento (transações simultâneas não se atrapalham) e Durabilidade (depois do commit, os dados persistem mesmo se a energia cair).
WHERE define o alcance da sua operação e transações definem o alcance da sua segurança. Esquecer qualquer um dos dois é onde os incidentes nascem.
Índices: por que algumas queries voam
Um índice é como o índice remissivo de um livro: em vez de ler página por página, você vai direto ao ponto. Sem índice, buscar WHERE email = 'ana@exemplo.com' obriga o banco a varrer a tabela inteira (full scan). Com um índice na coluna email, a busca é quase instantânea. O custo: índices ocupam espaço e deixam escritas um pouco mais lentas, então não se indexa tudo.
Conclusão
SQL é uma habilidade que rende juros: CRUD com WHERE para o dia a dia, JOINs para conectar dados, transações para garantir integridade e índices para performance. Domine esses quatro pilares e você cobre a esmagadora maioria das tarefas de banco — e das perguntas de entrevista.
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:
| Type | Returns | Typical use |
|---|---|---|
| INNER JOIN | Only rows that match on both sides | Users who placed orders |
| LEFT JOIN | All from the left + matches from the right | All users, with or without orders |
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 ROLLBACKA 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.