Checando a validade dos dados carregados

Trazer dados de fora é tipo chamar a galera pra um rolê: você quer garantir que todo mundo chegou no clima certo — ou, no nosso caso, no formato certo. Até um errinho besta no arquivo pode virar horas de debug, resultados zoados nas queries ou até ferrar a tabela toda.

Às vezes o arquivo vem com linhas vazias, espaços a mais, duplicatas ou, sei lá, texto onde devia ter número. E se a codificação não bater, a tabela pode nem aceitar o arquivo.

Pra evitar isso, é importante aprender a checar os dados antes de carregar ou logo depois. Bora ver como faz isso na prática.

Checando a estrutura dos dados

1. Comparando a estrutura da tabela com os dados carregados

Primeiro de tudo, tem que garantir que os dados entraram certinho conforme a estrutura da sua tabela. Por exemplo, você criou a tabela students pra guardar info dos estudantes:

CREATE TABLE students (
    student_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50) NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    birth_date DATE,
    email VARCHAR(100) UNIQUE
);

Se você já carregou os dados nessa tabela, bora dar uma olhada no que tem lá:

SELECT * FROM students;

As linhas que voltarem vão mostrar tudo que tá na tabela. Se a estrutura do CSV não bater com a da tabela, você já vai ver erro na hora de carregar. Mas mesmo sem erro, não quer dizer que tá tudo perfeito.

2. Checando os tipos de dados

Usa as funções do PostgreSQL pra conferir o que tem nas colunas. Tipo assim:

Checando valores vazios (NULL):

Se sua tabela tem campos obrigatórios NOT NULL, tem que garantir que eles tão preenchidos mesmo. Por exemplo:

SELECT * FROM students WHERE first_name IS NULL OR last_name IS NULL;

Checando formatos dos dados:

Às vezes os dados vêm como string, mas deviam ser data ou número. Pra conferir isso, usa as funções certas do PostgreSQL, tipo:

SELECT * FROM students WHERE birth_date::DATE IS NULL;

Essa query mostra as linhas onde o campo birth_date não dá pra converter pra DATE.

Checando se tem erro

1. Procurando duplicatas

Registro duplicado é um clássico dos problemas. Imagina que seus dados têm que ser únicos pelo email (email). Pra achar duplicata, manda essa query:

SELECT email, COUNT(*)
FROM students
GROUP BY email
HAVING COUNT(*) > 1;

Essa query mostra todos os email repetidos e quantas vezes aparecem. Se o campo email tá como UNIQUE, tentar carregar duplicata vai dar erro.

2. Checando dados errados

Se você espera que o campo birth_date só tenha datas de nascimento, tem que garantir que os valores tão num intervalo aceitável. Tipo assim:

SELECT * FROM students
WHERE birth_date < '1900-01-01' OR birth_date > CURRENT_DATE;

Essa query mostra as linhas onde a data de nascimento tá muito fora da realidade.

Trabalhando com dados errados

Depois que você achou os problemas, tem que resolver. Bora ver como faz isso.

1. Deletando dados errados

Se achou linhas com nome vazio, pode apagar elas:

DELETE FROM students
WHERE first_name IS NULL OR last_name IS NULL;

Mas cuidado ao deletar! Pode ser que esses dados sejam importantes, então talvez seja melhor atualizar do que apagar.

2. Atualizando dados

Se achou linhas faltando info, pode atualizar com base em outras fontes ou chutar um valor. Exemplo:

UPDATE students
SET email = 'unknown@example.com'
WHERE email IS NULL;

Visualizando dados pra análise

1. Usando funções agregadas

Às vezes é útil contar agregados pra checar os dados. Tipo, pra saber quantos estudantes nasceram em cada ano, faz assim:

SELECT EXTRACT(YEAR FROM birth_date) AS year, COUNT(*)
FROM students
GROUP BY year
ORDER BY year;

Essa query mostra a distribuição por ano e pode mostrar anomalias (tipo, se num ano apareceu um monte de estudante do nada).

2. Checando dados com constraints

Confere se os dados tão batendo com os constraints da tabela, tipo assim:

Checando unicidade:

SELECT DISTINCT email
FROM students;

Se o número de valores únicos for menor que o total de linhas — tem duplicata aí.

Checando limites de valores:

SELECT * FROM students
WHERE LENGTH(first_name) > 50 OR LENGTH(last_name) > 50;

Isso ajuda a garantir que os nomes dos estudantes não passaram do limite de 50 caracteres.

O que fazer se deu ruim?

Às vezes os dados tão tão zoados que é melhor carregar tudo de novo.

1. Apaga todas as linhas da tabela:

   TRUNCATE TABLE students;
   

2. Arruma o CSV original usando Python, Excel ou qualquer outra ferramenta.

3. Carrega os dados de novo usando o comando COPY.

Aplicação prática

Saber validar dados vai te ajudar sempre que mexer com fonte externa. Em entrevista, por exemplo, podem pedir pra você montar uma query SQL pra checar qualidade dos dados — é super comum. Na vida real não é diferente: dados do cliente ou de outro setor quase sempre vêm com erro, e é você que vai sacar isso primeiro e arrumar antes de virar bug.

Checar os dados com frequência mantém o banco em ordem — e não é só formalidade, é economia real de tempo, paciência e esforço da equipe toda. Então, se você já saca rapidinho se os dados tão ok, pode se considerar um passo mais perto de virar mestre do PostgreSQL.