Consultas com SELECT

Uma consulta solicita dados a um banco de dados. Uma consulta SELECT simples lê a tabela armazenada sem alterá-la. SELECT indica as colunas a exibir, e FROM indica a tabela a ler.

Os exemplos de texto usam a igualdade comum que diferencia maiúsculas de minúsculas no SQLite e no PostgreSQL. Configurações de colação podem alterar a comparação e a ordenação de texto.

Duas tabelas para trabalhar

A tabela employees tem estas oito linhas. salary é o salário anual em dólares; hire_date é texto no formato YYYY-MM-DD. NULL marca um valor ausente.

A tabela products registra preços em dólares e estoque em unidades no depósito.

Leia a estrutura da consulta

SELECT city, first_name
FROM employees;

O conjunto de resultados é outra tabela: oito linhas e duas colunas, com city primeiro. Não há filtro, então cada funcionário contribui com uma linha. A SQL não garante a ordem das linhas até você adicionar ORDER BY.

SELECT * FROM products; exibe todas as colunas na ordem definida pela tabela. O asterisco é útil para explorar. Em uma consulta salva, indicar as colunas mantém o resultado focado e impede que uma coluna recém-adicionada à tabela altere sua estrutura.

Torne a sintaxe legível

Separe as colunas com vírgulas, sem vírgula final antes de FROM. Termine a instrução com ponto e vírgula. As palavras-chave não diferenciam maiúsculas de minúsculas, então select funciona, mas as maiúsculas facilitam a identificação das cláusulas. Espaços e quebras de linha separam palavras; eles não alteram o significado desta consulta. Um comentário com -- continua até o fim da linha.

Os nomes devem corresponder aos do esquema. Se frist_name causar um erro de coluna inexistente, compare a grafia com first_name. A SQL padrão usa aspas duplas para nomes que contêm espaços ou palavras reservadas, como "order date". O PostgreSQL converte nomes sem aspas para minúsculas, enquanto "City" procura esse nome exatamente com a maiúscula. O MySQL normalmente usa crases; aspas duplas identificam nomes no modo ANSI_QUOTES. O SQL Server também aceita colchetes e aceita aspas duplas quando QUOTED_IDENTIFIER está ativado, sua configuração padrão.

Um valor repetido no resultado de uma consulta é frequentemente útil. Vários funcionários podem morar na mesma cidade, e cada um ainda precisa de uma linha. Use DISTINCT quando a pergunta pedir valores ou combinações distintos.

Escolha o que deve contar como duplicata

SELECT DISTINCT city
FROM employees;

O resultado contém Chicago, Denver e Boston, sem ordem garantida. O SELECT city simples retornaria oito linhas porque cada funcionário fornece uma cidade. Adicionar DISTINCT reduz essa exibição a três valores distintos. Isso mantém os oito registros de funcionários armazenados.

A comparação inclui todas as colunas selecionadas. Considere:

SELECT DISTINCT department, city
FROM employees;

Ana e Chloe contribuem com (Sales, Chicago), então esse par aparece uma vez. Emma contribui com (Sales, Denver), que é diferente e permanece. Os outros pares são (IT, Denver), (Marketing, Boston), (IT, Chicago), (NULL, Boston) e (Marketing, Chicago). Há sete linhas de resultado. Departamentos repetidos permanecem porque um departamento associado a outra cidade forma uma linha de resultado diferente.

Escreva DISTINCT uma vez, imediatamente após SELECT. Ele se aplica à linha selecionada inteira. Colocá-lo entre nomes de colunas, como em SELECT department, DISTINCT city, é um erro de sintaxe.

Observe quais colunas você inclui

Se você adicionar employee_id às colunas selecionadas, cada linha se tornará diferente. SELECT DISTINCT employee_id, city FROM employees; ainda retorna oito linhas: cada identificador é único, mesmo quando a cidade se repete. Para responder a “Quais cidades têm funcionários?”, selecione apenas a cidade. Para responder a “Quais funcionários moram em cada cidade?”, mantenha as colunas de identificação e espere cidades repetidas.

Nessa etapa de remoção de duplicatas, valores NULL repetidos são tratados como duplicatas. SELECT DISTINCT department FROM employees; retorna Sales, IT, Marketing e uma linha NULL. A linha NULL registra que um departamento está ausente; ela não é o nome de um quarto departamento. Essa regra de duplicatas difere de NULL = NULL, que resulta em desconhecido em um filtro.

Comparações de texto seguem uma colação, as regras do banco de dados para comparar e ordenar texto. Nas comparações comuns que diferenciam maiúsculas de minúsculas usadas nestes exemplos de SQLite e PostgreSQL, Chicago e chicago são valores diferentes. Uma lista DISTINCT pode revelar uso inconsistente de maiúsculas. Remover repetições da exibição não corrige a grafia nos dados armazenados.

Combine DISTINCT com uma lista curta ordenada

SELECT DISTINCT city
FROM employees
ORDER BY city
LIMIT 2;

Primeiro, as cidades duplicadas desaparecem. Em seguida, as três cidades são ordenadas. Por fim, restam duas linhas de resultado: Boston e Chicago, nessa ordem. Aplicar o limite primeiro às linhas de funcionários responderia a outra pergunta.

Em uma consulta DISTINCT, mantenha as colunas de ordenação na lista SELECT. O PostgreSQL exige isso; o SQLite permite algumas consultas que ordenam por uma coluna não selecionada, mas a escolha entre diferentes valores ocultos torna a ordenação difícil de interpretar. Se um resultado tiver repetições inesperadas, examine as colunas selecionadas antes de decidir que DISTINCT deve fazer parte da consulta.

A cláusula WHERE mantém uma linha somente quando sua condição é verdadeira. Ela vem depois de FROM e pode testar qualquer coluna da tabela, inclusive uma coluna que você não exibe.

Relacione as palavras ao operador

