DEV Community: Yuri Peixinho

SQL: JOIN Queries

Yuri Peixinho — Mon, 13 Jul 2026 01:12:49 +0000

Introdução

Bancos de dados relacionais distribuem informações em múltiplas tabelas de propósito — para evitar redundância e garantir integridade. Mas na hora de consultar, frequentemente precisamos de dados que estão espalhados por duas ou mais tabelas. É aí que entram os JOINs: operações que combinam linhas de tabelas distintas com base em uma condição de correspondência.

Para todos os exemplos, usaremos estas duas tabelas:

clientes:
| id | nome        | cidade         |
|----|-------------|----------------|
|  1 | Ana Lima    | São Paulo      |
|  2 | Bruno Melo  | Curitiba       |
|  3 | Carla Nunes | Rio de Janeiro |
|  4 | Diego Costa | Brasília       |

pedidos:
| id | cliente_id | produto  | valor   |
|----|------------|----------|---------|
|  1 | 1          | Notebook | 3500.00 |
|  2 | 1          | Mouse    |   80.00 |
|  3 | 2          | Teclado  |  150.00 |
|  4 | 99         | Monitor  |  900.00 |

Dois detalhes importantes: Diego (id=4) não tem nenhum pedido. E o pedido 4 referencia o cliente_id 99, que não existe na tabela de clientes. Esses casos-limite vão revelar o comportamento de cada tipo de JOIN.

INNER JOIN

Retorna apenas as linhas que têm correspondência nos dois lados. Linhas sem par são descartadas.

SELECT
  c.nome,
  p.produto,
  p.valor
FROM clientes c
INNER JOIN pedidos p ON p.cliente_id = c.id;

| nome       | produto  | valor   |
|------------|----------|---------|
| Ana Lima   | Notebook | 3500.00 |
| Ana Lima   | Mouse    |   80.00 |
| Bruno Melo | Teclado  |  150.00 |

Diego desapareceu — não tem pedidos. O pedido 4 (cliente_id=99) também desapareceu — não tem cliente correspondente. O INNER JOIN é o mais restritivo: só retorna o que existe nos dois lados.

É o tipo de JOIN mais comum, e a palavra INNER é opcional — JOIN sozinho já implica INNER JOIN.

LEFT JOIN

Retorna todas as linhas da tabela da esquerda, com os dados da tabela da direita onde houver correspondência. Onde não houver, os campos da direita vêm como NULL.

SELECT
  c.nome,
  p.produto,
  p.valor
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id= c.id;

| nome        | produto  | valor   |
|-------------|----------|---------|
| Ana Lima    | Notebook | 3500.00 |
| Ana Lima    | Mouse    |   80.00 |
| Bruno Melo  | Teclado  |  150.00 |
| Carla Nunes | NULL     | NULL    |
| Diego Costa | NULL     | NULL    |

Agora Diego e Carla aparecem — sem pedidos, mas presentes. O LEFT JOIN é ideal para perguntas do tipo: "quais clientes ainda não fizeram nenhum pedido?"

SELECT nome
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id= c.id
WHERE p.id IS NULL;

| nome        |
|-------------|
| Carla Nunes |
| Diego Costa |

Filtrar por IS NULL no lado direito após um LEFT JOIN é um padrão clássico para encontrar registros sem correspondência.

RIGHT JOIN

O espelho do LEFT JOIN: retorna todas as linhas da tabela da direita, com os dados da esquerda onde houver correspondência.

SELECT
  c.nome,
  p.produto,
  p.valor
FROM clientes c
RIGHT JOIN pedidos p ON p.cliente_id= c.id;

| nome       | produto  | valor   |
|------------|----------|---------|
| Ana Lima   | Notebook | 3500.00 |
| Ana Lima   | Mouse    |   80.00 |
| Bruno Melo | Teclado  |  150.00 |
| NULL       | Monitor  |  900.00 |

Agora o pedido 4 aparece — com NULL no nome do cliente, pois o cliente_id=99 não existe. Diego e Carla voltam a sumir.

Na prática, RIGHT JOIN é pouco usado — qualquer RIGHT JOIN pode ser reescrito como LEFT JOIN invertendo a ordem das tabelas, o que muitos consideram mais legível. Ele existe por simetria e completude da linguagem.

FULL OUTER JOIN

Combina LEFT e RIGHT: retorna todas as linhas dos dois lados, com NULL onde não houver correspondência.

SELECT
  c.nome,
  p.produto,
  p.valor
FROM clientes c
FULL OUTER JOIN pedidos p ON p.cliente_id= c.id;

| nome        | produto  | valor   |
|-------------|----------|---------|
| Ana Lima    | Notebook | 3500.00 |
| Ana Lima    | Mouse    |   80.00 |
| Bruno Melo  | Teclado  |  150.00 |
| Carla Nunes | NULL     | NULL    |
| Diego Costa | NULL     | NULL    |
| NULL        | Monitor  |  900.00 |

Ninguém é descartado. Clientes sem pedidos aparecem, pedidos sem cliente aparecem. É útil para auditorias e para encontrar inconsistências nos dois lados de uma relação.

Vale saber: o MySQL não suporta FULL OUTER JOIN nativamente. O equivalente é unir um LEFT JOIN com um RIGHT JOIN usando UNION.

Self Join

Um Self Join é quando uma tabela é juntada com ela mesma. Não é um tipo de JOIN diferente — é uma aplicação de qualquer JOIN (geralmente INNER ou LEFT) usando aliases para tratar a mesma tabela como se fossem duas.

O caso de uso mais clássico: uma tabela de funcionários onde cada funcionário tem um gerente_id que referencia outro funcionário na mesma tabela.

funcionarios:
| id | nome       | gerente_id |
|----|------------|------------|
|  1 | Carlos     | NULL       |
|  2 | Ana        | 1          |
|  3 | Bruno      | 1          |
|  4 | Diego      | 2          |

SELECT
  f.nome AS funcionario,
  g.nome AS gerente
FROM funcionarios f
LEFT JOIN funcionarios gON f.gerente_id= g.id;

| funcionario | gerente |
|-------------|---------|
| Carlos      | NULL    |
| Ana         | Carlos  |
| Bruno       | Carlos  |
| Diego       | Ana     |

O alias é obrigatório aqui: f representa o funcionário e g representa o gerente — ambos vindos da mesma tabela. Sem aliases, o banco não saberia a qual instância da tabela cada coluna pertence.

Cross Join

O CROSS JOIN produz o produto cartesiano das duas tabelas: cada linha de A é combinada com cada linha de B. Se A tem 4 linhas e B tem 3, o resultado tem 12 linhas. Não tem cláusula ON — não há condição de correspondência.

SELECT
  c.nome,
  p.produto
FROM clientes c
CROSS JOIN pedidos p;

Isso retornaria 4 × 4 = 16 combinações, incluindo Ana com Monitor e Diego com Notebook — independente de qualquer relação real entre eles.

Na maioria dos casos, um CROSS JOIN acidental em tabelas grandes é catastrófico para a performance. 1.000 linhas × 1.000 linhas = 1 milhão de resultados. Mas há casos de uso legítimos: gerar combinações para testes, preencher uma grade de horários, ou calcular todas as possibilidades de configuração de um produto.

