SQL Tipos de Dados

Na aula CREATE TABLE, cada coluna ganhou um tipo: INTEGER, REAL, TEXT. O tipo diz que tipo de valor a coluna guarda: um número inteiro, um preço, um nome, uma data, um "sim ou não". Nesta aula você vai conhecer os tipos do SQL, com os nomes que eles têm no SQL padrão e em cada um dos bancos famosos, e vai ver por que escolher o tipo certo evita contas erradas, datas fora de ordem e CEPs que perdem o zero da frente.

Um aviso antes de começar: o SQLite, o banco que roda no editor do guia, é bem mais "relaxado" com os tipos do que os outros bancos. Ele aceita todos os nomes desta aula, mas trata vários deles do seu jeito. Nesta aula você vê o mapa geral; a próxima, Os Tipos no SQLite, mostra em detalhe o que o SQLite faz com cada um.

A ideia: os campos de um formulário

Pense na ficha de cadastro de cliente, em papel, que a Loja Aurora usava antes do computador:

Nome: ______________________________
Nascimento: __/__/____
CEP: [ ][ ][ ][ ][ ]-[ ][ ][ ]
Quer receber ofertas?  ( ) sim  ( ) não
Limite de crédito: R$ ________,__

Cada campo já diz o que cabe nele. Na data, três espaços: dia, mês, ano. No CEP, oito quadradinhos para algarismos. Nas ofertas, só duas respostas possíveis. No limite de crédito, reais e centavos. Ninguém escreve "abacaxi" no campo da data.

O tipo de uma coluna é esse "formato do campo". Ele serve para três coisas:

A segunda linha da tabela parece estranha? Veja com os seus olhos. O mesmo "10 é menor que 9?", uma vez com textos (entre aspas) e outra com números:

SELECT '10' < '9' AS como_texto,
       10 < 9     AS como_numero;

Como texto, a resposta é 1 ("verdadeiro"): o banco compara letra por letra, como num dicionário, e o caractere 1 vem antes do 9. Como número, a resposta é 0 ("falso"), a resposta certa. O valor é o mesmo; quem muda o resultado é o tipo.

1. Números inteiros

Inteiro é número sem casas decimais: quantidade em estoque, número do pedido, idade. O SQL padrão tem três tamanhos:

Um número fora da faixa dá erro nesses bancos (a documentação do PostgreSQL diz: tentar guardar um valor fora da faixa resulta em erro). Na dúvida, use INTEGER: é o que a Loja Aurora usa em todos os id, no estoque e na quantidade.

A divisão de inteiros

Inteiro com inteiro dá inteiro, até na divisão. A Ana quer dividir 7 caixas entre 2 lojas:

SELECT 7 / 2   AS inteiros,
       7 / 2.0 AS com_decimal,
       7.0 / 2 AS tambem_com_decimal;

7 / 2

Os dois são inteiros, então a conta é de inteiros: o resultado é 3, e o "meio" que sobrou é jogado fora (não é arredondado: é cortado).

7 / 2.0

Basta um dos dois ter casa decimal para a conta virar de número com decimais: 3.5.

7.0 / 2

Tanto faz qual dos dois: 3.5 de novo.

Esse comportamento é o mesmo no PostgreSQL e no SQL Server (a documentação da Microsoft diz: inteiro dividido por inteiro dá um inteiro, com a parte decimal cortada). O MySQL é exceção: lá, 3/5 dá 0.60, e a divisão inteira tem um operador próprio, DIV. No SQLite, ao dividir duas colunas INTEGER (como estoque / quantidade), lembre-se de multiplicar uma delas por 1.0.

SELECT 7 / 2 AS metade;

SELECT 7 / 2.0 AS metade;

2. Números com casas decimais: exatos e aproximados

Preço, frete, salário, peso. Aqui o SQL tem duas famílias, e a diferença entre elas é importante:

DECIMAL(p, s): precisão e escala

Os dois números entre parênteses dizem o tamanho do número:

DECIMAL

O tipo exato. NUMERIC é outro nome para a mesma coisa (no PostgreSQL e no SQL Server, os dois são idênticos).

p

A precisão: quantos algarismos o número tem no total, somando os de antes e os de depois da vírgula.

s

A escala: quantos desses algarismos ficam depois da vírgula.

O exemplo da documentação do PostgreSQL: o número 23.5141 tem precisão 6 (seis algarismos) e escala 4 (quatro depois do ponto). Para dinheiro, o comum é DECIMAL(10, 2): dez algarismos no total, dois de centavos, ou seja, até 99.999.999,99 reais. Nos bancos que levam o tipo a sério, um número com algarismos demais antes da vírgula dá erro, e casas a mais depois da vírgula são arredondadas.

O problema dos aproximados

Os tipos aproximados guardam o número em binário (zeros e uns), e alguns números que são "redondos" para nós, como 0,1, não têm uma escrita exata em binário, do mesmo jeito que 1/3 não tem uma escrita exata em decimal (0,3333…). O resultado é este:

