Colunas calculadas e funções em SQL: expressões CASE

Uma coluna de resultado pode mostrar um valor que não está armazenado em nenhum lugar da tabela. A SQL o calcula a partir da linha atual. Uma expressão combina colunas, valores fixos, operadores e chamadas de função.

Calcule um valor para cada linha

SELECT order_id,
       quantity * unit_price AS line_total
FROM orders;

Para quantidade 3 e preço unitário 12,50, a nova coluna mostra 37.5. Cada linha fornece sua própria quantidade e seu próprio preço. A consulta deixa as colunas armazenadas inalteradas. Uma função escalar, como ROUND(unit_price, 0), também retorna um valor por linha de entrada. Adicioná-la à lista SELECT não combina linhas. Já uma função de agregação como SUM ou AVG calcula um valor para um grupo.

O nome depois de AS é um apelido de coluna: um cabeçalho para o resultado. Sem ele, SQLite usa o texto da expressão como cabeçalho; PostgreSQL usa ?column? para essa expressão aritmética. AS é opcional, mas torna mais fácil distinguir um nome de uma vírgula ausente.

Escolha nomes e aspas

Use um nome simples como line_total: letras, algarismos e sublinhados, começando com uma letra. Um nome que contenha espaço ou seja uma palavra reservada precisa de aspas duplas: AS "Line Total" ou AS "order". Aspas simples indicam valores de texto, como 'Boston'. MySQL também aceita crases para nomes, e SQL Server aceita colchetes.

PostgreSQL converte nomes sem aspas para minúsculas: AS LineTotal produz linetotal. Aspas duplas preservam a grafia em AS "LineTotal". SQLite mantém um apelido como foi digitado. Nomes em minúsculas com sublinhados funcionam bem em ambos.

Use um apelido na etapa correta

A ordem lógica é FROM, WHERE, SELECT e depois ORDER BY. A tabela é escolhida e as linhas são filtradas antes que as expressões de saída recebam seus apelidos. A ordenação acontece depois.

SELECT order_id,
       quantity * unit_price AS line_total
FROM orders
WHERE quantity * unit_price > 100
ORDER BY line_total DESC;

ORDER BY pode usar line_total. A SQL padrão, PostgreSQL e MySQL não podem usar esse novo apelido em WHERE; repita a expressão nesse ponto. SQLite aceita um apelido em WHERE como extensão, mas essa forma falhará quando for transferida para PostgreSQL.

Um novo apelido também não está disponível para outra expressão na mesma lista SELECT. Depois de unit_price * 1.08 AS with_tax, escrever with_tax - unit_price AS tax falha se a tabela não tiver uma coluna with_tax. Escreva unit_price * 1.08 - unit_price AS tax.

Investigue um resultado surpreendente

SELECT first_name last_name FROM customers; é SQL válida. Ela exibe uma coluna de primeiros nomes com o apelido last_name. Para recuperar ambas as colunas, escreva SELECT first_name, last_name FROM customers;. Assim, uma vírgula ausente pode produzir um resultado enganoso sem gerar erro.

Para verificar rapidamente uma expressão, uma tabela é desnecessária: SELECT 19.99 * 3 AS total; retorna 59.97 no SQLite e no PostgreSQL. Oracle anterior à Release 23 exige FROM DUAL para essa consulta; Release 23 e versões posteriores também permitem SELECT sem FROM.

Expressões aritméticas transformam quantidades originais em valores, taxas e diferenças. Os operadores são +, -, *, / e %; o módulo fornece o resto da divisão.

Controle a ordem do cálculo

Multiplicação, divisão e módulo vêm antes de adição e subtração. Operadores de mesma precedência são executados da esquerda para a direita. Assim, 10 + 3 * 2 resulta em 16, enquanto (10 + 3) * 2 resulta em 26.

Para quantidade 3, preço unitário 12,50 e percentual de desconto 10:

quantity * unit_price * (1 - discount_pct / 100.0)

Primeiro, 10 / 100.0 resulta em 0.1. Os parênteses fornecem a fração paga, 0.9. O valor bruto é 37.5, então o valor líquido é 33.75. Sem parênteses, quantity * unit_price * 1 - discount_pct / 100.0 subtrai 0.1 de 37.5 e resulta em 37.4.

Preserve frações durante a divisão

No SQLite, PostgreSQL e SQL Server, dividir um inteiro por outro descarta a fração em direção a zero: 7 / 2 resulta em 3, e -7 / 2 resulta em -3. MySQL e Oracle fornecem um resultado decimal para /. No SQLite e no PostgreSQL, torne um operando decimal antes de dividir: 7 / 2.0, 7 * 1.0 / 2 ou CAST(7 AS REAL) / 2 resulta em 3.5. CAST(7 / 2 AS REAL) chega tarde demais e resulta em 3.0.

Para uma alta de 80 para 92, (92 - 80) * 100.0 / 80 resulta em 15.0 por cento. Dividir primeiro a diferença inteira por 80 perde a fração. O módulo mantém a parte restante: 135 / 60 é 2 horas e 135 % 60 é 15 minutos. No SQLite e no PostgreSQL, -7 % 3 resulta em -1; o resto segue o sinal do operando à esquerda. Oracle usa MOD(17, 5) em vez de %.

Um divisor zero gera erro no PostgreSQL e no SQL Server; SQLite e MySQL retornam NULL. amount / NULLIF(divisor, 0) faz o caso de zero retornar NULL nesses sistemas.

Arredonde ou escolha um inteiro

ROUND(x, n) arredonda para n casas decimais. Uma luminária com preço de 24,00 e custo de 15,50 tem lucro 8.5. ROUND((price - cost) / price * 100, 1) resulta em uma margem de 35.4 por cento. PostgreSQL aceita uma quantidade negativa de casas: ROUND(1234.5678, -2) resulta em 1200; SQLite trata a quantidade de casas como zero e resulta em 1235.0.