Resumo Visual

Tabela A    Tabela B

INNER JOIN  → apenas a intersecção (correspondência nos dois lados)
LEFT JOIN   → tudo de A + correspondências de B
RIGHT JOIN  → tudo de B + correspondências de A
FULL OUTER  → tudo de A + tudo de B
CROSS JOIN  → todas as combinações possíveis
SELF JOIN   → a tabela junta com ela mesma

JOINs em cadeia

Na prática, consultas reais combinam múltiplos JOINs:

SELECT
  c.nomeAS cliente,
  p.idAS pedido,
  pr.nomeAS produto,
  ip.quantidade,
  ip.quantidade* pr.precoAS subtotal
FROM clientes c
INNER JOIN pedidos pON p.cliente_id= c.id
INNER JOIN itens_pedido ipON ip.pedido_id= p.id
INNER JOIN produtos prON pr.id= ip.produto_id
WHERE c.id= 1
ORDER BY p.id;

Cada JOIN adiciona uma tabela ao contexto da consulta. A ordem importa para legibilidade, mas não para o resultado — o otimizador do banco decide a ordem de execução internamente, independente da ordem em que os JOINs foram escritos.

Modelagem ER (Entidade Relacionamento)

Yuri Peixinho — Mon, 13 Jul 2026 00:53:48 +0000

Introdução

Antes de criar uma única tabela, um banco de dados bem projetado começa no papel. A Modelagem ER é a técnica usada para representar visualmente a estrutura de um domínio — quais coisas existem, quais atributos elas têm, e como se relacionam entre si. É a planta baixa do banco de dados.

O modelo foi proposto por Peter Chen em 1976, num artigo que se tornaria um dos mais citados na história da computação. A ideia central era simples: representar o mundo real através de entidades, atributos e relacionamentos, e fazer isso de forma independente de qualquer banco de dados específico. O diagrama ER é uma linguagem de comunicação entre analistas, desenvolvedores e clientes, antes de qualquer linha de SQL ser escrita.

Entidades

Uma entidade é qualquer coisa do mundo real que tem existência independente e sobre a qual queremos armazenar informações. No diagrama, entidades são representadas por retângulos.

Exemplos de entidades: Cliente, Produto, Pedido, Funcionário, Departamento.

Existe uma distinção importante entre:

Tipo de entidade: a definição abstrata — o conceito de "Cliente"
Instância de entidade: um cliente específico — "Ana Lima, CPF 123.456.789-00"

Quando o modelo é convertido para o banco, o tipo de entidade vira uma tabela e cada instância vira uma linha.

Entidade Forte vs Entidade Fraca

Uma entidade forte tem existência própria — pode ser identificada por seus próprios atributos, independente de qualquer outra entidade. Cliente é uma entidade forte: existe um cliente mesmo sem nenhum pedido.

Uma entidade fraca depende de outra entidade para existir e ser identificada. No diagrama, é representada por um retângulo duplo. Um exemplo clássico: Item de Pedido não existe sem um Pedido — e seu identificador só faz sentido dentro do contexto daquele pedido (item 1 do pedido 10, item 1 do pedido 11 são coisas diferentes, mas têm o mesmo número).

Atributos

Atributos descrevem as propriedades de uma entidade. No diagrama, são representados por elipses conectadas à entidade.

Atributo Simples

Valor único e indivisível. nome, preco, data_nascimento. É o tipo mais comum.

Atributo Composto

Pode ser subdividido em partes menores com significado próprio. endereco pode ser decomposto em rua, numero, cidade, cep. No diagrama, o atributo composto tem sub-elipses conectadas a ele.

Na conversão para tabelas, há uma escolha: manter como coluna única (endereco VARCHAR) ou expandir em colunas separadas (rua, numero, cidade). A decisão depende de se será necessário filtrar ou ordenar por partes do endereço.

Atributo Multivalorado

Pode ter mais de um valor para a mesma entidade. Uma Pessoa pode ter vários telefones. No diagrama, é representado por uma elipse dupla.

Na conversão para tabelas, atributos multivalorados viram tabelas separadas — pois uma coluna não pode guardar múltiplos valores (violaria a 1FN).

CREATE TABLE telefones (
  id INT PRIMARY KEY,
  pessoa_id INT REFERENCES pessoas(id),
  numero VARCHAR(20)
);

Atributo Derivado

Calculado a partir de outro atributo — não é armazenado, é computado. idade é derivado de data_nascimento. No diagrama, é representado por uma elipse tracejada.

Em SQL, atributos derivados podem ser implementados como colunas calculadas ou simplesmente computados na consulta:

SELECT
  nome,
  EXTRACT(YEAR FROM AGE(data_nascimento)) AS idade
FROM pessoas;

Atributo-Chave

O atributo que identifica unicamente cada instância da entidade. No diagrama, é sublinhado. Corresponde à chave primária na tabela.

Relacionamentos

Um relacionamento representa uma associação entre duas ou mais entidades. No diagrama, é representado por um losango conectado às entidades participantes.

[Cliente] ——— <faz> ——— [Pedido]

Assim como entidades, relacionamentos também podem ter atributos. Um relacionamento Matricula entre Aluno e Curso pode ter o atributo data_matricula e nota — valores que pertencem à relação, não a nenhuma das entidades isoladamente.

Grau do Relacionamento

O grau indica quantas entidades participam do relacionamento.

Binário (grau 2): o mais comum. Dois tipos de entidade se relacionam.

[Cliente] ——— <compra> ——— [Produto]

Ternário (grau 3): três entidades participam simultaneamente. Um Médico prescreve um Medicamento para um Paciente — e os três fazem parte do mesmo relacionamento.

Unário (grau 1 / auto-relacionamento): uma entidade se relaciona consigo mesma. Funcionário pode ser gerenciado por outro Funcionário.

[Funcionário] ——— <gerencia> ——— [Funcionário]

Cardinalidade

A cardinalidade define quantas instâncias de uma entidade podem se associar a instâncias da outra. É a informação mais importante de um relacionamento.

1:1 — Um para Um

Cada instância de A se associa a no máximo uma instância de B, e vice-versa.

[Pessoa] ——1—— <tem> ——1—— [Passaporte]

Uma pessoa tem um passaporte; um passaporte pertence a uma pessoa. Na conversão, a chave estrangeira pode ficar em qualquer um dos lados — por convenção, fica na entidade mais fraca ou mais dependente.

1:N — Um para Muitos

Cada instância de A pode se associar a várias de B, mas cada instância de B se associa a apenas uma de A.

[Cliente] ——1—— <faz> ——N—— [Pedido]

Um cliente faz vários pedidos; cada pedido pertence a um cliente. A chave estrangeira sempre fica no lado N — pedidos.cliente_id.

N:N — Muitos para Muitos

Cada instância de A pode se associar a várias de B, e vice-versa.

[Aluno] ——N—— <matricula> ——N—— [Curso]

Um aluno se matricula em vários cursos; um curso tem vários alunos. Na conversão, exige uma tabela de junção — pois não há como representar isso com uma simples chave estrangeira.