<> é a forma da SQL padrão para “diferente de”. Os cinco bancos de dados discutidos aqui também aceitam !=. Use um sinal de igualdade para indicar igualdade. O SQLite aceita ==, mas o PostgreSQL rejeita essa forma.

Acompanhe uma linha no limite

SELECT first_name, salary
FROM employees
WHERE salary > 60000;

Ben ganha 71000, Emma ganha 65000 e Farid ganha 83000. Essas são as três linhas que atendem à condição, sem ordem determinada. David ganha exatamente 60000. Sua linha não passa em > 60000 porque “mais de” exclui a igualdade.

Altere apenas o operador para >=. David agora entra no resultado, que passa a ter quatro linhas. É assim que “pelo menos 60000” difere de “mais de 60000”. Uma verificação útil do limite pergunta o que acontece com um valor exatamente igual ao limite; valores muito acima dele não revelam esse erro.

Para “no máximo 20,50”, um preço de 20,50 passa e um preço de 20,51 não passa. Quando uma solicitação fornece um limite inferior e um superior, verifique cada extremo separadamente antes de unir os testes.

Escreva valores numéricos como números

Use apenas algarismos em condições SQL: 60000, sem separador de milhares ou símbolo de moeda. Uma vírgula separa itens em SQL; WHERE salary > 60,000 é um erro de sintaxe. Valores decimais usam ponto, como em WHERE price < 20.50. Salários e preços pertencem a colunas numéricas para que as comparações usem sua magnitude numérica.

Texto que parece numérico segue regras de texto quando comparado como texto. O valor de texto '9' é ordenado depois de '10' porque seu primeiro caractere vem depois. Isso informa sobre caracteres, não sobre nove ser maior que dez. Leia o tipo de dados da coluna antes de interpretar uma comparação inesperada.

Filtre sem exibir a coluna testada

SELECT first_name
FROM employees
WHERE salary < 50000;

Chloe e Grace passam. Seus salários são usados para testar as linhas, mas não aparecem no resultado. Você não precisa adicionar o salário a SELECT para que o filtro funcione. Ao verificar uma consulta, exibi-lo temporariamente pode ajudar você a examinar por que cada linha passou.

Uma igualdade em uma chave primária permite buscar diretamente um registro: WHERE employee_id = 6 encontra Farid. Uma chave primária identifica uma linha, então essa igualdade não pode retornar vários funcionários com o mesmo identificador.

Dados ausentes exigem cuidado separado. WHERE stock <> 0 retorna seis produtos. Lamp Shade fica de fora porque seu estoque conhecido é zero. Bookshelf também fica de fora: seu estoque é NULL, então a comparação é desconhecida e WHERE não o mantém. Um teste de “diferente de” não acrescenta valores ausentes ao resultado.

Condições de texto e de data precisam de valores em uma forma que o banco de dados possa interpretar. Um valor escrito incorretamente pode não retornar nenhuma linha sem gerar aviso, enquanto a falta de aspas pode transformar esse valor em um nome de coluna.

Distinga um valor de um nome

SELECT first_name
FROM employees
WHERE city = 'Chicago';

As aspas simples tornam 'Chicago' um valor de texto. O resultado contém Ana, Chloe, Farid e Hugo. Sem aspas, Chicago é interpretado como um nome, então o banco de dados procura uma coluna com esse nome. As aspas duplas padrão também delimitam nomes. O PostgreSQL rejeita city = "Chicago" quando essa coluna não existe. Algumas configurações do SQLite aceitam cadeias entre aspas duplas como recurso legado; use aspas simples para valores de forma consistente.

Um apóstrofo dentro de um valor é duplicado:

SELECT first_name
FROM employees
WHERE last_name = 'O''Neill';

Isso encontra Hugo. As duas aspas simples adjacentes representam um apóstrofo dentro do valor; as aspas externas marcam seu início e seu fim. A SQL padrão não usa uma barra invertida para escapar esse apóstrofo.

Verifique as regras de comparação

Uma colação controla a igualdade e a ordenação de texto, incluindo maiúsculas, minúsculas e letras acentuadas. Nas comparações comuns que diferenciam maiúsculas de minúsculas no SQLite e no PostgreSQL usadas aqui, 'Chicago' e 'chicago' são diferentes. WHERE city = 'chicago' não retorna linhas. MySQL e SQL Server costumam usar colações que ignoram maiúsculas e minúsculas, então suas configurações usuais podem encontrar ambas as grafias.

Comparações de intervalos de texto também seguem a colação. Com esses nomes, WHERE last_name < 'M' retorna Brown, Carter, Haddad, Kim e Lopez. Os valores são comparados a partir da esquerda. Um valor mais longo que começa com os mesmos caracteres vem depois de seu prefixo: 'Martin' vem depois de 'M'. Um limite de 'M' não é o mesmo que “todos os nomes que começam com M”.

Coloque o ano primeiro

A coluna hire_date do exemplo armazena datas completas como texto: ano, mês e depois dia, com larguras fixas. Isso faz com que a ordem do texto corresponda à ordem do calendário.

SELECT first_name, hire_date
FROM employees
WHERE hire_date >= '2022-01-01';

Chloe, Grace e Hugo passam. O PostgreSQL também tem um tipo DATE para datas reais que aceita esse literal. Sua forma padrão com tipo explícito é DATE '2022-01-01'; o SQLite não usa essa sintaxe de literal tipado.

Uma data em texto no formato local, como '03/04/2024', é ambígua em uma coluna de data porque as configurações podem interpretá-la como 4 de março ou 3 de abril. Armazenadas como texto, datas com o mês primeiro são comparadas pelo mês antes do ano. Por exemplo, '12/01/2021' é ordenado depois de '03/15/2024', embora a primeira data no calendário seja anterior.

Interprete o limite com a data completa

“Contratado após 2022” significa a partir de '2023-01-01'. Comparar o texto com '2022' também inclui o '2022-08-05' de Hugo: o texto mais longo é ordenado depois do prefixo correspondente.