PostgreSQL fornece essas funções. SQLite fornece ABS; CEIL, FLOOR e TRUNC exigem uma compilação com funções matemáticas, disponíveis a partir da versão 3.35.

Ajuste a precisão aos dados

ROUND do SQLite e ROUND para numeric do PostgreSQL arredondam valores exatamente na metade para longe de zero: ROUND(-2.5) resulta em -3. O arredondamento de ponto flutuante do PostgreSQL geralmente arredonda valores na metade para o inteiro par mais próximo; seu ROUND com dois argumentos exige numeric, então use ROUND(CAST(x AS numeric), 2) para uma coluna de precisão dupla.

Números de ponto flutuante aproximam muitas frações decimais. SQLite pode considerar 0.1 + 0.2 = 0.3 falso e fazer ROUND(2.675, 2) retornar 2.67. Os literais decimais do PostgreSQL usam numeric exato. Para valores monetários exatos, use NUMERIC/DECIMAL no PostgreSQL ou centavos armazenados como inteiros no SQLite. Declarar DECIMAL no SQLite não cria armazenamento decimal exato. Mantenha a precisão durante os cálculos e arredonde para exibição.

O tipo de dados de um valor afeta operações aritméticas, comparações e ordenação. O número 42 é diferente do texto '42', mesmo quando uma grade de resultados os exibe da mesma forma.

Converta um valor explicitamente

Tipos comuns incluem INTEGER para números inteiros, NUMERIC ou DECIMAL para decimais exatos no PostgreSQL, REAL ou double precision para números aproximados, TEXT ou VARCHAR para texto e DATE, TIME, TIMESTAMP e BOOLEAN quando disponíveis.

SELECT CAST('42' AS INTEGER) AS number_value,
       CAST(42 AS TEXT) AS text_value;

CAST(expression AS type) faz parte da SQL padrão. O primeiro resultado é um número; o segundo é texto. PostgreSQL também aceita '42'::integer. Converter NULL continua resultando em NULL.

Para divisão decimal no SQLite, escreva CAST(quantity AS REAL) / 4; no PostgreSQL, escreva CAST(quantity AS NUMERIC) / 4. Uma quantidade de 7 resulta em 1.75. CAST(7 AS NUMERIC) / 2 do SQLite ainda resulta em 3: NUMERIC deixa esse valor inteiro armazenado como inteiro. REAL é a conversão adequada no SQLite para esse fim.

Entenda o que uma conversão para inteiro faz

SQLite remove uma fração em direção a zero. PostgreSQL arredonda um valor numérico para o inteiro mais próximo. Use ROUND, TRUNC, FLOOR ou CEIL primeiro quando a regra pretendida for importante. PostgreSQL rejeita texto que não é um número válido. SQLite lê uma parte numérica inicial: '12abc' torna-se 12 e '12.5' torna-se 12 quando convertido para INTEGER. Portanto, zero após uma conversão no SQLite não prova que o texto original era um zero válido. TRY_CAST do SQL Server retorna NULL quando uma conversão falha.

Separe quantidades de identificadores

Texto é ordenado caractere por caractere. As cadeias '9', '10' e '100' são ordenadas como '10', '100', '9'. Para ordenar quantidades realmente numéricas mantidas como texto, use ORDER BY CAST(code AS INTEGER) depois de verificar que são números válidos.

Um código postal dos Estados Unidos como '02134' é um identificador. Convertê-lo resulta em 2134 e perde o primeiro zero. Números de telefone também devem ser texto: seus algarismos identificam algo, em vez de descrever uma quantidade a ser somada ou usada em uma média.

Reconheça conversões automáticas

SQLite e PostgreSQL convertem o número em texto em 'Order #' || 42, produzindo 'Order #42'. Ambos também avaliam o literal entre aspas em '5' + 3 como número. No PostgreSQL, esse literal tem inicialmente um tipo ainda não definido; uma coluna TEXT não tem a mesma flexibilidade. Adicionar 3 a uma coluna TEXT falha, então converta a coluna explicitamente.

SQLite dá às colunas uma preferência de tipo, chamada afinidade de tipo, e pode manter diferentes tipos de valores em uma coluna comum. typeof(42), typeof(4.2), typeof('42') e typeof(NULL) informam 'integer', 'real', 'text' e 'null'. SQLite não tem um tipo DATE específico: CAST('2026-03-14' AS DATE) resulta em 2026. Use date('2026-03-14') para suas funções de data.

Oracle fornece TO_NUMBER, TO_CHAR e TO_DATE. TO_CHAR e TO_DATE do PostgreSQL recebem máscaras de formatação como 'MM/DD/YYYY'. CONVERT do SQL Server usa um código numérico de estilo: CONVERT(date, '03/14/2026', 101) lê o formato de data dos Estados Unidos.

NULL indica um valor ausente ou desconhecido. Uma célula de resultado em branco pode exibir NULL, mas NULL não é um valor comum que você compara com =.

Acompanhe uma entrada ausente em uma expressão

Zero é um número conhecido. Texto vazio, '', é uma cadeia conhecida sem caracteres. O texto 'N/A' é um rótulo registrado. NULL indica que nenhum valor está disponível. Oracle trata texto vazio como NULL; SQLite e PostgreSQL os distinguem.

A maioria das operações aritméticas e funções propaga uma entrada ausente como NULL. Com salário de 50.000 e bônus NULL, salary + bonus resulta em NULL. O total é desconhecido porque o bônus é desconhecido. UPPER(NULL), ROUND(NULL, 2) e 'Ana ' || NULL também retornam NULL no SQLite e no PostgreSQL.