CREATE TABLE matriculas (
  aluno_id INT REFERENCES alunos(id),
  curso_id INT REFERENCES cursos(id),
  data_entrada DATE,
  nota_final DECIMAL(4,2),
  PRIMARY KEY (aluno_id, curso_id)
);

Do Diagrama ER ao Esquema Relacional

A conversão segue regras sistemáticas:

Elemento ER	Resultado no banco
Entidade forte	Tabela
Atributo simples	Coluna
Atributo composto	Colunas para cada componente
Atributo multivalorado	Tabela separada com FK
Atributo derivado	Coluna calculada ou consulta
Relacionamento 1:1	FK em um dos lados
Relacionamento 1:N	FK no lado N
Relacionamento N:N	Tabela de junção
Entidade fraca	Tabela com chave composta (PK parcial + FK da forte)
Especialização	Tabela única, por subtipo, ou apenas subtipos

SQL: Data Constraints

Yuri Peixinho — Mon, 13 Jul 2026 00:13:41 +0000

Introdução

Validar dados é uma responsabilidade que pode ficar na aplicação, no banco de dados, ou em ambos. Deixar tudo na aplicação é arriscado: diferentes sistemas podem acessar o mesmo banco, migrações podem rodar diretamente, um bug pode deixar passar um valor inválido. Constraints são regras definidas no próprio banco de dados — uma camada de proteção que age independente de quem está escrevendo os dados.

PRIMARY KEY

A chave primária identifica cada linha de forma única. Ela combina duas restrições implicitamente: NOT NULL e UNIQUE. Nenhuma linha pode ter o mesmo valor de chave primária, e nenhuma pode tê-la nula.

CREATE TABLE clientes (
  id INT PRIMARY KEY,
  nome VARCHAR(100) NOT NULL
);

Quando a chave primária envolve mais de uma coluna, ela é declarada separadamente:

CREATE TABLE matriculas (
  aluno_id INT,
  curso_id INT,
  PRIMARY KEY (aluno_id, curso_id)
);

Na maioria dos bancos, é comum usar uma chave primária auto-incremental para não precisar gerenciar os IDs manualmente:

-- PostgreSQL
id SERIAL PRIMARY KEY

-- MySQL
id INT AUTO_INCREMENTPRIMARY KEY

-- SQL padrão (suportado por ambos)
id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY

FOREIGN KEY

A chave estrangeira garante integridade referencial: um valor só pode existir numa coluna se ele existir como chave primária na tabela referenciada. É o que torna os relacionamentos entre tabelas confiáveis.

CREATE TABLE pedidos (
  id INT PRIMARY KEY,
  cliente_idINT REFERENCES clientes(id)
);

Tentar inserir um pedido com cliente_id = 99 quando não existe cliente com esse id resulta em erro imediato. O banco rejeita a operação antes mesmo de ela chegar ao disco.

O comportamento quando o registro referenciado é deletado pode ser configurado:

CREATE TABLE pedidos (
  id INT PRIMARY KEY,
  cliente_id INT REFERENCES clientes(id)
    ON DELETE CASCADE    -- deleta os pedidos junto com o cliente
    ON UPDATE CASCADE    -- atualiza o cliente_id se o id do cliente mudar
);

As opções disponíveis são:

Opção	Comportamento
`RESTRICT`	Rejeita a operação se houver dependentes (padrão)
`CASCADE`	Propaga a operação para os dependentes
`SET NULL`	Define a FK como nula nos dependentes
`SET DEFAULT`	Define a FK com o valor padrão da coluna

UNIQUE

Garante que todos os valores de uma coluna — ou combinação de colunas — sejam distintos. Diferente da chave primária, uma coluna UNIQUE pode conter NULL (e em geral múltiplos NULL são permitidos, pois NULL não é igual a nada, nem a si mesmo).

CREATE TABLE usuarios (
  id INT PRIMARY KEY,
  email VARCHAR(150) UNIQUE,
  username VARCHAR(50) UNIQUE
);

UNIQUE composto funciona da mesma forma que PRIMARY KEY composto — a restrição se aplica à combinação, não às colunas individualmente:

-- O mesmo aluno pode ter notas em vários cursos,
-- mas não duas notas no mesmo curso
CREATE TABLE notas (
  aluno_id INT,
  curso_id INT,
  notaDECIMAL(4,2),
  UNIQUE (aluno_id, curso_id)
);

NOT NULL

Impede que uma coluna aceite ausência de valor. Simples e direto — mas uma das constraints mais importantes na prática, porque NULL se propaga de formas inesperadas em cálculos e comparações.

CREATE TABLE produtos (
  id INT PRIMARY KEY,
  nomeVARCHAR(100) NOT NULL,
  precoDECIMAL(10,2) NOT NULL,
  descricao TEXT          -- aceita NULL: campo opcional
);

Uma coluna sem NOT NULL aceita NULL por padrão. Definir quais campos são obrigatórios e quais são opcionais é uma decisão de modelagem — e NOT NULL é a forma de documentar e enforçar isso no próprio esquema.

Vale lembrar: AVG, SUM e outras funções de agregação ignoram NULL automaticamente. E comparações com NULL usando = sempre retornam falso — NULL = NULL é falso em SQL; a verificação correta é IS NULL.

CHECK

Permite definir uma condição arbitrária que os valores de uma coluna precisam satisfazer. É a constraint mais flexível — qualquer expressão booleana válida pode ser usada.

CREATE TABLE produtos (
  id INT PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  preco DECIMAL(10,2) NOT NULL CHECK (preco>= 0),
  estoque INT           NOT NULL CHECK (estoque>= 0),
  avaliacao DECIMAL(2,1)CHECK (avaliacaoBETWEEN 0 AND 5)
);

Tentar inserir um produto com preco = -50 vai gerar um erro de violação de constraint antes de qualquer dado ser gravado.

CHECK também pode referenciar múltiplas colunas da mesma linha:

CREATE TABLE descontos (
  id INT PRIMARY KEY,
  preco_original DECIMAL(10,2) NOT NULL,
  preco_final DECIMAL(10,2) NOT NULL,
  CHECK (preco_final<= preco_original)
);

Isso garante que nenhum desconto resulte em preço final maior que o original — uma regra de negócio simples que, sem CHECK, dependeria inteiramente da aplicação para ser respeitada.

Adicionando Constraints depois

Constraints podem ser adicionadas a tabelas existentes com ALTER TABLE:

ALTER TABLE produtos
  ADD CONSTRAINT chk_preco CHECK (preco>= 0);

ALTER TABLE pedidos
  ADD CONSTRAINT fk_cliente
  FOREIGN KEY (cliente_id) REFERENCES clientes(id);

E removidas quando necessário:

ALTER TABLE produtos DROP CONSTRAINT chk_preco;

Por que usar Constraints

A alternativa às constraints é validar tudo na aplicação. O problema é que a aplicação não é a única forma de os dados chegarem ao banco — migrações, scripts de manutenção, ferramentas de BI, outros serviços. Constraints garantem que independente da origem, os dados respeitem as regras. É a diferença entre confiar que ninguém vai errar e tornar o erro impossível.

SQL: Aggregate Queries

Yuri Peixinho — Mon, 13 Jul 2026 00:07:59 +0000

