A escolha entre CHAR e VARCHAR no Firebird afeta não apenas o armazenamento, mas também comparações e índices. Entenda as diferenças.
CHAR: tamanho fixo
CREATE TABLE produtos (
codigo CHAR(10) -- sempre ocupa 10 bytes, preenchido com espaços
);
- Armazena sempre o tamanho definido
- Preenche com espaços à direita (padding)
- Comparação ignora trailing spaces (padrão SQL)
VARCHAR: tamanho variável
CREATE TABLE produtos (
nome VARCHAR(100) -- ocupa apenas o necessário
);
- Armazena apenas os caracteres usados
- Sem padding
- Comparação é exata (incluindo espaços)
A armadilha da comparação
-- CHAR(10): 'ABC' armazenado como 'ABC '
SELECT * FROM produtos WHERE codigo = 'ABC'; -- ✅ encontra (ignora padding)
SELECT * FROM produtos WHERE codigo = 'ABC '; -- ✅ também encontra
-- VARCHAR: 'ABC' armazenado como 'ABC'
SELECT * FROM produtos WHERE nome = 'ABC'; -- ✅ encontra
SELECT * FROM produtos WHERE nome = 'ABC '; -- ❌ NÃO encontra (espaço extra)
Impacto em índices
-- Índice em CHAR pode ser ineficiente se houver padding inconsistente
CREATE INDEX idx_codigo ON produtos(codigo);
-- Índice em VARCHAR é mais eficiente para buscas exatas
CREATE INDEX idx_nome ON produtos(nome);
Quando usar cada um
| Tipo | Use quando |
|---|---|
| CHAR | Códigos fixos (CPF, CNPJ, UF, status) |
| VARCHAR | Nomes, descrições, textos variáveis |
Dica de migração
Se você tem CHAR e quer converter para VARCHAR:
-- Firebird: alterar tipo (requer recriar coluna)
ALTER TABLE produtos ADD nome_new VARCHAR(100);
UPDATE produtos SET nome_new = TRIM(nome);
ALTER TABLE produtos DROP nome;
ALTER TABLE produtos ALTER COLUMN nome_new TO nome;
Precisa gerar DDL para alterar tipos de colunas? Descreva a mudança em português no Sqlify.
Conclusão
Use CHAR para códigos de tamanho fixo e VARCHAR para textos variáveis. A diferença de padding afeta comparações e pode causar bugs sutis.