Teste NULL diretamente

bonus = NULL, bonus <> NULL e até NULL = NULL produzem UNKNOWN. Não se sabe se dois valores ausentes são iguais. Use bonus IS NULL ou bonus IS NOT NULL. Esses testes sempre retornam TRUE ou FALSE.

Condições SQL têm três resultados possíveis: TRUE, FALSE e UNKNOWN. SQLite exibe TRUE como 1, FALSE como 0 e UNKNOWN como NULL.

Entenda quais linhas WHERE mantém

WHERE mantém apenas TRUE. FALSE e UNKNOWN excluem a linha. Para bônus de 1000, 0, NULL, 2500 e NULL, WHERE bonus < 1000 mantém apenas o zero. WHERE bonus >= 1000 mantém 1000 e 2500. Esses filtros abrangem três linhas, não cinco. WHERE NOT (bonus < 1000) também mantém apenas os dois bônus conhecidos de pelo menos 1000.

O mesmo problema afeta <>. Com as cidades Boston, Denver, NULL, Boston e Austin, WHERE city <> 'Boston' mantém Denver e Austin. Inclua explicitamente a cidade desconhecida:

WHERE city <> 'Boston' OR city IS NULL

Isso mantém três linhas. NOT não traz automaticamente de volta os valores ausentes.

Observe listas e comparações

3 IN (1, 2, NULL) é UNKNOWN: o elemento ausente pode ser 3. Para x NOT IN (1, 2, NULL), um valor correspondente não passa em NOT IN e qualquer valor sem correspondência resulta em UNKNOWN. Em uma cláusula WHERE, essa lista fixa não mantém nenhuma linha. Remova um NULL não intencional de uma lista de exclusão antes de usá-la.

Para uma igualdade que trata dois valores NULL como iguais, use a IS NOT DISTINCT FROM b. Seu oposto, a IS DISTINCT FROM b, é TRUE quando um valor é NULL e o outro não; dois valores NULL não são distintos. PostgreSQL e SQLite a partir da versão 3.39 aceitam essas formas. SQLite também tem IS e IS NOT; MySQL escreve a igualdade segura com NULL como <=>.

Os padrões de ordenação de NULL diferem: SQLite coloca NULL primeiro em ordem crescente; PostgreSQL o coloca por último. Declare a posição quando ela for importante: ORDER BY bonus DESC NULLS LAST coloca bônus conhecidos em ordem decrescente e bônus ausentes no fim.

Às vezes, valores ausentes precisam de um valor alternativo e, às vezes, devem continuar ausentes. Essa escolha faz parte do significado de um relatório. COALESCE preenche uma lacuna; NULLIF transforma um valor marcador correspondente em uma lacuna.

Escolha o primeiro valor disponível

COALESCE(a, b, ...) verifica da esquerda para a direita e retorna o primeiro argumento que não é NULL. Ela retorna NULL se todos os argumentos forem NULL.

SELECT COALESCE(mobile_phone, home_phone, 'no phone') AS contact
FROM customers;

Sem número de celular e com telefone residencial '555-0100', o contato é '555-0100'. Se nenhum dos números estiver registrado, é 'no phone'. Um zero conhecido ou uma cadeia vazia conta como disponível: COALESCE ignora NULL, não valores que parecem vazios ou falsos.

Para remuneração, salary + COALESCE(bonus, 0) resulta em 50.000 quando o salário é 50.000 e o bônus é NULL. Isso é adequado quando um bônus ausente significa que nenhum foi pago. Uma avaliação de produto ausente não significa uma avaliação zero; substituí-la inventaria uma avaliação ruim. Deixe esse número ausente ou crie um rótulo de texto para exibição.

Mantenha os tipos dos valores alternativos compatíveis

PostgreSQL não consegue combinar o inteiro rating com o texto 'not rated' em um único resultado numérico. Converta primeiro as avaliações conhecidas em texto:

COALESCE(CAST(rating AS TEXT), 'not rated')

Uma avaliação de 4 é exibida como o texto '4'; um NULL é exibido como 'not rated'. SQLite aceita uma mistura de argumentos numéricos e de texto, mas a saída pode conter tipos diferentes. Deixe claro o tipo de resultado pretendido ao transferir uma consulta entre bancos de dados.

COALESCE faz parte da SQL padrão e aceita dois ou mais argumentos. As alternativas comuns com dois argumentos são IFNULL no SQLite e no MySQL, ISNULL no SQL Server e NVL no Oracle.

Transforme um valor marcador em NULL

NULLIF(a, b) retorna NULL se os argumentos forem iguais; caso contrário, retorna o primeiro argumento. NULLIF(0, 0) é NULL, enquanto NULLIF(5, 0) é 5.

Uma expressão útil para uma taxa é:

orders * 100.0 / NULLIF(visits, 0) AS conversion_pct

Com 12 pedidos e 300 visitas, o divisor permanece 300 e a taxa é 4.0. Com zero visitas, o divisor torna-se NULL e a taxa torna-se NULL. PostgreSQL evita um erro de divisão por zero, e o resultado indica corretamente uma taxa indefinida. Substituir essa taxa por zero faria uma afirmação diferente.

Limpe lacunas antes de fornecer um rótulo

COALESCE(NULLIF(phone, ''), 'unknown')

O NULLIF interno transforma uma cadeia vazia em NULL. O COALESCE externo então atribui o rótulo 'unknown' tanto a um NULL original quanto a uma cadeia vazia. Um número de telefone registrado passa sem alterações.

Para um nome do meio opcional, inclua seu espaço final dentro do valor alternativo:

first_name || ' ' || COALESCE(middle_name || ' ', '') || last_name