Introdução

Consultas individuais respondem perguntas como "qual o email do cliente 42?". Mas as perguntas mais valiosas em qualquer sistema são de outro tipo: "qual o produto mais vendido?", "qual a receita média por pedido?", "quantos clientes se cadastraram esse mês?". Para responder isso, o SQL oferece as funções de agregação — operações que recebem um conjunto de linhas e devolvem um único valor resumido.

Para os exemplos a seguir, considere esta tabela:

pedidos:
| id | cliente    | produto     | categoria    | quantidade | valor  |
|----|------------|-------------|--------------|------------|--------|
|  1 | Ana Lima   | Notebook    | Eletrônicos  | 1          | 3500.00|
|  2 | Ana Lima   | Mouse       | Periféricos  | 2          |   80.00|
|  3 | Bruno Melo | Teclado     | Periféricos  | 1          |  150.00|
|  4 | Bruno Melo | Notebook    | Eletrônicos  | 1          | 3500.00|
|  5 | Carla Nunes| Monitor     | Eletrônicos  | 2          | 1200.00|
|  6 | Carla Nunes| Mouse       | Periféricos  | 1          |   80.00|

As Funções de Agregação

COUNT

Conta o número de linhas — ou de valores não nulos em uma coluna específica.

-- Total de pedidos
SELECT COUNT(*)AS total_pedidosFROM pedidos;
-- Resultado: 6

-- Clientes distintos que fizeram pedidos
SELECT COUNT(DISTINCT cliente) AS clientes_unicosFROM pedidos;
-- Resultado: 3

COUNT(*) conta todas as linhas, incluindo as que têm nulos. COUNT(coluna) conta apenas as linhas onde aquela coluna não é nula. COUNT(DISTINCT coluna) conta valores únicos — útil para saber quantos clientes, produtos ou categorias distintos aparecem no resultado.

SUM

Soma os valores de uma coluna numérica.

-- Receita total
SELECT SUM(valor) AS receita_total FROM pedidos;
-- Resultado: 8510.00

-- Total de itens vendidos
SELECT SUM(quantidade) AS itens_vendidos FROM pedidos;
-- Resultado: 8

AVG

Calcula a média aritmética dos valores.

-- Valor médio por pedido
SELECT AVG(valor) AS ticket_medio FROM pedidos;
-- Resultado: 1418.33

AVG ignora valores nulos automaticamente — calcula a média apenas sobre os registros que têm valor preenchido naquela coluna.

MIN e MAX

Retornam o menor e o maior valor de uma coluna, respectivamente. Funcionam com números, datas e texto.

SELECT
  MIN(valor) AS pedido_minimo,
  MAX(valor) AS pedido_maximo
FROM pedidos;
-- Resultado: 80.00 | 3500.00

Com datas, MIN retorna a data mais antiga e MAX a mais recente — útil para saber o primeiro e o último evento de um conjunto.

GROUP BY

Funções de agregação sem GROUP BY resumem a tabela inteira em uma linha. Com GROUP BY, elas resumem por grupo — calculando um resultado para cada valor distinto da coluna agrupada.

-- Receita total por categoria
SELECT
  categoria,
  SUM(valor) AS receita
FROM pedidos
GROUP BY categoria;

| categoria   | receita |
|-------------|---------|
| Eletrônicos | 8200.00 |
| Periféricos |  310.00 |

É possível agrupar por múltiplas colunas:

-- Receita por cliente e categoria
SELECT
  cliente,
  categoria,
  SUM(valor) AS receita,
  COUNT(*) AS pedidos
FROM pedidos
GROUP BY cliente, categoria
ORDER BY cliente, receitaDESC;

| cliente     | categoria   | receita | pedidos |
|-------------|-------------|---------|---------|
| Ana Lima    | Eletrônicos | 3500.00 | 1       |
| Ana Lima    | Periféricos |  160.00 | 1       |
| Bruno Melo  | Eletrônicos | 3500.00 | 1       |
| Bruno Melo  | Periféricos |  150.00 | 1       |
| Carla Nunes | Eletrônicos | 2400.00 | 1       |
| Carla Nunes | Periféricos |   80.00 | 1       |

Uma regra importante: toda coluna no SELECT que não é uma função de agregação precisa estar no GROUP BY. O banco precisa saber como agrupar — se você seleciona cliente e categoria mas agrega por apenas um, ele não sabe qual valor exibir para o outro.

HAVING

WHERE filtra linhas antes da agregação. HAVING filtra grupos depois da agregação. São complementares, não concorrentes.

-- Apenas clientes com receita total acima de 1000
SELECT
  cliente,
  SUM(valor) AS receita_total
FROM pedidos
GROUP BY cliente
HAVING SUM(valor)> 1000;

| cliente     | receita_total |
|-------------|---------------|
| Ana Lima    | 3580.00       |
| Bruno Melo  | 3650.00       |
| Carla Nunes | 2480.00       |

A diferença entre WHERE e HAVING fica clara quando os dois aparecem juntos:

-- Receita por cliente, considerando apenas pedidos de Eletrônicos,
-- e mostrando apenas quem passou de 2000
SELECT
  cliente,
  SUM(valor)AS receita
FROM pedidos
WHERE categoria = 'Eletrônicos'   -- filtra linhas antes de agrupar
GROUP BY cliente
HAVING SUM(valor) > 2000;-- filtra grupos depois de agregar

| cliente     | receita |
|-------------|---------|
| Ana Lima    | 3500.00 |
| Bruno Melo  | 3500.00 |
| Carla Nunes | 2400.00 |

Carla passou porque seus R$ 2.400 em Eletrônicos superam o limite de R$ 2.000. Se o limite fosse R$ 3.000, apenas Ana e Bruno apareceriam.

A Ordem de Execução

Entender a ordem em que o SQL processa as cláusulas explica por que HAVING existe como cláusula separada do WHERE:

1. FROM       → identifica a tabela
2. WHERE      → filtra as linhas brutas
3. GROUP BY   → agrupa as linhas restantes
4. HAVING     → filtra os grupos formados
5. SELECT     → calcula as expressões e funções
6. ORDER BY   → ordena o resultado final
7. LIMIT      → recorta a quantidade retornada

WHERE atua antes da agregação existir — por isso não é possível usar uma função de agregação dentro do WHERE. Tentar WHERE SUM(valor) > 1000 resulta em erro. Para filtrar por resultado de agregação, o lugar certo é sempre o HAVING.

SQL: Normalização e Formas Normais

Yuri Peixinho — Sun, 12 Jul 2026 23:15:52 +0000

Introdução

Imagine uma planilha onde cada linha de um pedido guarda também o nome do cliente, o email, a cidade, o nome do produto e a categoria — tudo junto. Funciona no começo. Mas conforme o sistema cresce, começam a aparecer problemas silenciosos: dados duplicados, inconsistências difíceis de rastrear, operações que quebram coisas inesperadas. A normalização existe para eliminar esses problemas sistematicamente.

Proposta por Codd nos anos 1970 e formalizada ao longo das décadas seguintes, a normalização é um processo de reorganização do esquema em formas normais progressivas — cada uma corrigindo uma classe específica de problema.