Se uma coluna contiver horas, a igualdade com apenas uma data não seleciona todas as horas desse dia. Para incluir 31 de março de 2024, use ordered_at >= '2024-03-31' AND ordered_at < '2024-04-01'. Isso mantém todos os horários desde o início de 31 de março até o início de 1º de abril, sem incluí-lo.

Uma linha pode precisar passar em vários testes. AND exige que ambas as condições sejam verdadeiras. OR exige que pelo menos uma seja verdadeira. NOT inverte verdadeiro e falso; quando uma condição é desconhecida por causa de NULL, NOT a mantém desconhecida.

Decida se ambos os testes devem ser atendidos

SELECT first_name
FROM employees
WHERE department = 'Sales' AND city = 'Chicago';

Ana e Chloe passam nos dois testes. Emma trabalha em Sales, mas mora em Denver, então não passa nesse AND. Mudar AND para OR também inclui Emma, Farid e Hugo: os cinco funcionários que atendem à condição satisfazem um teste ou ambos.

Adicionar uma condição AND pode manter ou reduzir o resultado. Adicionar uma condição OR pode manter ou ampliar o resultado. Isso permite uma verificação rápida ao construir um filtro em etapas.

Toda comparação deve estar completa. Escreva department = 'IT' OR department = 'Marketing', repetindo a coluna e o operador. department = 'IT' OR 'Marketing' não expressa a segunda comparação. O PostgreSQL a rejeita; o SQLite trata o texto isolado como falso e retorna apenas funcionários de IT. Da mesma forma, escreva salary > 50000 AND salary < 70000, com salary dos dois lados de AND.

Interprete grupos de alternativas

“Funcionários em Boston e Denver” normalmente pede pessoas em qualquer uma das duas cidades. Cada linha tem uma cidade, então use city = 'Boston' OR city = 'Denver'. Isso retorna Ben, David, Emma e Grace. Um AND entre essas igualdades exige que um único valor de cidade seja os dois lugares ao mesmo tempo e não retorna linhas.

Quando operadores são combinados, NOT é avaliado antes de AND, e AND antes de OR. Sem parênteses:

WHERE department = 'Sales'
   OR department = 'Marketing' AND city = 'Chicago'

Isso significa funcionários de Sales em qualquer lugar, mais funcionários de Marketing em Chicago. Emma passa porque a comparação com Sales é suficiente. Para restringir ambos os departamentos a Chicago, agrupe as alternativas:

SELECT first_name
FROM employees
WHERE (department = 'Sales' OR department = 'Marketing')
  AND city = 'Chicago';

Agora Ana, Chloe e Hugo passam. Os parênteses submetem as duas opções de departamento a uma mesma exigência de cidade. Use-os para tornar claro um filtro que mistura AND e OR, mesmo quando a ordem padrão já estaria correta.

Inverta um grupo inteiro

NOT (city = 'Chicago' OR city = 'Denver') retorna David e Grace em Boston. Nenhuma das cidades listadas é permitida. Isso equivale a city <> 'Chicago' AND city <> 'Denver' para esses valores.

Usar OR entre esses dois testes de “diferente de” é uma armadilha comum. Uma linha de Chicago é diferente de Denver, e uma linha de Denver é diferente de Chicago. Todo funcionário com uma cidade registrada passa em pelo menos um teste, então o OR não exclui nenhuma das duas cidades.

Construa uma condição complexa por partes. Verifique as linhas depois do primeiro teste e depois de adicionar o seguinte. Você pode trocar os dois lados de um AND ou os dois lados de um OR sem alterar a resposta; escolha a disposição que torne os grupos mais fáceis de ler.

Use IN quando uma coluna puder corresponder a qualquer valor de uma lista. Ele encurta um grupo de igualdades unidas por OR, mantendo seu significado.

Crie uma lista de alternativas

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing');

Ben, David, Farid e Hugo passam. Cada um tem um dos dois valores de departamento. O mesmo teste poderia ser escrito como department = 'IT' OR department = 'Marketing'.

Coloque os itens da lista entre parênteses, separados por vírgulas. Coloque texto entre aspas; deixe valores numéricos sem aspas. Por exemplo, employee_id IN (2, 4, 6) seleciona Ben, David e Farid. A ordem dos itens da lista não ordena o resultado. Repetir um item não repete uma linha correspondente: IN (6, 2, 2, 4) seleciona os mesmos registros. Use ORDER BY se precisar de uma ordem para o resultado.

IN busca correspondências de valores inteiros segundo as mesmas regras de comparação da igualdade. city IN ('Chi') não corresponde a Chicago. Nas comparações comuns que diferenciam maiúsculas de minúsculas usadas aqui, city IN ('chicago') também não corresponde. Uma busca por fragmento precisa de LIKE, enquanto o tratamento de maiúsculas e minúsculas depende da colação.

Aplique outra regra a todas as opções

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing')
  AND city = 'Chicago';

Farid e Hugo passam. IN é uma condição, então AND aplica o teste de cidade a toda a escolha de departamentos. Na versão expandida com OR, coloque parênteses em torno das duas comparações de departamento. Sem eles, department = 'IT' OR department = 'Marketing' AND city = 'Chicago' também inclui Ben, pois AND tem precedência maior e a regra de cidade se aplica apenas a Marketing.

Exclua os valores listados

WHERE city NOT IN ('Chicago', 'Denver') retorna David e Grace. Uma cidade registrada passa somente quando é diferente das duas entradas. Essa é uma forma útil para várias exclusões e evita o erro de unir condições de “diferente de” com OR.

Valores ausentes não correspondem a nenhuma das duas formas. Grace tem departamento NULL, então department NOT IN ('Sales') não a inclui. O banco de dados não consegue determinar que o departamento ausente é diferente de Sales. Para incluir também funcionários sem departamento atribuído, escreva department NOT IN ('Sales') OR department IS NULL.