Um nome do meio NULL não acrescenta nada, produzindo 'Ana Lopez'. Um nome do meio igual a 'Maria' acrescenta 'Maria ', produzindo 'Ana Maria Lopez'.

Essas expressões alteram apenas o resultado da consulta. Elas deixam os valores originais armazenados na tabela. Um filtro como WHERE COALESCE(bonus, 0) = 0 agrupa bônus conhecidos de valor zero e bônus ausentes, então use-o quando esses forem os dois grupos desejados.

A SQL trata um valor de texto como uma cadeia de caracteres. Funções de texto podem construir um nome completo ou organizar um endereço de e-mail para comparação. Seus resultados aparecem na consulta; o texto armazenado permanece inalterado.

Escreva e concatene texto

Literais de texto usam aspas simples. Para incluir um apóstrofo, duplique-o: 'O''Brien' representa “O'Brien”. Um par de aspas simples, '', é texto vazio.

SELECT first_name || ' ' || last_name AS full_name
FROM customers;

O operador de concatenação || junta as partes exatamente como foram escritas. Com 'Ana' e 'Lopez', o resultado é 'Ana Lopez'. O literal do meio fornece o espaço; a concatenação não insere um automaticamente.

SQLite, PostgreSQL e Oracle usam ||. O || padrão do MySQL significa OR, então use CONCAT nele. SQL Server usa + e também aceita || a partir de 2025. Para concatenar um identificador numérico de pedido, SQLite e PostgreSQL o convertem em texto em 'Order #' || order_id. Com + do SQL Server, converta o número primeiro: 'Order #' + CAST(order_id AS VARCHAR(10)).

Escolha como concatenar uma parte ausente

No SQLite e no PostgreSQL, um operando NULL torna o resultado de || NULL. Oracle trata essa parte ausente como texto vazio. CONCAT também varia conforme o banco de dados:

CONCAT do Oracle recebe exatamente dois argumentos. CONCAT_WS(' ', first_name, middle_name, last_name) coloca espaços entre as partes que não são NULL, então um nome do meio ausente resulta em 'Ana Lopez'. SQLite adicionou CONCAT e CONCAT_WS na versão 3.44. Ignorar NULL não remove uma cadeia vazia.

Converta maiúsculas e minúsculas e remova espaços das extremidades

UPPER('boston') resulta em 'BOSTON'; LOWER produz letras minúsculas. INITCAP('ana LOPEZ') do PostgreSQL resulta em 'Ana Lopez'. SQLite não tem INITCAP, e sua conversão integrada altera apenas as letras de A a Z: UPPER('é') permanece 'é' sem a extensão ICU. A conversão de maiúsculas e minúsculas do PostgreSQL segue sua configuração regional.

TRIM remove espaços nas duas extremidades; LTRIM os remove apenas no início e RTRIM apenas no fim. TRIM(' New York ') resulta em 'New York', mantendo os dois espaços internos. Para remover x das duas extremidades, SQLite usa TRIM('xxBostonxx', 'x'); PostgreSQL usa TRIM(BOTH 'x' FROM 'xxBostonxx').

Substitua caracteres e aninhe etapas de limpeza

REPLACE('555-0100', '-', '') resulta em '5550100'. Ela substitui cada ocorrência exata. Maiúsculas e minúsculas fazem diferença: substituir 'st' em 'Main St' não altera nada porque 'St' tem um S maiúsculo.

SELECT LOWER(TRIM(email)) AS email_clean
FROM customers;

Para ' Ana@Example.COM ', TRIM primeiro produz 'Ana@Example.COM', depois LOWER produz 'ana@example.com'. Aninhamento significa que a função mais interna fornece a entrada da próxima.

A igualdade comum de texto diferencia maiúsculas de minúsculas por padrão no SQLite e no PostgreSQL. WHERE LOWER(TRIM(email)) = 'ana@example.com' pode encontrar correspondências em entradas com diferentes usos de maiúsculas e minúsculas e com espaços nas extremidades. A colação padrão do MySQL ignora essa diferença, e LIKE do SQLite ignora a diferença entre maiúsculas e minúsculas de A a Z, embora sua comparação padrão com = não o faça.

Funções de texto localizam e recortam partes pela posição dos caracteres. A SQL começa as posições em 1, então o primeiro caractere está na posição 1. Uma posição encontrada e uma quantidade de caracteres são entradas diferentes.

Meça e recorte uma cadeia de caracteres

LENGTH('Boston') resulta em 6. Espaços contam: LENGTH(' Bo ') resulta em 4. Texto vazio tem comprimento 0; LENGTH(NULL) é NULL. LENGTH do MySQL conta bytes, então use CHAR_LENGTH para caracteres nesse sistema. SQL Server usa LEN, que ignora espaços no final.

SELECT SUBSTR('Boston', 1, 3) AS beginning,
       SUBSTR('Boston', 4) AS ending;

Os resultados são 'Bos' e 'ton'. A primeira chamada extrai três caracteres a partir da posição 1. A segunda omite a quantidade e extrai tudo a partir da posição 4. PostgreSQL também usa SUBSTRING('Boston' FROM 4 FOR 3). SQLite aceita SUBSTRING como nome a partir da versão 3.34. SQL Server usa SUBSTRING(text, start, count); a quantidade é obrigatória até a versão 2022 e opcional a partir da versão 2025.

SQLite pode contar a partir da direita: SUBSTR('Boston', -3) resulta em 'ton'. Posições iniciais negativas no PostgreSQL não contam de trás para a frente a partir do fim. Use RIGHT('Boston', 3) nesse sistema; LEFT extrai caracteres do início. SQLite não tem LEFT nem RIGHT.

Encontre o ponto de divisão