O problema: Anomalias

Antes de ver as soluções, vale entender o que está sendo resolvido. Um esquema mal estruturado produz três tipos de anomalia.

Considere esta tabela que mistura informações de pedidos, clientes e produtos:

| pedido_id | cliente    | cliente_cidade | produto     | categoria    | qtd | preco   |
|-----------|------------|----------------|-------------|--------------|-----|---------|
| 1         | Ana Lima   | São Paulo      | Notebook    | Eletrônicos  | 1   | 3500.00 |
| 1         | Ana Lima   | São Paulo      | Mouse       | Periféricos  | 2   |   80.00 |
| 2         | Bruno Melo | Curitiba       | Notebook    | Eletrônicos  | 1   | 3500.00 |

Anomalia de atualização: se Ana Lima mudar de cidade, é preciso atualizar todas as linhas onde ela aparece. Esquecer uma cria inconsistência — o mesmo cliente com duas cidades diferentes no banco.

Anomalia de inserção: não é possível cadastrar um produto sem vinculá-lo a um pedido. O produto não existe de forma independente nesse esquema.

Anomalia de exclusão: se o pedido 2 for deletado, os dados do Notebook somem junto — mesmo que o produto exista em outros contextos.

Esses são os sintomas de um esquema não normalizado. As formas normais são o tratamento.

Primeira Forma Normal — 1FN

Regra: cada coluna deve conter um valor atômico — indivisível. Não pode haver listas, conjuntos ou grupos repetidos dentro de uma célula.

Um exemplo que viola 1FN:

| pedido_id | cliente  | produtos                    |
|-----------|----------|-----------------------------|
| 1         | Ana Lima | Notebook, Mouse, Teclado    |

A coluna produtos guarda múltiplos valores numa célula só. Isso parece conveniente, mas impossibilita filtrar pedidos que contenham um produto específico sem recorrer a gambiarras com LIKE.

A correção é expandir cada valor em sua própria linha:

| pedido_id | cliente  | produto  |
|-----------|----------|----------|
| 1         | Ana Lima | Notebook |
| 1         | Ana Lima | Mouse    |
| 1         | Ana Lima | Teclado  |

Além de valores atômicos, 1FN exige que cada linha seja única — o que leva naturalmente à definição de uma chave primária.

Segunda Forma Normal — 2FN

Regra: estar em 1FN e não ter dependências parciais — todo atributo não-chave deve depender da chave primária inteira, não de apenas parte dela.

Essa forma só é relevante quando a chave primária é composta. Considere:

| pedido_id | produto_id | produto_nome | cliente    | quantidade |
|-----------|------------|--------------|------------|------------|
| 1         | 10         | Notebook     | Ana Lima   | 1          |
| 1         | 11         | Mouse        | Ana Lima   | 2          |
| 2         | 10         | Notebook     | Bruno Melo | 1          |

A chave primária é (pedido_id, produto_id). Mas produto_nome depende apenas de produto_id — não precisa do pedido_id para ser determinado. E cliente depende apenas de pedido_id. Essas são dependências parciais.

A solução é separar em tabelas distintas, onde cada atributo depende da chave inteira da sua tabela:

-- Cada tabela tem sua própria identidade
CREATE TABLE produtos (
  idINT PRIMARY KEY,
  nomeVARCHAR(100)
);

CREATE TABLE pedidos (
  idINT PRIMARY KEY,
  cliente_idINT REFERENCES clientes(id)
);

CREATE TABLE itens_pedido (
  pedido_idINT REFERENCES pedidos(id),
  produto_idINT REFERENCES produtos(id),
  quantidadeINT,
  PRIMARY KEY (pedido_id, produto_id)
);

Agora produto_nome vive em produtos, cliente vive em pedidos, e itens_pedido guarda apenas o que é realmente da relação entre pedido e produto.

Terceira Forma Normal — 3FN

Regra: estar em 2FN e não ter dependências transitivas — nenhum atributo não-chave pode depender de outro atributo não-chave.

Exemplo:

| produto_id | nome     | categoria_id | categoria_nome |
|------------|----------|--------------|----------------|
| 10         | Notebook | 1            | Eletrônicos    |
| 11         | Mouse    | 2            | Periféricos    |

Aqui, categoria_nome não depende de produto_id diretamente — depende de categoria_id, que por sua vez depende de produto_id. Isso é uma dependência transitiva: produto_id → categoria_id → categoria_nome.

O problema: se o nome da categoria "Eletrônicos" precisar mudar, será necessário atualizar todos os produtos dessa categoria. E se não houver nenhum produto numa categoria, ela não pode ser armazenada.

A solução, novamente, é separar:

CREATE TABLE categorias (
  idINT PRIMARY KEY,
  nomeVARCHAR(100)
);

CREATE TABLE produtos (
  idINT PRIMARY KEY,
  nomeVARCHAR(100),
  categoria_idINT REFERENCES categorias(id)
);

Agora categoria_nome vive onde pertence, e os produtos referenciam a categoria por chave estrangeira.

Forma Normal de Boyce-Codd — BCNF

A BCNF é uma versão mais rigorosa da 3FN, proposta em 1974 por Raymond Boyce e o próprio Codd. A diferença é sutil mas importante: na 3FN, há exceções para dependências envolvendo chaves candidatas. A BCNF elimina essas exceções.

Regra: para cada dependência funcional X → Y, X deve ser uma chave candidata.

Na prática, a maioria dos esquemas bem projetados que atingem 3FN já satisfaz a BCNF. Os casos que violam BCNF mas não 3FN são relativamente raros — envolvem tabelas com múltiplas chaves candidatas sobrepostas.

4FN e 5FN

Existem formas normais além da BCNF, que tratam de casos ainda mais específicos. A 4FN lida com dependências multivaloradas — quando um atributo determina múltiplos valores independentes de outro atributo. A 5FN trata de dependências de junção. Na prática do desenvolvimento cotidiano, chegar à 3FN ou BCNF já resolve a grande maioria dos problemas. A 4FN e 5FN aparecem em modelagens muito específicas ou acadêmicas.

Desnormalização

Normalizar é bom, mas normalizar demais pode ser um problema de desempenho. Uma consulta que precisa juntar seis tabelas para montar um relatório vai ser mais lenta do que uma que lê uma tabela única já consolidada.

Desnormalização é a decisão deliberada de violar uma forma normal em prol de desempenho. É comum em sistemas de analytics e data warehouses, onde leituras são muito mais frequentes que escritas, e a redundância de dados é um custo aceitável em troca de consultas mais rápidas.

A diferença entre um banco mal projetado e um banco desnormalizado intencionalmente é exatamente essa: consciência. Desnormalizar sem entender as formas normais é acidente. Desnormalizar conhecendo os trade-offs é arquitetura.

Data Manipulation Language (DML)

Yuri Peixinho — Sun, 12 Jul 2026 23:15:17 +0000

Introdução

DML é o conjunto de comandos que os usuários e aplicações usam no dia a dia: consultar, inserir, atualizar e deletar dados. Se o DDL define o esquema, o DML é o que acontece dentro dele ao longo de toda a vida do sistema.

SELECT