Um NULL dentro de uma lista NOT IN cria um problema mais amplo. department NOT IN ('Sales', NULL) exige tanto department <> 'Sales' quanto department <> NULL. A segunda comparação é sempre desconhecida, então o teste combinado nunca é verdadeiro e WHERE não retorna linhas. Mantenha os testes de valores ausentes separados da lista de valores.

Com IN, uma correspondência real ainda passa mesmo que outro item da lista seja NULL. department IN ('Sales', NULL) mantém os três funcionários de Sales, mas não adiciona Grace. Use IS NULL para solicitar explicitamente valores ausentes.

Uma lista IN comum em SQL precisa de pelo menos um item. O PostgreSQL rejeita IN (); o SQLite o aceita como falso. Se um programa criar uma lista a partir das escolhas do usuário, trate uma lista vazia antes de enviar a consulta para que o comportamento seja intencional nos diferentes bancos de dados.

BETWEEN testa um intervalo com ambos os extremos incluídos. Use-o quando “de” e “até” incluírem os valores de fronteira indicados; use comparações explícitas quando algum limite precisar ser excluído.

Verifique os dois extremos

SELECT name, price
FROM products
WHERE price BETWEEN 15.50 AND 89.00;

Desk Lamp, Floor Lamp, Lamp Shade e Desk Organizer passam. Floor Lamp custa exatamente 89,00 e Lamp Shade exatamente 15,50, então ambos permanecem. A condição significa price >= 15.50 AND price <= 89.00.

Coloque o menor valor primeiro. price BETWEEN 89.00 AND 15.50 pede um preço de pelo menos 89,00 e no máximo 15,50. É uma sintaxe válida, mas não há correspondências. O BETWEEN comum não reordena os extremos para você. O PostgreSQL oferece BETWEEN SYMMETRIC para fazer isso, mas use a forma com o menor valor primeiro para uma consulta compartilhada com o SQLite.

Para “mais de 15,50 e menos de 89,00”, escreva price > 15.50 AND price < 89.00. Apenas Desk Lamp e Desk Organizer passam. Essa diferença diz respeito aos extremos da pergunta, não à forma como o resultado é exibido.

Fora de um intervalo

price NOT BETWEEN 20 AND 100 significa price < 20 OR price > 100. Ele retorna Lamp Shade, Office Chair, Standing Desk, Desk Organizer, Bookshelf e Paper Tray. Valores exatamente iguais a 20 ou 100 estariam dentro do intervalo original e não passariam em NOT BETWEEN.

Um valor testado ausente resulta em desconhecido em qualquer um dos dois testes. Para estoque, BETWEEN 5 AND 40 seleciona cinco produtos e NOT BETWEEN seleciona dois: Lamp Shade com 0 e Desk Organizer com 60. Bookshelf tem estoque NULL e não pertence a nenhum dos resultados. Portanto, um intervalo e sua negação não precisam abranger todas as linhas armazenadas.

Datas e horas

Datas completas em texto na ordem YYYY-MM-DD permitem usar intervalos de datas. hire_date BETWEEN '2020-01-01' AND '2022-12-31' seleciona Ben, David e Hugo, abrangendo os três anos do calendário nessa coluna que contém apenas datas.

Uma coluna que contém horas precisa de um limite superior diferente para um mês inteiro. Um extremo que contém apenas a data em uma coluna de data e hora significa meia-noite no início desse dia. Como texto, até '2024-03-31 00:00:00' é ordenado depois do prefixo mais curto '2024-03-31'. Para incluir todos os horários de março, use:

WHERE ordered_at >= '2024-03-01'
  AND ordered_at < '2024-04-01'

Isso inclui o início de março e termina imediatamente antes de abril, sem precisar adivinhar a última fração de segundo de 31 de março.

Intervalos de texto e os dois usos de AND

Extremos de texto são valores completos. last_name BETWEEN 'A' AND 'C' inclui Brown, mas exclui Carter, pois Carter é ordenado depois de seu prefixo C. Segundo essas regras de texto, last_name >= 'A' AND last_name < 'D' abrange nomes que começam com A, B ou C e retorna Brown e Carter.

Em price BETWEEN 10 AND 100 AND category = 'Lighting', o primeiro AND separa os extremos do intervalo; o segundo une o teste do intervalo ao teste da categoria. Os produtos correspondentes são Desk Lamp, Floor Lamp e Lamp Shade. Quebras de linha podem facilitar a visualização dos dois papéis.

LIKE testa um texto em relação a um padrão. Use-o para buscar um início, um final ou um fragmento quando a igualdade exigiria um valor inteiro exato.

Posicione os caracteres curinga

O padrão deve corresponder ao valor inteiro. % pode representar zero ou mais caracteres, incluindo espaços. Em '%Lamp%', qualquer um dos sinais de porcentagem pode corresponder a nenhum caractere, então o texto pode começar ou terminar com Lamp, além de contê-lo no meio.

_ representa exatamente um caractere. last_name LIKE '_im' encontra Kim. Quatro sublinhados em first_name LIKE '____' encontram Emma e Hugo, os nomes com exatamente quatro letras. O sublinhado não é um caractere opcional.

SELECT first_name, phone
FROM employees
WHERE phone LIKE '312-%';

Ana, Chloe e Farid passam porque o texto de telefone registrado começa com 312-. O sinal de porcentagem abrange todos os caracteres restantes.

Escolha o operador e a regra de maiúsculas e minúsculas

Caracteres curinga pertencem a padrões LIKE. name = '%Lamp%' procura sinais de porcentagem literais e não retorna produtos aqui. Os caracteres curinga de busca de arquivos * e ? não têm significado especial em LIKE; name LIKE 'Desk*' procura um asterisco literal depois de Desk.

O LIKE do SQLite normalmente ignora maiúsculas e minúsculas para as letras ASCII de A a Z, enquanto o LIKE comum do PostgreSQL as diferencia. Assim, name LIKE '%desk%' encontra Desk Lamp, Standing Desk e Desk Organizer no SQLite, mas nenhum no PostgreSQL com uma colação que diferencia maiúsculas de minúsculas. O PostgreSQL também oferece ILIKE, que ignora essa diferença. O comportamento do MySQL segue a colação.