INSTR(text, search) do SQLite retorna a primeira posição correspondente. PostgreSQL usa STRPOS ou POSITION(search IN text). Essas funções retornam 0 quando não encontram correspondência. A busca diferencia maiúsculas de minúsculas: INSTR('Ana', 'a') é 3.

Em 'ana@example.com', o @ está na posição 4. O nome de usuário termina logo antes dele; o domínio começa logo depois:

SUBSTR(email, 1, INSTR(email, '@') - 1) AS user_name,
SUBSTR(email, INSTR(email, '@') + 1) AS domain

A primeira expressão torna-se SUBSTR(email, 1, 3) e produz 'ana'. A segunda começa na posição 5 e produz 'example.com'. Omitir - 1 inclui @ no nome de usuário. Omitir + 1 o inclui no início do domínio. No PostgreSQL, substitua INSTR por STRPOS ou use SPLIT_PART(email, '@', 2) para o domínio.

Trate um separador ausente

Para 'anaexample.com', INSTR retorna 0. A fórmula do domínio começa na posição 1 e retorna toda a cadeia, produzindo um resultado enganoso. A fórmula do nome de usuário no SQLite resulta em texto vazio; PostgreSQL rejeita seu comprimento negativo de subcadeia. Proteja a extração:

CASE
  WHEN INSTR(email, '@') > 0
  THEN SUBSTR(email, INSTR(email, '@') + 1)
END

Isso retorna NULL quando o separador está ausente. A verificação procura um separador, não todas as regras de um endereço de e-mail válido.

Crie rótulos curtos e códigos de largura fixa

SUBSTR(first_name, 1, 1) || '. ' || last_name resulta em 'A. Lopez' para Ana Lopez. WHERE LENGTH(zip_code) <> 5 encontra cadeias de códigos postais dos Estados Unidos registradas com comprimento incorreto; comprimentos NULL produzem UNKNOWN e são excluídos.

LPAD('42', 5, '0') do PostgreSQL resulta em '00042'; RPAD preenche à direita. SQLite pode construir esse código com SUBSTR('00000' || 42, -5). Manter apenas cinco caracteres também corta um valor mais longo, então essa expressão de largura fixa precisa de um código que caiba nela.

É mais fácil calcular com uma data quando seu armazenamento e sua forma de escrita são claros. O texto '03/04/2026' pode significar 4 de março ou 3 de abril. Uma data ISO, '2026-03-14', coloca ano, mês e dia em uma ordem sem ambiguidade.

Associe o valor ao seu tipo

PostgreSQL tem DATE para um dia do calendário, TIME para uma hora do dia e TIMESTAMP para uma data e hora. Seu TIMESTAMP WITH TIME ZONE, também chamado timestamptz, armazena um instante em UTC e o exibe no fuso horário da sessão. Um TIMESTAMP simples não associa esse significado de fuso.

SQLite armazena datas e horas como texto ISO ou como números, sem tipos específicos de data e hora. As formas numéricas incluem números de dias julianos e tempo Unix. As funções de data interpretam esses valores e retornam uma data, uma hora ou uma medida numérica.

Use texto ISO de largura fixa, como '2026-03-14', incluindo zeros iniciais. Adicione uma hora usando o formato de 24 horas: '2026-03-14 09:30:00'. O literal tipado DATE '2026-03-14' do PostgreSQL cria explicitamente uma data.

Preserve a ordem cronológica

Texto ISO de largura fixa é comparado em ordem de data porque começa pela maior parte. '2026-03-14' vem antes de '2026-11-02'. Texto de exibição no formato dos Estados Unidos não tem essa propriedade: como cadeias de caracteres, '11/02/2025' é ordenado depois de '03/14/2026', embora sua data seja anterior.

O interpretador do SQLite precisa do formato aceito. date('2026-3-14') retorna NULL porque o mês não tem dois algarismos. Ele também pode normalizar uma data impossível: date('2026-02-30') retorna '2026-03-02'. Um resultado diferente de NULL, por si só, não prova que a entrada era um dia válido do calendário. PostgreSQL rejeita DATE '2026-02-30'.

Leia texto em outro formato

PostgreSQL e Oracle usam TO_DATE('03/14/2026', 'MM/DD/YYYY') para ler o formato dos Estados Unidos. PostgreSQL também lê texto ISO com CAST('2026-03-14' AS DATE) ou '2026-03-14'::date.

SQLite não tem um interpretador TO_DATE. Para texto em d no formato fixo MM/DD/YYYY, reconstrua o texto ISO:

SUBSTR(d, 7, 4) || '-' ||
SUBSTR(d, 1, 2) || '-' || SUBSTR(d, 4, 2)

As partes são o ano '2026', o mês '03' e o dia '14'. O resultado é '2026-03-14', que as funções de data do SQLite podem ler. As posições dependem de a entrada realmente usar o formato fixo.

Obtenha a data e a hora atuais

CURRENT_DATE e CURRENT_TIMESTAMP funcionam no SQLite e no PostgreSQL. SQLite retorna texto em UTC; date('now', 'localtime') fornece a data local. Perto da meia-noite, a data do calendário em UTC e a local podem ser diferentes.

PostgreSQL usa o fuso horário da sessão. CURRENT_TIMESTAMP e NOW() refletem o início da transação atual, então esperar dentro dessa transação não faz seus valores avançarem. MySQL oferece NOW() e CURDATE(); SQL Server tem GETDATE() e SYSDATETIME(); Oracle tem SYSDATE, que inclui uma hora, e CURRENT_DATE.

Para verificar um cálculo de vencimento, use primeiro uma data fixa de referência, como DATE '2026-10-21' no PostgreSQL ou '2026-10-21' no SQLite. Assim, você pode comparar o resultado com um calendário sem que a resposta mude no dia seguinte.