O comando mais usado em SQL. Consulta dados de uma ou mais tabelas.

SELECT nome, email
FROM clientes
WHERE criado_em>= '2024-01-01'
ORDER BY nomeASC;

O SELECT é composto por cláusulas que se encaixam numa ordem lógica:

Cláusula	Função
`FROM`	Define de onde os dados vêm
`WHERE`	Filtra as linhas antes de agrupar
`JOIN`	Combina dados de outras tabelas
`GROUP BY`	Agrupa linhas por um critério
`HAVING`	Filtra grupos (depois do `GROUP BY`)
`ORDER BY`	Ordena o resultado final

Um exemplo com mais cláusulas:

SELECT
  c.nome,
  COUNT(p.id)AS total_pedidos,
  SUM(p.valor)AS valor_total
FROM clientes c
JOIN pedidos pON p.cliente_id= c.id
WHERE p.criado_em>= '2024-01-01'
GROUP BY c.nome
HAVING SUM(p.valor)> 1000
ORDER BY valor_totalDESC;

Este SELECT retorna clientes que, desde 2024, acumularam mais de R$ 1.000 em pedidos — ordenados do maior para o menor.

INSERT

Adiciona novos registros a uma tabela.

-- Inserindo um registro
INSERT INTO clientes (id, nome, email)
VALUES (1,'Ana Lima','ana@email.com');

-- Inserindo vários de uma vez
INSERT INTO clientes (id, nome, email)
VALUES
  (2,'Bruno Melo','bruno@email.com'),
  (3,'Carla Nunes','carla@email.com');

UPDATE

Altera registros já existentes. Sempre use WHERE — sem ele, o UPDATE afeta todas as linhas da tabela.

UPDATE clientes
SET email= 'ana.lima@email.com'
WHERE id= 1;

DELETE

Remove registros. Assim como o UPDATE, exige atenção ao WHERE.

DELETE FROM clientes
WHERE id= 3;

Diferente do TRUNCATE, o DELETE processa linha por linha, dispara triggers e pode ser revertido dentro de uma transação — o que o torna mais seguro, mas mais lento em volumes grandes.

Data Definition Language (DDL)

Yuri Peixinho — Sun, 12 Jul 2026 23:15:02 +0000

Introdução

DDL é o conjunto de comandos responsável por definir e modificar a estrutura do banco de dados: criar tabelas, alterar colunas, remover objetos. Operações DDL geralmente são irreversíveis — um DROP TABLE não pede confirmação, ele simplesmente executa.

CREATE TABLE

Cria uma nova tabela com suas colunas, tipos de dados e restrições.

CREATE TABLE clientes (
  id INT PRIMARY KEY,
  nomeVARCHAR(100) NOT NULL,
  emailVARCHAR(150) UNIQUE,
  criado_em DATE DEFAULT CURRENT_DATE
);

Neste exemplo, id é a chave primária, nome não pode ser nulo, email deve ser único em toda a tabela, e criado_em recebe a data atual automaticamente se nenhum valor for informado.

ALTER TABLE

Modifica uma tabela já existente — adiciona colunas, remove, renomeia, ou altera tipos.

-- Adicionando uma coluna nova
ALTER TABLE clientes ADD COLUMN telefoneVARCHAR(20);

-- Removendo uma coluna
ALTER TABLE clientes DROP COLUMN telefone;

-- Renomeando uma coluna
ALTER TABLE clientes RENAME COLUMN nomeTO nome_completo;

ALTER TABLE é o comando mais usado em migrações de banco de dados — toda vez que o sistema evolui e o esquema precisa acompanhar.

DROP TABLE

Remove uma tabela completamente, junto com todos os seus dados.

DROP TABLE clientes;

Sem volta. Por isso, em ambientes de produção, é comum exigir backups antes de executar qualquer DROP.

TRUNCATE TABLE

Remove todos os registros de uma tabela, mas preserva a estrutura dela.

TRUNCATE TABLE clientes;

A diferença para um DELETE sem cláusula WHERE é de desempenho: o TRUNCATE não processa linha por linha, ele simplesmente descarta o conteúdo inteiro de uma vez, sendo muito mais rápido em tabelas grandes. Em contrapartida, não dispara triggers e em vários bancos não pode ser revertido.

SQL Keyword, Tipos de Dados & Operators

Yuri Peixinho — Sun, 12 Jul 2026 22:24:38 +0000

Introdução

Keywords são as palavras reservadas da linguagem, termos com significado especial que o banco de dados reconhece e interpreta. Elas formam a espinha dorsal de qualquer instrução SQL.

Por convenção, keywords são escritas em maiúsculas, embora o SQL seja case-insensitive. select funciona igual a SELECT, mas o uso de maiúsculas é uma convenção amplamente adotada que melhora a legibilidade, deixando claro o que é comando e o que é nome de tabela ou coluna.

As principais keywords se organizam por função:

Categoria	Keywords
Consulta	`SELECT`, `FROM`, `WHERE`, `ORDER BY`, `GROUP BY`, `HAVING`, `LIMIT`
Junção	`JOIN`, `INNER JOIN`, `LEFT JOIN`, `ON`
Manipulação	`INSERT`, `UPDATE`, `DELETE`, `INTO`, `VALUES`, `SET`
Estrutura	`CREATE`, `ALTER`, `DROP`, `TABLE`, `INDEX`
Auxiliares	`AS`, `DISTINCT`, `NULL`, `NOT NULL`, `DEFAULT`, `AND`, `OR`, `IN`, `LIKE`

Nomes de tabelas e colunas não podem ser keywords reservadas, ou, se forem, precisam ser envolvidos em aspas ou colchetes dependendo do banco. Chamar uma coluna de order ou select, por exemplo, vai causar um erro de sintaxe.

Tipos de Dados

Ao criar uma tabela, cada coluna precisa de um tipo de dado. Esse tipo define o que pode ser armazenado ali, e o banco de dados garante que nenhum valor inválido seja inserido. É a primeira camada de validação dos dados.

Numéricos

id INT           -- inteiro, de -2 bilhões a 2 bilhões
populacao BIGINT        -- inteiro grande, para números acima de 2 bilhões
preco DECIMAL(10,2) -- número exato com 10 dígitos, 2 decimais (ideal para dinheiro)
peso FLOAT         -- número de ponto flutuante (menos preciso, mais rápido)

DECIMAL é preferível para valores monetários porque não tem os erros de arredondamento do FLOAT. FLOAT(1.1) + FLOAT(2.2) pode resultar em 3.3000000000000003 — um problema clássico de ponto flutuante.

Texto

nome VARCHAR(100)-- texto de tamanho variável, até 100 caracteres
sigla CHAR(2)-- texto de tamanho fixo, sempre 2 caracteres
descricao TEXT          -- texto longo sem limite definido

CHAR ocupa espaço fixo independente do conteúdo — CHAR(2) para 'SP' e para 'A' ocupa o mesmo espaço. VARCHAR ocupa só o necessário, sendo mais eficiente para campos de tamanho variável.

Data e Hora

nascimento DATE        -- apenas data: 1990-04-15
abertura TIME        -- apenas hora: 09:30:00
criado_em TIMESTAMP   -- data e hora: 2024-03-10 14:22:00

