SQLite INNER JOIN: Unindo Linhas de Várias Tabelas

Um JOIN costura duas tabelas

Bancos de dados relacionais separam os dados em várias tabelas de propósito — clientes numa tabela, pedidos em outra, produtos numa terceira. Assim, cada informação fica em um único lugar. Só que, na hora de responder uma pergunta de verdade ("quais clientes pediram o quê?"), você precisa juntar os pedaços de novo. É exatamente para isso que serve um join.

O INNER JOIN é o mais usado no dia a dia. Ele combina linhas de duas tabelas sempre que uma condição bate, e descarta o resto.

CREATE TABLE customers (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER REFERENCES customers(id),
    total REAL
);

INSERT INTO customers (id, name) VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Chen');
INSERT INTO orders (customer_id, total) VALUES (1, 49.99), (1, 12.50), (2, 80.00);

SELECT customers.name, orders.total
FROM customers
INNER JOIN orders ON orders.customer_id = customers.id;

Três clientes, três pedidos, mas o Chen não tem nenhum pedido — então ele simplesmente não aparece no resultado. Essa é a essência do inner: só sobrevivem as linhas que casaram.

Modelo mental: casar linhas e depois filtrar

A melhor forma de ler um INNER JOIN é assim: pegue cada linha da primeira tabela, compare com cada linha da segunda tabela e mantenha o par apenas quando a condição do ON for verdadeira. Na prática, é como se fosse um produto cartesiano gigante seguido de um filtro. O SQLite não executa exatamente desse jeito (ele usa índices sempre que pode), mas esse modelo serve direitinho para prever o que vai sair no resultado.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);

INSERT INTO customers VALUES (1, 'Ada'), (2, 'Boris');
INSERT INTO orders VALUES (10, 1, 30), (11, 1, 70), (12, 2, 15);

SELECT c.name, o.id AS order_id, o.total
FROM customers AS c
INNER JOIN orders AS o ON o.customer_id = c.id;

Alguns hábitos que vale a pena adotar aqui:

• Use aliases nas tabelas (customers AS c) quando for citá-las mais de uma vez. Reduz a poluição visual.
• Qualifique as colunas (c.name, o.total) quando ambas as tabelas puderem ter aquele nome.
• A ordem em ON o.customer_id = c.id não importa — c.id = o.customer_id funciona igual.

INNER JOIN vs JOIN no SQLite

No SQLite (e no SQL padrão), usar só JOIN já é a mesma coisa que INNER JOIN. A palavra-chave INNER é opcional.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);
INSERT INTO customers VALUES (1, 'Ada'), (2, 'Boris');
INSERT INTO orders VALUES (10, 1, 30), (11, 2, 15);

SELECT c.name, o.total
FROM customers c
JOIN orders o ON o.customer_id = c.id;

Os dois estilos geram o mesmo plano de execução e devolvem as mesmas linhas. Escrever INNER JOIN por extenso é um pequeno ganho de legibilidade em código que mistura tipos de join — o intuito fica óbvio quando há um LEFT JOIN poucas linhas depois.

ON ou USING: qual cláusula usar

Quando as colunas do join têm o mesmo nome nas duas tabelas, USING (coluna) fica mais enxuto que ON a.col = b.col:

CREATE TABLE customers (customer_id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);

INSERT INTO customers VALUES (1, 'Ada'), (2, 'Boris');
INSERT INTO orders VALUES (10, 1, 30), (11, 2, 15);

SELECT name, total
FROM customers
INNER JOIN orders USING (customer_id);

USING (customer_id) faz duas coisas: casa as linhas onde customer_id é igual e funde a coluna, fazendo com que ela apareça uma única vez no resultado. Use quando os dois lados realmente compartilham o mesmo nome de coluna. Já o ON é a melhor escolha quando os nomes diferem (orders.customer_id = customers.id) ou quando a condição vai além de uma simples igualdade.

Inner join com 3 tabelas no SQLite

Para juntar várias tabelas no SQLite, basta encadear novas cláusulas JOIN ... ON .... Cada nova cláusula conecta o resultado parcial a mais uma tabela.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);
CREATE TABLE order_items (
    order_id INTEGER,
    product TEXT,
    quantity INTEGER
);