Extraia uma parte de uma data quando precisar de um ano ou dia da semana para calcular. Formate uma data quando precisar de texto para um leitor. Essas operações podem produzir tipos diferentes mesmo quando os caracteres exibidos parecem iguais.

Extraia um ano, mês ou dia da semana

PostgreSQL usa a forma padrão EXTRACT(part FROM value). Para DATE '2026-03-14', extrair YEAR resulta em 2026 e MONTH resulta em 3, ambos como números. MySQL e Oracle também aceitam EXTRACT.

SQLite usa strftime(format, value), que retorna texto:

%w do SQLite e DOW do PostgreSQL numeram os dias de domingo como 0 até sábado como 6. 14 de março de 2026 é sábado. Já ISODOW do PostgreSQL numera os dias de segunda-feira como 1 até domingo como 7. Um filtro de fim de semana no SQLite é WHERE strftime('%w', order_date) IN ('0', '6').

Compare os tipos corretos

strftime('%m', order_date) = 3 é falso para uma data de março no SQLite: a função retorna o texto '03', não o número 3. Compare-o com = '03' ou converta primeiro:

CAST(strftime('%m', order_date) AS INTEGER) = 3

Isso também é útil na expressão de trimestre (CAST(strftime('%m', d) AS INTEGER) + 2) / 3. A divisão inteira resulta no trimestre 1 para março e no trimestre 4 para novembro. PostgreSQL tem EXTRACT(QUARTER FROM d) diretamente.

Identifique um mês como um período completo

strftime('%Y-%m', order_date) cria um rótulo no SQLite como '2026-03'. date(order_date, 'start of month') cria '2026-03-01'. PostgreSQL pode usar TO_CHAR(order_date, 'YYYY-MM') para um rótulo ou DATE_TRUNC('month', order_date) para o primeiro instante desse mês.

Mantenha o ano em um rótulo de período. Um valor de mês isolado igual a 3 combinaria marços de anos diferentes. O valor do primeiro dia do mês pode continuar sendo usado para cálculo e ordenação, enquanto uma expressão separada fornece a exibição.

Formate na etapa de saída

No PostgreSQL, TO_CHAR(DATE '2026-03-14', 'MM/DD/YYYY') resulta em '03/14/2026', e a máscara 'Mon DD, YYYY' resulta em 'Mar 14, 2026'. Oracle também usa essas máscaras. O formato dos Estados Unidos no SQLite é strftime('%m/%d/%Y', '2026-03-14').

As letras das máscaras dependem do banco de dados. MM no PostgreSQL significa mês e MI significa minuto. %m no SQLite significa mês e %M significa minuto; mudar a letra maiúscula altera a informação solicitada.

SELECT TO_CHAR(order_date, 'MM/DD/YYYY') AS order_day
FROM orders
ORDER BY order_date;

Aqui PostgreSQL exibe texto legível, mas ordena as datas reais. Ordenar por order_day ordenaria as cadeias de exibição primeiro pelo mês e poderia colocar datas de anos diferentes fora de ordem.

Cálculos com o calendário devem levar em conta a duração dos meses, os componentes de hora e o tipo de resposta necessário. Uma quantidade de dias, um mês do calendário e um ano completo de idade são medidas diferentes.

Adicione dias e meses do calendário

PostgreSQL usa DATE '2026-03-14' + 30; SQLite usa date('2026-03-14', '+30 days'). Ambos chegam a 13 de abril: 17 dias completam março e outros 13 chegam a 13 de abril. Já a expressão direta do SQLite '2026-03-14' + 30 resulta em 2056, pois a operação aritmética lê o ano inicial como número.

Fins de mês exigem uma regra explícita. DATE '2026-01-31' + INTERVAL '1 month' do PostgreSQL resulta em 28 de fevereiro à meia-noite, usando o último dia disponível. date('2026-01-31', '+1 month') do SQLite transfere os dias excedentes para março e resulta em '2026-03-03'. A partir do SQLite 3.46, adicione 'floor' após o deslocamento para escolher '2026-02-28'. ADD_MONTHS do Oracle também passa para o último dia do mês mais curto.

Meça o tempo decorrido

A subtração de valores DATE no PostgreSQL retorna dias completos: DATE '2026-04-13' - DATE '2026-03-14' é 30. SQLite subtrai valores numéricos de dias: julianday('2026-04-13') - julianday('2026-03-14') é 30.0. SQL Server usa DATEDIFF(day, start, end); MySQL usa DATEDIFF(end, start).

Para timestamps de 14 de março das 09:30 às 18:00, a subtração no PostgreSQL resulta em um intervalo de 08:30:00; EXTRACT(EPOCH FROM interval) / 3600 o expressa como 8,5 horas. SQLite a partir da versão 3.38 pode usar:

(unixepoch('2026-03-14 18:00') -
 unixepoch('2026-03-14 09:30')) / 3600.0

Isso resulta em 8.5. Uma diferença de dias julianos multiplicada por 24 pode resultar em 8.49999999627471 devido à aproximação de ponto flutuante; arredonde para exibição. Uma duração fracionária entre timestamps não deve ser convertida para INTEGER antes de calcular a unidade desejada.

Conte aniversários completos

Uma pessoa nascida em 2 de novembro de 1990 tem 35 anos em 21 de outubro de 2026. Os números dos anos diferem em 36, mas o aniversário ainda não chegou. PostgreSQL usa EXTRACT(YEAR FROM AGE(DATE '2026-10-21', DATE '1990-11-02')), resultando em 35.

SQLite subtrai um se o aniversário deste ano ainda estiver por vir:

strftime('%Y', '2026-10-21') - strftime('%Y', birth_date)
- (strftime('%m-%d', '2026-10-21') < strftime('%m-%d', birth_date))