Booleano e Nulo

ativo BOOLEAN       -- TRUE ou FALSE
apelido VARCHAR(50)-- pode receber NULL (ausência de valor)

NULL não é um tipo, mas um estado — significa que o valor é desconhecido ou ausente. É diferente de zero ou de uma string vazia. Uma coluna sem NOT NULL aceita NULL por padrão.

Operators

Operadores são os símbolos e palavras usados para comparar, combinar e filtrar valores dentro de uma consulta. Eles aparecem principalmente na cláusula WHERE.

Comparação

WHERE preco= 99.90       -- igual
WHERE preco!= 99.90      -- diferente (também pode ser <>)
WHERE preco> 50          -- maior que
WHERE preco<= 100        -- menor ou igual

Lógicos

Combinam múltiplas condições:

WHERE preco> 50 AND estoque> 0         -- ambas verdadeiras
WHERE cidade= 'SP' OR cidade= 'RJ'     -- pelo menos uma verdadeira
WHERE NOT ativo-- inverte a condição

BETWEEN, IN e LIKE

-- BETWEEN: intervalo inclusivo
WHERE precoBETWEEN 50 AND 200

-- IN: pertence a uma lista
WHERE cidadeIN ('SP','RJ','BH')

-- LIKE: correspondência de padrão
WHERE nomeLIKE 'Ana%'     -- começa com "Ana"
WHERE emailLIKE '%@gmail%' -- contém "@gmail"
WHERE codigoLIKE 'BR_'    -- "BR" seguido de exatamente um caractere

No LIKE, % substitui qualquer sequência de caracteres e _ substitui exatamente um caractere.

IS NULL / IS NOT NULL

WHERE telefoneIS NULL       -- campo sem valor
WHERE telefoneIS NOT NULL   -- campo preenchido

Nunca use = NULL — isso não funciona em SQL. O operador de igualdade não consegue comparar com NULL; use sempre IS NULL.

Introduzindo SQL

Yuri Peixinho — Sun, 12 Jul 2026 21:45:30 +0000

O que é SQL?

SQL (Structured Query Language) é uma linguagem de programação utilizada para gerenciar e manipular dados armazenados em sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Ela permite recuperar, inserir, atualizar e excluir dados, bem como definir esquemas de banco de dados e controlar o acesso aos dados. A compreensão básica de SQL é fundamental para interagir com praticamente qualquer banco de dados.

Bancos de dados Relacionais

Em 1970, o cientista da computação Edgar F. Codd publicou um artigo que mudaria para sempre a forma como armazenamos e consultamos dados. Nele, propunha organizar informações em estruturas tabulares — linhas e colunas — conectadas entre si por meio de relacionamentos lógicos. Nascia ali o modelo relacional, base de praticamente todo sistema de software corporativo que conhecemos hoje.

Um banco de dados relacional armazena dados em tabelas. Cada tabela representa uma entidade do mundo real: clientes, pedidos, produtos. Cada linha é um registro individual, e cada coluna descreve um atributo desse registro. O que torna o modelo poderoso não é apenas a organização em tabelas, mas a capacidade de relacioná-las — uma tabela de pedidos pode referenciar a tabela de clientes por meio de uma chave estrangeira, evitando duplicação e garantindo que os dados permaneçam consistentes.

Essa consistência é garantida por um conjunto de propriedades conhecido pela sigla ACID: as operações são atômicas (ou tudo acontece, ou nada acontece), o banco sempre transita entre estados válidos, transações concorrentes não interferem entre si, e dados confirmados persistem mesmo diante de falhas. São essas garantias que tornam os SGBDRs a escolha natural para sistemas financeiros, hospitalares e qualquer domínio onde a integridade dos dados não é negociável.

PostgreSQL, MySQL, Oracle Database e SQL Server são os representantes mais conhecidos dessa família. Cada um com suas particularidades, mas todos falando a mesma língua: o SQL.

Benefícios e Limitações dos SGBDRs

Por décadas, o modelo relacional foi sinônimo de banco de dados. E com razão: ele resolve de forma elegante um problema difícil, que é manter grandes volumes de dados organizados, íntegros e acessíveis de forma eficiente.

A linguagem SQL, padronizada e amplamente dominada pela indústria, permite expressar consultas complexas com poucas linhas. Um JOIN entre três tabelas que retorna exatamente os dados necessários, filtrados e ordenados, é algo que o modelo relacional faz com naturalidade. Somado a décadas de otimização dos engines, ferramentas maduras de administração e uma comunidade enorme, o SGBDR é uma das tecnologias mais confiáveis que existem.

Mas toda escolha tem um custo. O modelo relacional exige que o esquema seja definido antes de armazenar os dados — e alterar esse esquema em produção pode ser uma operação delicada e cara. Em sistemas que evoluem rápido, ou cujos dados não têm forma bem definida, essa rigidez vira um obstáculo.

Há também uma questão de escala. SGBDRs foram projetados para crescer verticalmente: quando o banco fica lento, você coloca mais memória, mais CPU, um disco mais rápido. Essa estratégia tem um limite físico e financeiro. Distribuir um banco relacional entre dezenas de servidores — escala horizontal — é tecnicamente possível, mas complexo, e vai contra a natureza do modelo. Para aplicações que precisam atender centenas de milhões de usuários com latência mínima, essa limitação se torna crítica.

SQL vs. NoSQL

À medida que a internet cresceu, ficou evidente que o modelo relacional não era a resposta para todos os problemas. O ponto de virada aconteceu nos anos 2000, quando empresas como Google e Amazon começaram a enfrentar volumes de dados que nenhum SGBDR tradicional suportava adequadamente. Em 2006, o Google publicou o paper do Bigtable. Em 2007, a Amazon publicou o paper do Dynamo. Em 2008, o Facebook abriu o código do Cassandra, desenvolvido internamente para gerenciar a caixa de entrada de seus usuários. O termo "NoSQL" foi popularizado em uma meetup em San Francisco, em junho de 2009 — e a partir daí o movimento tomou forma.

A motivação era clara: estima-se que cerca de 80% de todos os dados gerados hoje são não estruturados — mensagens, imagens, logs, dados de sensores, eventos de clique. Esse tipo de dado não cabe naturalmente em linhas e colunas de uma tabela relacional. Surgiu então o NoSQL, que mais do que uma negação do SQL, significa "Not Only SQL": uma expansão do repertório de soluções disponíveis.

NoSQL não é um único tipo de banco de dados, mas uma família de abordagens. Os bancos de documentos, como MongoDB, armazenam dados em formato JSON sem esquema fixo — ideais para catálogos e perfis de usuário. Os bancos de chave-valor, como Redis, operam como dicionários extremamente rápidos, perfeitos para cache e sessões. Os bancos de coluna larga, como Cassandra, foram construídos para escalar horizontalmente: o Netflix, por exemplo, usa Cassandra para processar mais de 1 trilhão de operações por dia. E os bancos de grafo, como Neo4j, modelam entidades e relacionamentos de forma nativa — a base de qualquer sistema de recomendação ou rede social.

