Trabalhando com a restrição CHECK para validar dados

A restrição CHECK é tipo um segurança na porta da sua tabela. Ela garante que os dados que você coloca na tabela seguem certas condições. Se você tentar colocar dados que quebram essas regras, o banco de dados vai recusar na hora.

Imagina que você quer abrir uma loja na Alemanha. Mas pela lei, domingo é folga, e não pode vender nesse dia. Essa restrição é tipo um CHECK no banco de dados. Você tenta colocar o horário da loja: aberta 7 dias por semana, mas o sistema já responde: "Nein, nein, domingo é proibido. Esse horário não passa na checagem!"

No banco de dados é igual: se você coloca um valor que quebra a regra do CHECK, o sistema bloqueia pra não deixar passar "erro lógico" nos dados.

Pra que serve o CHECK?

1. Manter a qualidade dos dados: CHECK impede que informações erradas ou sem lógica entrem na tabela.
2. Menos chance de erro: ao invés de checar tudo na mão antes de inserir, você pode deixar isso pro banco de dados cuidar.
3. Lógica independente: as regras de validação ficam direto na estrutura do banco, não precisa jogar essa responsa pro código da aplicação.

Como funciona o CHECK?

A restrição CHECK é definida quando você cria a tabela ou pode ser adicionada depois com o comando ALTER TABLE. Olha o básico da sintaxe:

CREATE TABLE tabela (
    coluna tipo_de_dado CHECK (condicao)
);

condicao é uma expressão lógica que tem que ser verdadeira pra cada valor naquela coluna. Se não for, o banco de dados dá erro.

Exemplo 1: Checando um intervalo de valores

Bora criar uma tabela students, onde a idade dos estudantes (age) tem que ser entre 16 e 100:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INTEGER CHECK (age >= 16 AND age <= 100)
);

Agora, se você tentar inserir um estudante com 12 anos, o banco de dados vai te "pegar no flagra":

INSERT INTO students (name, age)
VALUES ('Maria Chi', 12);

Erro:

ERROR:  new row for relation "students" violates check constraint "students_age_check"
DETAIL:  Failing row contains (1, Maria Chi, 12).

Pois é, o banco aqui é tipo porteiro bravo. Não tem 16? Nem entra.

Exemplo 2: Checando formato dos dados

Vamos supor que temos uma tabela emails pra guardar endereços de e-mail. Queremos garantir que os endereços tenham o símbolo @ (é uma checagem simplona):

CREATE TABLE emails (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) CHECK (email LIKE '%@%')
);

Vamos tentar adicionar um endereço errado, que não bate com a condição:

INSERT INTO emails (email)
VALUES ('notanemail.com');

Erro:

ERROR:  new row for relation "emails" violates check constraint "emails_email_check"
DETAIL:  Failing row contains (1, notanemail.com).

Dá pra evitar esse erro se todos os dados tiverem o @:

INSERT INTO emails (email) 
VALUES ('example@student.com');

Esse comando vai rodar de boa.

Exemplo 3: Checando condições em várias colunas

As restrições CHECK podem validar não só uma coluna, mas também expressões lógicas que envolvem várias colunas. Olha esse exemplo com a tabela employees, onde o salário (salary) tem que ser maior que o bônus (bonus):

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    salary NUMERIC CHECK (salary > 0),
    bonus NUMERIC CHECK (bonus >= 0),
    CHECK (salary > bonus)
);

Agora, se alguém tentar adicionar um funcionário com bônus maior que o salário, o banco não deixa:

INSERT INTO employees (name, salary, bonus)
VALUES ('Otto Lin', 3000, 4000);

Erro:

ERROR:  new row for relation "employees" violates check constraint "employees_salary_bonus_check"
DETAIL:  Failing row contains (1, Otto Lin, 3000, 4000).

Aplicações práticas

A restrição CHECK é útil quando sua lógica de negócio depende de regras nos dados. Por exemplo:

1. Lojas online: não deixar cadastrar produto com preço negativo.
2. Plataformas de ensino: checar a idade dos alunos nos cursos.
3. Sistemas médicos: garantir que a temperatura do paciente está num intervalo aceitável.

Essas checagens não são só mais uma camada de segurança, elas economizam tempo e paciência de devs e usuários.

Peculiaridades e erros comuns

Quando for usar CHECK, fica ligado nessas paradas:

• As expressões lógicas no CHECK têm que ser verdadeiras pra todas as linhas da tabela. Se alguma linha quebra a regra, antes de adicionar a restrição você tem que corrigir ela.

• A checagem não rola se o valor inserido for NULL. Ou seja, CHECK (age >= 18) não vai dar erro pra age = NULL. Isso porque qualquer expressão com NULL vira indefinida. Se quiser proibir NULL, coloca NOT NULL junto.

• Condições muito complicadas no CHECK podem deixar as inserções e updates mais lentos, principalmente em tabelas grandes.