SELECT 0.1 + 0.2       AS soma,
       0.1 + 0.2 = 0.3 AS igual,
       0.1 + 0.2 - 0.3 AS diferenca;

soma

Na tela aparece 0.3, porque o SQLite arredonda na hora de mostrar.

igual

Mas a comparação com 0.3 dá 0, "falso": por dentro, a soma não é exatamente 0,3.

diferenca

A sobra é minúscula: 5.55111512312578e-17, ou seja, 0,0000000000000000555… (o e-17 quer dizer "vezes 10 elevado a -17"). Pequena, mas basta para um WHERE total = 0.3 não achar nada.

Num relatório de vendas com milhares de linhas somadas, essas sobras se acumulam. É por isso que os bancos têm DECIMAL e que bancos e lojas o usam para dinheiro.

CREATE TABLE fretes (valor DECIMAL(10,2));
INSERT INTO fretes VALUES (0.1), (0.2);

SELECT sum(valor) AS soma, sum(valor) = 0.3 AS igual FROM fretes;

CREATE TABLE fretes (valor_centavos INTEGER);
INSERT INTO fretes VALUES (10), (20);

SELECT sum(valor_centavos)         AS centavos,
       sum(valor_centavos) / 100.0 AS em_reais,
       sum(valor_centavos) = 30    AS igual
FROM fretes;

3. Texto: CHAR, VARCHAR e TEXT

Nome, email, cidade, comentário. Três tipos, que diferem no tamanho:

O n do VARCHAR(n) funciona como os quadradinhos do formulário: se o texto passar do limite, os bancos rígidos recusam. No PostgreSQL, o exemplo da documentação é este (ilustrativo, não roda no SQLite):

CREATE TABLE test2 (b varchar(5));
INSERT INTO test2 VALUES ('too long');
-- ERROR:  value too long for type character varying(5)

"Valor longo demais para o tipo character varying(5)." O MySQL faz o mesmo no modo estrito (que faz parte do modo padrão do MySQL 8.4); fora do modo estrito, ele corta o texto e só dá um aviso.

Já o SQLite ignora o número entre parênteses. A Ana criou a coluna do estado com VARCHAR(2) e escreveu o nome inteiro, sem querer:

CREATE TABLE enderecos (uf VARCHAR(2));
INSERT INTO enderecos VALUES ('Piauí');

SELECT uf, length(uf) AS letras FROM enderecos;

Os cinco caracteres entraram sem reclamação. No SQLite, VARCHAR(2), VARCHAR(255) e TEXT dão no mesmo. Se você quer um limite de verdade no SQLite, ele se faz com a restrição CHECK (por exemplo, CHECK (length(uf) = 2)).

Número que não é número

CEP, telefone, CPF: são feitos de algarismos, mas não são números. Ninguém soma dois CEPs. E o pior: como número, o zero da frente desaparece. Veja o CEP 04567-000, de São Paulo, guardado numa coluna INTEGER:

CREATE TABLE enderecos (cliente_id INTEGER, cep INTEGER);
INSERT INTO enderecos VALUES (5, '04567000');

SELECT * FROM enderecos;

Saiu 4567000: o zero sumiu, e o CEP agora tem sete algarismos. Com TEXT (ou CHAR(8)), ele fica intacto:

CREATE TABLE enderecos (cliente_id INTEGER, cep TEXT);
INSERT INTO enderecos VALUES (5, '04567000');

SELECT * FROM enderecos;

A regra prática: se você não vai fazer conta com ele, é texto. Por isso o telefone dos fornecedores da Loja Aurora é TEXT: além do zero, ele tem parênteses, espaços, hífen e o +351 do fornecedor de Portugal.

4. Data e hora

Data do pedido, data de entrega, nascimento. O SQL padrão tem:

Repare na ordem: ano-mês-dia (o formato ISO 8601), e não dia/mês/ano como escrevemos no Brasil. É o formato que todos os bancos entendem. Cada banco tem os seus nomes extras: o MySQL tem DATETIME; o SQL Server, datetime2; o PostgreSQL, timestamp with time zone (data e hora com fuso).

O SQLite, de novo, é diferente: ele não tem tipo de data. As datas ficam guardadas como texto, no formato ISO, e as funções de data (aula Funções de Data) sabem fazer conta com esse texto. Os pedidos da Loja Aurora são assim:

SELECT id, data, date(data, '+7 days') AS uma_semana_depois
FROM pedidos
ORDER BY data DESC
LIMIT 3;

Por que o ISO e não o nosso formato? Porque o texto ISO se ordena como data: comparar '2026-10-02' com '2026-10-14' letra por letra dá a mesma resposta que comparar as datas. Com dia/mês/ano, não:

SELECT '2026-10-02' < '2026-10-14' AS iso,
       '02/10/2026' < '14/09/2026' AS brasileiro;