A comparação produz 1 quando o aniversário ainda está por vir e 0 caso contrário. Dividir os dias decorridos por 365 não é confiável: em 1º de novembro de 2026, essa pessoa viveu 13.148 dias, que divididos por 365 resultam em 36,02, embora o 36º aniversário seja amanhã. DATEDIFF do SQL Server conta fronteiras: passar de 31 de dezembro para 1º de janeiro conta como uma fronteira de ano, não como um ano completo de idade.

Inclua todos os timestamps de um período

BETWEEN inclui ambos os extremos. Para colunas DATE, de 1º a 31 de março abrange março. Para timestamps, um limite superior de '2026-03-31' significa meia-noite no início do último dia e deixa o restante dele de fora.

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

Esse intervalo fechado à esquerda e aberto à direita inclui o início e exclui o início do próximo período, abrangendo todos os horários de março sem escolher uma fração final de segundo.

Datas vencidas satisfazem due_date < CURRENT_DATE. O limite inferior para os últimos 30 dias no PostgreSQL é CURRENT_DATE - 30; no SQLite é date('now', '-30 days'). Os dias até um prazo são dados por due_date - CURRENT_DATE para valores DATE no PostgreSQL e por julianday(due_date) - julianday(date('now')) no SQLite.

Uma expressão CASE escolhe um resultado para cada linha. Você pode usá-la para atribuir um rótulo a uma faixa de preço, calcular uma taxa ou marcar um registro que exige atenção.

Leia a forma pesquisada

CASE
  WHEN total < 50 THEN 'small'
  WHEN total < 200 THEN 'medium'
  ELSE 'large'
END AS size_band

Cada WHEN fornece uma condição, e THEN fornece o valor a retornar se essa condição for TRUE. O banco de dados verifica de cima para baixo e escolhe a primeira condição verdadeira. END fecha a expressão; um apelido pode vir depois. Se nenhuma condição for TRUE e ELSE estiver ausente, o resultado é NULL.

Um total de 35 atende à primeira condição e recebe 'small'. Um total de 50 não passa na primeira, mas atende à segunda, recebendo 'medium'. O mesmo acontece com 199,99. Um total de 200 chega ao ELSE e recebe 'large'.

Faça a ordem e as fronteiras corresponderem à regra

O segundo ramo não precisa de total >= 50: um valor abaixo de 50 já retornou do primeiro ramo. Limites crescentes com < funcionam porque os ramos anteriores removem os valores menores. Limites decrescentes com >= podem funcionar pelo mesmo motivo.

Colocar WHEN total < 200 primeiro torna um ramo posterior < 50 inalcançável. Um total de 35 já satisfaz < 200, então para nesse ponto. CASE não escolhe a condição mais específica nem verifica qual rótulo parece melhor.

Compare a regra de negócio com cada extremo. < 50 coloca exatamente 50 na faixa média; <= 50 o coloca na faixa pequena. Verifique 49,99, 50, 199,99 e 200 para observar os dois lados e as fronteiras. Se as condições forem escritas como intervalos explícitos, ajuste seus extremos sem deixar lacunas ou sobreposições indesejadas.

Trate NULL antes dos intervalos comuns

Um total NULL torna ambas as comparações UNKNOWN. Na primeira expressão, ele chega ao ELSE e recebe 'large', o que é enganoso. Capture a ausência primeiro:

CASE
  WHEN total IS NULL THEN 'unknown'
  WHEN total < 50 THEN 'small'
  WHEN total < 200 THEN 'medium'
  ELSE 'large'
END

ELSE significa “nenhuma condição foi verdadeira”, então pode capturar entradas ausentes e também valores conhecidos fora dos intervalos testados.

Retorne um tipo consistente de valor

PostgreSQL precisa de tipos compatíveis em THEN e ELSE. CASE WHEN quantity > 0 THEN unit_price ELSE 'n/a' END falha se unit_price for numérico, pois 'n/a' não pode se tornar um número. Use NULL para um resultado numérico indisponível ou converta o preço em texto se toda a saída for um rótulo de exibição. SQLite permite tipos de resultado mistos, o que pode complicar cálculos posteriores.

Uma condição pode combinar colunas:

CASE
  WHEN country = 'US' AND subtotal >= 100 THEN 0
  ELSE 7.99
END AS shipping_fee

A taxa retornada pode aparecer dentro de subtotal + CASE ... END AS amount_due. Um CASE é uma expressão de valor, não um comando que edita várias colunas; cada coluna de resultado precisa de sua própria expressão.

CASE também pode proteger uma divisão em cada linha: CASE WHEN visits = 0 THEN NULL ELSE orders * 100.0 / visits END. Uma linha com zero seleciona o ramo NULL. orders * 100.0 / NULLIF(visits, 0) expressa a mesma regra para uma taxa ausente de forma mais breve.

A forma CASE simples traduz um valor em outro. CASE pesquisado testa condições; CASE simples compara a mesma expressão com uma série de valores.

Traduza códigos com CASE simples

CASE status
  WHEN 'S' THEN 'Shipped'
  WHEN 'P' THEN 'Pending'
  WHEN 'C' THEN 'Canceled'
  ELSE 'Other'
END AS status_label

Os testes implícitos são status = 'S', depois status = 'P' e depois status = 'C'. Um status fora desses códigos recebe 'Other'. A forma pesquisada pode escrever os mesmos testes de igualdade explicitamente. Escolha CASE pesquisado para intervalos, padrões LIKE, testes de NULL ou condições envolvendo várias colunas.

CASE region WHEN NULL THEN 'missing' ELSE region END não consegue capturar uma região NULL. Seu region = NULL implícito é UNKNOWN, então a linha chega ao ELSE e permanece NULL. Escreva CASE WHEN region IS NULL THEN 'missing' ELSE region END.