INSERT INTO customers VALUES (1, 'Ada'), (2, 'Boris');
INSERT INTO orders VALUES (10, 1, 30), (11, 2, 15);
INSERT INTO order_items VALUES (10, 'Caderno', 2), (10, 'Caneta', 5), (11, 'Caneca', 1);

SELECT c.name, o.id AS order_id, i.product, i.quantity
FROM customers c
INNER JOIN orders o ON o.customer_id = c.id
INNER JOIN order_items i ON i.order_id = o.id
ORDER BY c.name, o.id;

Leia de cima para baixo: clientes se ligam a pedidos, e pedidos se ligam a itens. Cada linha do resultado representa uma combinação de cliente–pedido–item. Qualquer linha que não tenha correspondência em algum ponto da cadeia é descartada — é a regra do inner join aplicada em cada etapa.

Filtrando com WHERE

O ON define como as linhas se emparelham. Já o WHERE filtra o resultado já emparelhado. No caso específico do inner join, colocar uma condição extra no ON ou no WHERE gera as mesmas linhas — mas a convenção é manter as condições de junção no ON e os filtros de linha no WHERE.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, country TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);

INSERT INTO customers VALUES (1, 'Ada', 'UK'), (2, 'Boris', 'FR'), (3, 'Chen', 'UK');
INSERT INTO orders VALUES (10, 1, 30), (11, 2, 80), (12, 3, 12);

SELECT c.name, o.total
FROM customers c
INNER JOIN orders o ON o.customer_id = c.id
WHERE c.country = 'UK' AND o.total > 20;

Em português, isso quer dizer "junte clientes e pedidos, e depois fique só com os clientes do Reino Unido cujo pedido passa de 20." Dois papéis, duas cláusulas — seu eu do futuro vai agradecer. (Quando você começar a escrever LEFT JOIN, a diferença entre ON e WHERE deixa de ser só estética, mas isso fica para a próxima página.)

Várias condições no ON

A cláusula ON aceita qualquer expressão booleana, não apenas uma igualdade. Isso é útil quando o relacionamento entre as tabelas envolve mais de uma coluna, ou quando você quer filtrar o lado direito já no momento do join.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL, status TEXT);

INSERT INTO customers VALUES (1, 'Ada'), (2, 'Boris');
INSERT INTO orders VALUES
    (10, 1, 30, 'paid'),
    (11, 1, 50, 'cancelled'),
    (12, 2, 15, 'paid');

SELECT c.name, o.id, o.total
FROM customers c
INNER JOIN orders o
    ON o.customer_id = c.id
   AND o.status = 'paid';

O pedido cancelado some porque a segunda condição não bate. Num inner join, você poderia escrever WHERE o.status = 'paid' e teria o mesmo resultado. A versão com ON mantém a lógica do "o que conta como correspondência" pertinho do join.

Armadilhas comuns

Algumas coisas que costumam pegar a galera de surpresa:

• Esquecer da cláusula ON. FROM a INNER JOIN b sem ON é erro de sintaxe no SQLite. (Já uma vírgula simples — FROM a, b — compila, mas devolve um cross join, e quase nunca é o que você queria.)
• Duplicatas inesperadas. Se um cliente tem três pedidos, o nome dele aparece três vezes no resultado. Isso é o comportamento correto do join, não um bug. Use GROUP BY para agregar se quiser uma linha por cliente.
• Linhas faltando. Se um cliente deveria aparecer e não apareceu, é porque a condição do join não bateu — confira se há NULL nas colunas do join, ou parta para o LEFT JOIN.
• Nomes de colunas ambíguos. SELECT id FROM customers JOIN orders ON ... dá erro porque as duas tabelas têm uma coluna id. Qualifique: c.id ou o.id.

A seguir: LEFT JOIN

O INNER JOIN é ótimo quando "sem correspondência" significa "ignora essa linha". Mas tem hora que você quer listar todos os clientes, inclusive os que não têm pedido nenhum, com NULL no lugar dos dados ausentes. Para isso existe o LEFT JOIN, que é o próximo da fila.