A grande concessão do NoSQL está na consistência. O teorema CAP, formulado por Eric Brewer em 2000, estabelece que um sistema distribuído não pode garantir simultaneamente consistência, disponibilidade e tolerância a partições de rede — é preciso abrir mão de um. A maioria dos sistemas NoSQL escolhe disponibilidade e tolerância a partições, adotando o modelo BASE: a consistência é eventual, podendo levar alguns milissegundos até que todos os nós do cluster reflitam o novo valor. Para uma rede social, isso é aceitável. Para um sistema bancário, não.

A escolha entre SQL e NoSQL, portanto, não é uma questão de qual é melhor — é de qual serve melhor ao problema. O Stack Overflow Developer Survey de 2023 mostra PostgreSQL como banco de dados mais utilizado no mundo, com 45% dos desenvolvedores, enquanto MongoDB lidera entre os NoSQL com 28%. Esses números dizem algo importante: os dois modelos coexistem, e cada um domina onde faz sentido dominar.

Na prática, sistemas modernos raramente escolhem apenas um lado. É comum usar PostgreSQL para os dados transacionais do negócio, Redis para cache de sessões e MongoDB para conteúdo dinâmico. A Amazon, que concluiu em 2019 a migração completa de seus sistemas internos para fora do Oracle — economizando cerca de US$ 1 bilhão por ano —, hoje oferece mais de quinze tipos diferentes de banco de dados na AWS. Cada ferramenta, no lugar onde ela brilha.

Aprendendo os Fundamentos Técnicos

Antes de escrever consultas complexas, é preciso dominar o vocabulário básico do SQL. Esses quatro elementos: palavras-chave, tipos de dados, operadores e sintaxe, são a gramática da linguagem. Entendê-los bem é o que separa quem decora comandos de quem realmente entende o que está escrevendo.

Descomplicando o Vite

Yuri Peixinho — Sat, 20 Jun 2026 21:36:30 +0000

Introdução

Antes do Vite, ferramentas como Webpack/CRA funcionavam assim: pra você ver qualquer coisa no navegador, a ferramenta precisava primeiro empacotar (bundlar) todo o seu projeto — ler cada arquivo, resolver cada import, transformar tudo num (ou poucos) arquivo gigante de JS. Em projetos pequenos isso é rápido. Em projetos com milhares de módulos, esse "bundle inicial" podia levar dezenas de segundos, e toda vez que você salvava um arquivo, boa parte disso precisava ser refeito.

A sacada do Vite: navegadores modernos já sabem importar módulos ES nativamente (<script type="module">, import/export direto no browser). Então, em desenvolvimento, por que bundlar nada? O Vite simplesmente serve cada arquivo como um módulo separado, sob demanda, só quando o navegador pede.

Comparação com restaurante

Imagina um restaurante de buffet self-service. Antes de abrir as portas pro primeiro cliente, o chef precisa cozinhar o cardápio inteiro — todos os pratos, todas as guarnições, tudo, mesmo que você só queira um cafezinho. Só depois que tudo está pronto na bandeja é que a porta abre.

Agora imagina que você é cliente fiel, vai lá todo dia, e pede pra trocar uma pitada de sal num prato. O que o chef faz? Ele não troca só o sal — ele manda o prato inteiro de volta pra cozinha, refaz boa parte do buffet de novo, porque os pratos dependem uns dos outros (o molho usa o tempero, a guarnição usa o molho...). E você, sentado na mesa, fica esperando o buffet inteiro reabrir.

Isso é literalmente o Webpack clássico/CRA: antes de você ver qualquer coisa no navegador, ele precisa empacotar (bundlar) o projeto inteiro. E cada vez que você salva um arquivo, ele recalcula um bundle gigante de novo — quanto maior o projeto, mais demorado fica reabrir as portas.

Solução

Agora o Vite. É um restaurante à la carte. A porta abre na hora, sem ninguém cozinhar nada antes. Você senta, olha o cardápio (o index.html), e pede só o que quer — "garçom, me traz o main.tsx". O garçom vai até a cozinha, o chef prepara só esse prato, na hora, e te entrega. Você come e pede a sobremesa (App.tsx)? Aí sim ele prepara a sobremesa — só ela, não o cardápio inteiro de novo.

As duas fases do Vite

Isso é a ideia central: o Vite usa estratégias diferentes pra cada momento porque os dois momentos têm necessidades opostas.

	Desenvolvimento (`vite`/`vite dev`)	Produção (`vite build`)
Estratégia	Serve módulos ESM nativos, sem bundlar	Empacota tudo via Rolldown (bundler em Rust)
Velocidade de start	Instantânea, não depende do tamanho do projeto	Leva o tempo proporcional ao projeto
Por quê essa diferença	Em dev, poucas requisições HTTP locais não importam — rede é instantânea	Em produção, centenas de arquivos separados = centenas de requisições HTTP reais pro usuário final, isso é ruim. Bundlar reduz isso

CLI Tools

Yuri Peixinho — Sat, 20 Jun 2026 21:36:11 +0000

Introdução

CLI = Command Line Interface. É um jeito de controlar um programa digitando texto, em vez de clicar em ícones e janelas (isso seria uma GUI — Graphical User Interface). Você digita um comando, aperta Enter, o programa executa e devolve uma resposta em texto. Não é algo específico de JavaScript ou web — ls, cd, git, curl, python, docker são todas CLIs, e existem desde muito antes da internet existir.

A anatomia de um comando

Quase todo comando de terminal segue essa estrutura:

comando subcomando --flag valor argumento
   │        │          │      │      │
  git     commit      -m   "msg"   arquivo.txt

Por que isso importa tanto no desenvolvimento

GUIs são ótimas pra explorar visualmente, mas CLIs ganham em três frentes que importam muito pra programação:

Automação — você pode colocar um comando dentro de um script e rodar mil vezes sem clicar em nada
Composição — como vimos com os pipes, você combina ferramentas pequenas em fluxos complexos
Funciona sem interface gráfica — servidores, containers Docker, pipelines de CI/CD geralmente não têm tela nenhuma; só dá pra interagir via terminal

É por isso que praticamente toda ferramenta séria do ecossistema JS (Vite, ESLint, TypeScript, Git, Docker) é, no fundo, uma CLI: ela precisa rodar igualzinho na sua máquina e num servidor remoto sem interface nenhuma, de forma automatizável.

Typescript: Sobrecarga de Construtor

Yuri Peixinho — Sat, 13 Jun 2026 21:53:26 +0000

Introdução

Assim como funções, construtores podem ter múltiplas assinaturas:

O problema

class Evento {
  constructor(id: string, tipo: string, competencia: string) { ... }
  // como aceitar também só id e tipo, sem competencia?
}

Solução — overload signatures

class Evento {
  id: string;
  tipo: string;
  competencia: string;

  // assinaturas
  constructor(id: string, tipo: string);
  constructor(id: string, tipo: string, competencia: string);

  // implementação
  constructor(id: string, tipo: string, competencia: string = "nao-definida") {
    this.id = id;
    this.tipo = tipo;
    this.competencia = competencia;
  }
}

new Evento("1", "R-2010");              // ✅ primeira assinatura
new Evento("1", "R-2010", "2024-01");   // ✅ segunda assinatura