Para os nomes de produtos ASCII usados aqui, LOWER(name) LIKE '%desk%' fornece as mesmas correspondências no SQLite e no PostgreSQL: LOWER converte o nome para minúsculas antes da comparação. A conversão entre maiúsculas e minúsculas em outros sistemas de escrita depende das regras do banco de dados e do idioma. A igualdade no SQLite também difere de seu LIKE: city = 'chicago' não encontra Chicago com a colação binária padrão, embora city LIKE 'chicago' o encontre.

Busque um caractere curinga literal

Para encontrar um sublinhado literal, escolha um caractere de escape:

WHERE code LIKE 'SPRING!_%' ESCAPE '!'

Em uma tabela de códigos de desconto, isso corresponde a 'SPRING_10', mas não a 'SPRINGS10'. O !_ é um sublinhado real; o último % continua correspondendo a uma sequência. Use a mesma abordagem com !% para um sinal de porcentagem literal. Escrever ESCAPE explicitamente evita depender dos padrões do banco de dados; o PostgreSQL normalmente usa uma barra invertida e o SQLite não tem caractere de escape padrão.

Negação e tamanho da busca

name NOT LIKE '%Lamp%' retorna os outros cinco produtos. Texto ausente não passa nem em LIKE nem em NOT LIKE. Entre os funcionários, três telefones correspondem a '312-%', dois telefones registrados não correspondem e os três telefones NULL não aparecem em nenhum dos resultados.

Um % no início não fornece a um índice comum um texto inicial fixo para restringir a busca, então uma grande parte da tabela pode ser percorrida. Um início fixo como 'Desk%' pode ajudar um índice adequado. Para datas, use intervalos de datas: LIKE funciona nessas datas de texto, mas o PostgreSQL exige conversão antes de aplicar LIKE a uma coluna DATE real.

NULL marca um valor ausente: um valor pode ser desconhecido, não registrado ou não aplicável. Ele é diferente de um zero conhecido ou de um texto conhecido sem caracteres.

Entenda o que significa um valor ausente

Lamp Shade tem stock = 0. Sua quantidade registrada é zero, portanto está sem estoque. Bookshelf tem stock NULL: a quantidade não foi registrada. O banco de dados não pode informar que há zero unidades nem qualquer outra quantidade.

A distinção muda a pergunta que você pode responder:

Uma célula que parece vazia em uma ferramenta de consulta não basta para distinguir esses estados. Algumas ferramentas mostram NULL como uma célula vazia; outras exibem NULL. Teste diretamente o valor armazenado.

Use os testes de valores ausentes

SELECT first_name
FROM employees
WHERE phone IS NULL;

Ben, Emma e Hugo não têm telefone registrado. IS NULL resulta em verdadeiro para seus valores ausentes. Para encontrar os cinco funcionários com telefone registrado, use phone IS NOT NULL: Ana, Chloe, David, Farid e Grace.

Não escreva phone = NULL para encontrar telefones ausentes. Uma comparação comum que envolve NULL resulta em desconhecido, mesmo quando ambos os lados são NULL. WHERE mantém apenas as linhas verdadeiras, então = NULL não retorna nenhuma. <> NULL tem o mesmo problema. IS NULL é um teste do marcador de ausência e fornece uma resposta definida, verdadeira ou falsa, para esses valores de uma única coluna.

A forma NOT phone IS NULL também encontra telefones presentes no SQLite e no PostgreSQL, mas phone IS NOT NULL torna o teste pretendido mais fácil de ler.

Separe três tipos de texto

SQLite, PostgreSQL, MySQL e SQL Server distinguem texto vazio de NULL. phone = '' encontraria cadeias vazias, não os telefones ausentes de Ben, Emma ou Hugo. Se uma coluna puder conter ambos, use phone IS NULL OR phone = '' para encontrar qualquer um dos estados. O Oracle trata um valor de texto vazio como NULL, então essa distinção muda quando você troca de banco de dados.

Aplique o enunciado e o esquema

“Ausente”, “não registrado” e “não atribuído” indicam IS NULL. department IS NULL encontra Grace. Seu departamento ausente não significa que o texto do departamento seja a palavra 'NULL', nem estabelece a qual departamento ela pertence.

A definição da tabela pode marcar uma coluna como NOT NULL, o que significa que uma linha armazenada não pode ter NULL nessa coluna. Uma consulta IS NULL nessa coluna não retorna linhas. Verifique essa regra ao examinar um esquema: colunas que permitem dados ausentes precisam de atenção especial quando você cria exclusões ou combina condições.

Uma condição em SQL pode ser verdadeira, falsa ou desconhecida. Valores ausentes tornam o terceiro estado necessário: sem uma quantidade registrada, um banco de dados não consegue determinar se essa quantidade está acima de um limite.

Uma condição e seu oposto

Para Bookshelf, stock > 10 é desconhecido porque o estoque é NULL. O mesmo vale para stock <= 10. WHERE mantém apenas condições verdadeiras e exclui tanto as falsas quanto as desconhecidas.

Na tabela de produtos, stock > 10 retorna quatro linhas e stock <= 10 retorna três. Juntas, elas abrangem sete dos oito produtos. Bookshelf está ausente de ambas. Aplicar NOT não o recupera: NOT desconhecido é desconhecido, então NOT (stock > 10) ainda seleciona apenas as três quantidades conhecidas de no máximo 10.

Isso difere de um valor que não atende a uma condição. O zero conhecido de Lamp Shade torna stock > 10 falso, então NOT o torna verdadeiro. Uma quantidade ausente não fornece uma comparação definida desse tipo para inverter.

Combine desconhecido com outro teste

Bookshelf custa 120,00. Em stock > 10 OR price > 100, a condição de preço é verdadeira. OR precisa de apenas uma parte verdadeira, então a linha é mantida mesmo que a comparação do estoque seja desconhecida. Em stock > 10 AND price > 100, a condição de estoque continua sem resolução, então o resultado é desconhecido e a linha é excluída.