Atribua uma prioridade de ordenação personalizada

A ordem alfabética das prioridades é high, low, medium. Para ordenar por urgência, traduza os rótulos em números:

SELECT ticket_id, priority
FROM tickets
ORDER BY CASE priority
           WHEN 'high' THEN 1
           WHEN 'medium' THEN 2
           WHEN 'low' THEN 3
           ELSE 4
         END;

A ordem crescente agora coloca high antes de medium e medium antes de low, com outros valores ou valores ausentes por último. O CASE é uma expressão de ordenação; ele não precisa ser uma coluna exibida. Usar DESC inverteria a classificação numérica.

Crie um indicador numérico

CASE WHEN discount_pct > 0 THEN 1 ELSE 0 END AS is_discounted

Um percentual positivo recebe 1; um zero conhecido recebe 0. Um percentual NULL também recebe 0 porque > 0 é UNKNOWN e ELSE o captura. Portanto, esse indicador significa “há um desconto positivo registrado”. Ele não preserva a distinção entre nenhum desconto e um desconto desconhecido. Se essa distinção for necessária, adicione um ramo IS NULL com seu próprio resultado.

Indicadores podem ser selecionados, ordenados, filtrados ou incluídos em operações aritméticas. Em uma cláusula WHERE portátil, repita a expressão ou use sua condição original em vez de se referir a um apelido de saída recém-definido.

Reconheça funções condicionais relacionadas

COALESCE(bonus, 0) é uma forma curta de CASE WHEN bonus IS NOT NULL THEN bonus ELSE 0 END. NULLIF(a, b) corresponde a CASE WHEN a = b THEN NULL ELSE a END. Seus nomes comunicam diretamente essas finalidades comuns.

SQLite a partir da versão 3.32 e SQL Server têm IIF(condition, true_value, false_value); MySQL tem IF. DECODE do Oracle traduz correspondências de igualdade, por exemplo, DECODE(status, 'S', 'Shipped', 'P', 'Pending', 'Other'). DECODE trata dois valores NULL como iguais, ao contrário das comparações de igualdade no CASE simples. CASE padrão funciona nesses sistemas.

Um CASE pode conter outro CASE, mas condições combinadas muitas vezes tornam uma expressão sem aninhamento mais clara. Uma regra de envio pode usar diretamente WHEN country = 'US' AND subtotal >= 100 THEN 0, mantendo juntos os testes de país e subtotal.

Um relatório pode limpar nomes, calcular totais líquidos, identificar meses e atribuir rótulos à velocidade de envio em um único SELECT. Construa cada expressão a partir de suas entradas e confira o resultado antes de combiná-la com as outras.

Trabalhe com linhas conhecidas

Uma tabela de pedidos contém estes registros. As datas são texto ISO para a consulta SQLite abaixo; quantity é um inteiro e unit_price é numérico.

Aqui um desconto ausente significa que não há desconto. Comece recuperando os campos originais. Adicione uma coluna calculada de cada vez e use LIMIT 5 enquanto verifica uma pequena amostra.

Acompanhe um cálculo aninhado

ROUND(quantity * unit_price *
      (1 - COALESCE(discount_pct, 0) / 100.0), 2)

COALESCE fornece primeiro um desconto conhecido. Dividir por 100.0 preserva sua fração. Subtrair de 1 fornece a fração paga, a multiplicação fornece o valor líquido e ROUND define a precisão final. O valor de Ana é 33,75, o de Ben é 240,0 e o de Chen é 51,0. O desconto NULL de Chen torna-se zero; já uma data de envio ausente deve permanecer ausente na contagem de dias.

Monte o relatório no SQLite

SELECT order_id,
       first_name || ' ' || last_name AS customer,
       ROUND(quantity * unit_price *
         (1 - COALESCE(discount_pct, 0) / 100.0), 2) AS net_total,
       strftime('%Y-%m', order_date) AS order_month,
       CAST(julianday(shipped_date) - julianday(order_date)
         AS INTEGER) AS days_to_ship,
       CASE
         WHEN shipped_date IS NULL THEN 'not shipped'
         -- fast = shipped within 2 days
         WHEN julianday(shipped_date) - julianday(order_date) <= 2
           THEN 'fast'
         ELSE 'standard'
       END AS shipping
FROM orders
ORDER BY order_id;

Cada expressão tem um apelido de saída claro. A diferença numérica de dias é convertida para INTEGER porque esses valores contêm apenas datas. O ramo IS NULL vem antes da comparação de velocidade, então um pedido não enviado recebe um rótulo útil.

A saída é:

Adapte tipos e cláusulas da consulta

Para colunas DATE no PostgreSQL, use TO_CHAR(order_date, 'YYYY-MM') para o mês e shipped_date - order_date para a contagem de dias e a comparação no CASE. Mantenha unit_price como numeric exato para ROUND com dois argumentos. A concatenação, o valor alternativo do desconto e a regra de classificação mantêm o mesmo significado.

Para filtrar totais arredondados acima de 50 em ambos os bancos de dados, repita a expressão completa do valor líquido em WHERE. Os pedidos 1002 e 1003 permanecem. SQLite também permite WHERE net_total > 50, mas PostgreSQL não consegue ver esse novo apelido na etapa de filtragem. ORDER BY net_total DESC funciona em ambos.

Ao transferir um relatório, confira os tipos e nomes de funções em cada expressão. Uma função de texto deve receber texto, um cálculo de data deve receber um valor de data aceito e um valor alternativo numérico deve expressar a regra pretendida. Mantenha cada saída em sua própria linha; um comentário curto pode definir um limite de negócio sem obscurecer a SQL.