As duas perguntas deram 1 ("verdadeiro"). A primeira está certa: 2 de outubro vem antes de 14 de outubro. A segunda está errada: 2 de outubro vem depois de 14 de setembro, mas como texto, '02…' vem antes de '14…'. Um ORDER BY numa coluna com datas brasileiras sairia todo embaralhado.

5. Verdadeiro ou falso: BOOLEAN

"É VIP?", "Foi entregue?", "Está descontinuado?". Perguntas de sim ou não. O tipo do SQL padrão para isso é o BOOLEAN ("booleano", em homenagem ao matemático George Boole), com os valores TRUE ("verdadeiro") e FALSE ("falso"). Mas cada banco faz de um jeito:

SELECT TRUE, FALSE;

É por isso que as colunas vip (em clientes) e descontinuado (em produtos) da Loja Aurora são INTEGER com 0 ou 1. E dá para usar TRUE na consulta, que o SQLite entende como 1:

SELECT nome, vip FROM clientes WHERE vip = TRUE;

6. Binários: arquivos dentro do banco

Por fim, há tipos para guardar bytes "crus": uma foto, um PDF, um arquivo qualquer. No SQLite e no MySQL é o BLOB (de binary large object, "objeto binário grande"); no PostgreSQL, bytea (de byte array, "sequência de bytes"); no SQL Server, varbinary. Na prática, quase sempre é melhor guardar o arquivo numa pasta e, no banco, só o caminho dele (um TEXT como 'fotos/produto-3.jpg').

O mapa: cada tipo em cada banco

Os nomes mais usados, lado a lado. Os da coluna "SQL padrão" estão na lista de tipos do padrão SQL (a documentação do PostgreSQL traz essa lista na seção de compatibilidade). A última coluna diz o que o SQLite faz com o nome; a próxima aula explica essa "afinidade".

Qual tipo usar para cada dado

A tabela abaixo é o "gabarito" para os dados da Loja Aurora. A coluna do meio vale para os bancos rígidos; a da direita é o que a Loja Aurora usa no SQLite.

Quando dá errado

Escolher o tipo errado raramente dá erro na hora. O problema aparece depois, numa conta ou numa ordenação. Estes são os clássicos.

CREATE TABLE contagens (quantidade TEXT);
INSERT INTO contagens VALUES ('9'), ('10'), ('100');

SELECT quantidade FROM contagens ORDER BY quantidade;

SELECT 0.1 + 0.2 = 0.3 AS igual,
       round(0.1 + 0.2, 2) = 0.3 AS igual_arredondado;

CREATE TABLE fretes (pedido_id INTEGER, valor REAL);
INSERT INTO fretes VALUES (1, 12,50);

Referência rápida

Exercícios

Missão final: a tabela de entregas

CREATE TABLE entregas (
    id             INTEGER,
    pedido_id      INTEGER,
    transportadora TEXT,
    peso_kg        TEXT,
    saiu_em        TEXT,
    assinada       TEXT
);

INSERT INTO entregas VALUES (1, 86, 'Rápido Piauí', 1.25, '2026-10-02', FALSE);

PRAGMA table_info(entregas);

CREATE TABLE entregas (
    id             INTEGER,
    pedido_id      INTEGER,
    transportadora VARCHAR(60),
    peso_kg        DECIMAL(6,3),
    saiu_em        DATE,
    assinada       BOOLEAN
);

INSERT INTO entregas VALUES (1, 86, 'Rápido Piauí', 1.25, '2026-10-02', FALSE);

PRAGMA table_info(entregas);

Depois de cumprir a missão, acrescente SELECT *, typeof(saiu_em), typeof(assinada) FROM entregas; no fim e rode. O SQLite aceitou os nomes DATE e BOOLEAN, mas o que ele guardou de verdade em cada coluna é assunto da próxima aula.

Resumo

• O tipo de uma coluna diz que valor ela guarda, e muda as contas, as comparações e a ordenação: como texto, '10' < '9'.
• Inteiros: SMALLINT, INTEGER, BIGINT. Inteiro dividido por inteiro dá inteiro (7 / 2 = 3).
• Decimais: DECIMAL(p,s)/NUMERIC são exatos (dinheiro); REAL/DOUBLE PRECISION são aproximados (0.1 + 0.2 = 0.3 é falso). O SQLite aceita DECIMAL, mas guarda aproximado: use round() ou centavos.
• Texto: CHAR(n) fixo, VARCHAR(n) até n, TEXT livre. O SQLite ignora o n. CEP e telefone são texto.
• Datas: DATE, TIME, TIMESTAMP, sempre no formato AAAA-MM-DD. No SQLite, são texto ISO.
• Sim/não: BOOLEAN no padrão e no PostgreSQL, TINYINT(1) no MySQL, bit no SQL Server, 0/1 no SQLite.