Inclua valores ausentes deliberadamente

SELECT first_name
FROM employees
WHERE department <> 'Sales'
   OR department IS NULL;

Isso retorna Ben, David, Farid, Hugo e Grace. A comparação sozinha retornaria quatro, deixando Grace de fora. O ramo IS NULL inclui explicitamente funcionários cujo departamento não foi atribuído. Se esses funcionários pertencem a “fora de Sales” é uma questão sobre a resposta pretendida; a consulta deve expressar essa escolha.

Um valor NULL em uma lista NOT IN pode bloquear o resultado inteiro. department NOT IN ('Sales', NULL) significa que o departamento deve ser diferente de Sales e diferente de NULL. A última comparação é desconhecida para todas as linhas, então a condição completa nunca é verdadeira. IN ainda mantém correspondências reais: department IN ('Sales', NULL) seleciona os três funcionários de Sales, mas não encontra Grace.

Um valor testado ausente também produz desconhecido para LIKE e para um intervalo BETWEEN comum. IS NULL e IS NOT NULL fornecem respostas definidas para essas colunas escalares. Verifique valores ausentes com esses testes separadamente quando uma contagem de linhas parecer surpreendente.

Saiba quando valores NULL são agrupados

NULL = NULL continua sendo desconhecido; não se sabe se dois números de telefone ausentes são o mesmo número. DISTINCT, porém, trata valores ausentes repetidos como duplicatas, e ORDER BY os coloca juntos. Para uma comparação que trata deliberadamente dois valores NULL como iguais, SQLite e PostgreSQL também oferecem IS NOT DISTINCT FROM.

ORDER BY define a ordem das linhas do resultado. Sem ele, a SQL não garante qual linha aparece primeiro, mesmo quando uma tabela pequena parece retornar a mesma ordem todas as vezes.

Escolha a direção

ASC é o padrão. ORDER BY salary e ORDER BY salary ASC solicitam a mesma direção. “Maior salário primeiro” exige ORDER BY salary DESC.

SELECT first_name, salary
FROM employees
ORDER BY salary DESC;

Leia o resultado do maior para o menor: Farid 83000, Ben 71000, Emma 65000, David 60000, Hugo 58000, Ana 52000, Chloe 48000 e Grace 45000. O banco de dados reorganiza as linhas do resultado; essa consulta não altera a tabela armazenada.

Filtre antes de ordenar

SELECT name, price
FROM products
WHERE category = 'Lighting'
ORDER BY price;

Apenas as três linhas de Lighting entram nesse resultado. Seus preços em ordem crescente produzem Lamp Shade 15,50, Desk Lamp 24,99 e depois Floor Lamp 89,00. ORDER BY vem depois de WHERE na instrução. Inverter essas cláusulas é um erro de sintaxe.

A coluna de ordenação não precisa ser exibida. SELECT first_name FROM employees ORDER BY salary DESC; fornece a mesma ordem de nomes sem mostrar os salários. O PostgreSQL restringe isso quando DISTINCT está presente: uma consulta DISTINCT deve selecionar suas colunas de ordenação.

Leia o tipo de dados armazenado

Colunas numéricas são ordenadas por magnitude numérica. Colunas de texto são ordenadas por caracteres segundo sua colação. Os valores de texto '10', '9' e '100' são ordenados como '10', '100', '9' segundo a ordenação comum de caracteres. Essa não é uma classificação numérica correta, portanto verifique o tipo da coluna quando os valores parecerem fora de ordem.

Os valores de hire_date do exemplo são datas completas em texto, com largura fixa e ano primeiro. ORDER BY hire_date começa com Farid em 2017-09-12 e termina com Grace em 2024-02-19. DESC inverte essa ordem para apresentar as contratações mais recentes primeiro. Datas de texto com o mês primeiro, como MM/DD/YYYY, são comparadas pelo mês antes do ano e não podem fornecer uma ordem cronológica confiável entre anos.

A ordem do texto depende da colação

A colação binária padrão do SQLite coloca letras ASCII maiúsculas antes das minúsculas. Segundo essa regra, 'Zebra' precede 'apple', e 'é' vem depois de 'z'. Muitos bancos de dados PostgreSQL usam colações que consideram o idioma e produzem outra ordem. O uso consistente de maiúsculas ajuda, mas as regras de comparação do banco de dados ainda determinam a ordem dos caracteres acentuados e de outros caracteres.

Use nomes de colunas para especificar a ordenação com clareza. ORDER BY 2 DESC significa o segundo item da lista SELECT, então mover colunas pode alterar silenciosamente a ordenação. ORDER BY 'salary' indica uma constante de texto, não a coluna de salário: o SQLite não obtém uma ordenação útil com isso, e o PostgreSQL o rejeita. Escreva ORDER BY salary.

Uma segunda coluna de ordenação só importa quando há empate na primeira. Pense em uma lista ordenada de funcionários: agrupe primeiro por cidade e depois ordene os nomes dentro de cada cidade.

Acompanhe as colunas de ordenação da esquerda para a direita

SELECT last_name, city
FROM employees
ORDER BY city, last_name;

O resultado começa com Kim e Okafor em Boston. Depois vêm Haddad, Lopez, Nguyen e O'Neill em Chicago. Brown e Carter em Denver vêm por último. last_name não compete com city; ele determina a ordem apenas dentro de uma mesma cidade.

Inverter as colunas altera a ordem principal. ORDER BY last_name, city ordena principalmente pelo sobrenome e consulta a cidade apenas quando há empate nos sobrenomes. Use uma cláusula ORDER BY com vírgulas entre suas colunas de ordenação. Uma segunda cláusula ORDER BY é inválida.

Defina a direção de cada coluna

ORDER BY department, salary DESC significa departamento em ordem crescente e depois salário em ordem decrescente dentro de cada departamento. DESC pertence apenas a salary. Para colocar ambos em ordem decrescente, escreva department DESC, salary DESC.

Na ordenação padrão de NULL do SQLite, a primeira forma coloca o departamento ausente de Grace primeiro. IT vem em seguida com Farid e depois Ben; Marketing tem David e depois Hugo; Sales tem Emma, Ana e depois Chloe. Você está lendo uma hierarquia de comparações, não ordenando primeiro todas as linhas por salário e depois ignorando essa ordem.

Resolva um empate com um valor único

Linhas iguais em todas as colunas de ordenação podem aparecer em qualquer ordem. ORDER BY city não determina qual funcionário de Chicago vem primeiro. Uma ordenação total acrescenta uma última coluna que identifica cada linha de forma única:

SELECT first_name, city
FROM employees
ORDER BY city, employee_id;

Os identificadores resolvem todos os empates de cidade. Para dados inalterados, isso faz com que um LIMIT ou uma página posterior selecione uma parte reproduzível da lista ordenada. Um critério de desempate único determina quais linhas aparecem em um ponto de corte; ele não inclui linhas empatadas adicionais.

Posicione valores ausentes deliberadamente

Os padrões dos bancos de dados diferem:

Assim, a consulta de departamento coloca Grace por último no PostgreSQL com seu padrão, embora a coloque primeiro no SQLite. Essa diferença é independente da direção do salário.

SELECT first_name, department, salary
FROM employees
ORDER BY department NULLS LAST, salary DESC;

SQLite 3.30 ou posterior, PostgreSQL e Oracle oferecem suporte a NULLS FIRST e NULLS LAST. Aqui, eles colocam Grace depois de todos os departamentos registrados, mantendo a ordem salarial dentro de cada departamento. MySQL e SQL Server não aceitam essas cláusulas.

Interprete uma hierarquia solicitada na mesma sequência em que é enunciada: “por departamento, com os maiores salários primeiro em cada departamento” fornece department, salary DESC. “Em ordem alfabética por sobrenome e depois por nome” fornece last_name, first_name. Acrescente um identificador por último quando precisar de uma ordem reproduzível entre pessoas com nomes idênticos.

LIMIT mantém no máximo uma quantidade escolhida de linhas de resultado. Ele não decide quais linhas devem vir primeiro. Use ORDER BY para dar a uma lista curta um significado como maior salário, mais recente ou mais barato.

Ordene e depois corte

SELECT first_name, salary
FROM employees
ORDER BY salary DESC
LIMIT 3;

Os salários ordenados começam com Farid 83000, Ben 71000 e Emma 65000, então essas três linhas permanecem. Sem ORDER BY, LIMIT 3 retorna três linhas quaisquer, sem garantia de que sejam as pessoas com os maiores salários.

WHERE atua antes do limite. WHERE city = 'Boston' ORDER BY salary DESC LIMIT 5 retorna apenas David e Grace porque apenas dois funcionários atendem à condição. LIMIT é um máximo, não uma solicitação para inventar linhas adicionais. LIMIT 0 não retorna nenhuma.

Pule linhas para uma página posterior

OFFSET pula linhas antes de LIMIT contar as linhas a retornar. ORDER BY salary DESC LIMIT 3 OFFSET 3 pula Farid, Ben e Emma e depois retorna David, Hugo e Ana: posições quatro a seis.

Para a página k com n linhas por página, pule (k − 1) × n linhas. A página três com três linhas por página usa LIMIT 3 OFFSET 6. Restam apenas Chloe e Grace. A primeira página tem deslocamento zero, não um.

“Segunda linha” e “segundo valor distinto” são solicitações diferentes. ORDER BY salary DESC LIMIT 1 OFFSET 1 retorna Ben com 71000 aqui. Se dois funcionários compartilhassem o maior salário, essa consulta retornaria outra pessoa com o maior salário. Para encontrar o segundo salário distinto, selecione DISTINCT salary antes de ordenar e pular linhas.

Resolva o ponto de corte

ORDER BY city LIMIT 3 inclui os dois funcionários de Boston e um de Chicago, mas não especifica qual funcionário de Chicago. ORDER BY city, employee_id LIMIT 3 seleciona David, Grace e Ana. O identificador único resolve o ponto de corte.

Para manter todos os empatados no último valor de ordenação, PostgreSQL 13 ou posterior e Oracle oferecem suporte a FETCH FIRST 3 ROWS WITH TIES. Com ORDER BY city, ele mantém seis linhas: as duas de Boston e as quatro de Chicago. Se ORDER BY também incluir um identificador único, as linhas não poderão empatar na chave de ordenação completa.

Reconheça a sintaxe do banco de dados

A SQL padrão usa OFFSET e FETCH, não LIMIT. PostgreSQL e Oracle aceitam OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY. O SQL Server usa ORDER BY salary DESC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY; ORDER BY é obrigatório para essa forma de paginação.

SQLite e MySQL também aceitam LIMIT 6, 3, com o deslocamento primeiro. Prefira LIMIT 3 OFFSET 6 para que os papéis fiquem explícitos. A paginação executa novamente uma consulta para cada página. Uma ordenação total mantém as páginas consistentes enquanto os dados permanecem inalterados; inserções ou exclusões entre solicitações ainda podem fazer as páginas repetirem ou pularem registros.

As cláusulas SQL têm uma ordem fixa de escrita. Sua ordem lógica explica o resultado como uma sequência de decisões, mesmo quando o banco de dados usa um plano de execução interno diferente.

Escreva a instrução na ordem das cláusulas

SELECT DISTINCT city
FROM employees
WHERE department = 'Sales'
ORDER BY city
LIMIT 2 OFFSET 0;

SELECT e FROM identificam as colunas solicitadas e a tabela de origem. As outras cláusulas são opcionais, mas, quando presentes, mantêm esta ordem: WHERE, ORDER BY, LIMIT e depois OFFSET nessa forma com LIMIT. DISTINCT fica imediatamente após SELECT.

Use uma cláusula WHERE com várias condições unidas. Um segundo WHERE é um erro de sintaxe. O mesmo vale para ORDER BY: coloque várias colunas de ordenação em uma cláusula, separadas por vírgulas. Mover WHERE para depois de ORDER BY não solicita uma ordem de processamento diferente; produz SQL inválida.

Acompanhe as decisões lógicas

O resultado é Chicago, depois Denver. A cidade repetida desaparece antes de o limite contar as linhas de resultado. Você não está selecionando dois funcionários para depois perguntar se moram em cidades diferentes.

O otimizador pode usar um plano de execução física diferente que produza o mesmo resultado dessa sequência lógica.

Use colunas onde estão disponíveis

WHERE testa as linhas de origem antes de SELECT escolher as colunas exibidas:

SELECT first_name
FROM employees
WHERE salary > 60000;

Isso funciona sem salary na saída. Os nomes que atendem à condição são Ben, Emma e Farid. Salary ainda é uma coluna de cada linha de origem quando o teste é feito.

Da mesma forma, filtrar antes de limitar é essencial para obter o primeiro resultado dentro de um grupo:

SELECT first_name
FROM employees
WHERE department = 'Sales'
ORDER BY salary DESC
LIMIT 1;

A resposta é Emma. Os funcionários de Sales são selecionados primeiro; seus salários são então classificados. Selecionar primeiro a pessoa com o maior salário da empresa e testar essa única linha para Sales deixaria de fora a resposta pretendida, pois Farid pertence a IT.

Torne a estrutura visível

Escreva uma cláusula por linha e coloque condições mais longas em linhas separadas e recuadas. Para “produtos de Furniture abaixo de 200 dólares, com o maior preço primeiro”, use:

SELECT name, price
FROM products
WHERE category = 'Furniture'
  AND price < 200
ORDER BY price DESC;

Office Chair, com preço de 149,00, vem antes de Bookshelf, com 120,00. As duas condições compartilham um WHERE, o limite numérico não tem símbolo de moeda e ORDER BY ordena as linhas que passaram. Verificar cada linha de acordo com sua função facilita a localização de erros de sintaxe e de interpretações incorretas.

Antes de escrever SQL, identifique as decisões separadas que estão implícitas em uma solicitação cotidiana. Cada decisão pertence a uma cláusula, e cada cláusula pode ser verificada em relação à resposta pretendida.

Tome seis decisões

1. Qual tabela contém os registros? Escolha FROM.
2. Quais registros atendem à condição? Construa WHERE.
3. Quais campos respondem à pergunta? Escolha SELECT.
4. Valores repetidos no resultado são úteis? Decida sobre DISTINCT.
5. O que deve vir primeiro? Construa ORDER BY.
6. Há um máximo ou uma página? Adicione LIMIT e OFFSET.

Para “pelo menos”, inclua a igualdade. “Um de” sugere IN, “contém” sugere um padrão LIKE com sinais de porcentagem nas duas extremidades, “ausente” sugere IS NULL e “valores distintos” sugere DISTINCT. Uma solicitação dos primeiros n resultados precisa de uma direção de ordenação e de um limite.

Crie uma lista curta de funcionários

“Mostre os nomes e as datas de contratação dos três funcionários contratados mais recentemente fora de Sales que têm telefone registrado, começando pelo mais recente.” Inclua funcionários sem departamento atribuído no significado de fora de Sales dessa solicitação.

Comece com employees. A regra de departamento para selecionar as linhas é department <> 'Sales' OR department IS NULL. Agrupe essa escolha para que a regra de telefone se aplique a ambos os ramos. Mostre nomes e datas e depois classifique as linhas que atendem às condições:

SELECT first_name, last_name, hire_date
FROM employees
WHERE (department <> 'Sales' OR department IS NULL)
  AND phone IS NOT NULL
ORDER BY hire_date DESC
LIMIT 3;

Grace Okafor em 2024-02-19 é a primeira, David Kim em 2020-11-23 é o segundo e Farid Haddad em 2017-09-12 é o terceiro. Remover o ramo IS NULL exclui Grace e deixa apenas dois resultados. Para uma solicitação pouco clara, decida como os departamentos ausentes devem contar e informe a escolha junto com a resposta.

Combine categoria, preço e estoque

“Quais produtos de Lighting ou Storage custam menos de 20 dólares e estão em estoque, começando pelos mais baratos?” Use IN para as duas opções de categoria e exija uma quantidade positiva conhecida:

SELECT name, price
FROM products
WHERE category IN ('Lighting', 'Storage')
  AND price < 20
  AND stock > 0
ORDER BY price;

Paper Tray, a 9,99, vem antes de Desk Organizer, a 18,75. Lamp Shade é barato o suficiente e pertence a uma categoria escolhida, mas seu estoque é zero, então não passa no último teste. Uma quantidade ausente de estoque também não passaria, pois não permite determinar que o estoque é positivo.

Verifique as linhas que podem revelar um erro

Comece com SELECT * FROM products LIMIT 5; ao explorar o esquema e alguns registros. Adicione filtros um por vez, verificando mudanças na contagem de resultados e exibindo temporariamente as colunas testadas quando for útil.

Teste limites exatos, valores ausentes, uso de maiúsculas e minúsculas no texto e empates no limite. NOT mostra linhas em que uma condição era falsa; ele não revela linhas em que a condição era desconhecida. Execute testes IS NULL separadamente. Verifique se a saída tem as colunas solicitadas e se ORDER BY resolve todos os empates que afetam a resposta.

Ao transferir a consulta para outro banco de dados, verifique a sintaxe de limite de linhas, as regras de maiúsculas e minúsculas para igualdade e LIKE, as aspas em identificadores, o tratamento de datas e a posição de NULL. Os exemplos usam LIMIT no SQLite e no PostgreSQL; a forma da SQL padrão para limite de linhas é OFFSET com FETCH FIRST.