10.5.6 - Mantendo a Ordem na Casa - Constraints

Fala, guardião(ã) da ordem! Já manja tudo de criar tabelas, definir colunas, chaves e até manipular dados com SQL (CRUD + JOIN), né? Mas me diz: como a gente garante que os dados que entram no nosso banco Supabase sejam certinhos, sem erros e bagunça?

Imagina seu quarto: se não tiver umas regras (tipo, lugar certo pra cada coisa, não deixar roupa suja no chão), rapidinho vira zona, né? 😅

No banco, essas regras se chamam Constraints — tipo os “guardas de trânsito” do banco, que garantem que só dados válidos e organizados entrem nas tabelas.

Vamos conhecer as principais constraints que vão deixar nosso QG tinindo de organizado!

---

A Missão: Impor Regras e Garantir a Qualidade

Constraints são regras que definimos quando criamos a tabela (CREATE TABLE) ou podemos acrescentar depois (ALTER TABLE). Elas ficam nas colunas ou na tabela toda.

Por que usar Constraints?

• Integridade: Dados sempre corretos e confiáveis.

• Evitar Erros: Bloqueiam dados inválidos (ex: email repetido, campo vazio).

• Consistência: Mantêm as ligações entre tabelas funcionando.

• Regras de Negócio: Seu banco ajuda a aplicar as regras do seu projeto.

---

1. NOT NULL: Campo Obrigatório! 🚫🕳️

Simples, mas poderosa. NOT NULL significa que essa coluna nunca pode ficar vazia. Sempre que inserir (INSERT) ou atualizar (UPDATE), tem que ter valor nessa coluna.

Exemplo: Na tabela usuarios, faz sentido que nome e email sejam obrigatórios, né? Sem nome ou email, nem cadastra!

CREATE TABLE usuarios (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  nome TEXT NOT NULL,          -- nome obrigatório
  email TEXT UNIQUE NOT NULL,  -- email único e obrigatório
  data_nascimento DATE,
  cidade TEXT
);

Tentar inserir um usuário sem nome:

INSERT INTO usuarios (email, cidade) VALUES ('[e-mail]', 'Teste');

Vai dar erro! ❌

---

2. UNIQUE: Nada de Repetecos! ☝️👯‍♀️🚫

UNIQUE garante que os valores numa coluna (ou conjunto de colunas) sejam sempre diferentes. Nada de duplicar!

Exemplo: O email tem que ser único na tabela usuarios.

CREATE TABLE usuarios (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  nome TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,  -- garante unicidade
  -- outras colunas...
);

Se tentar inserir um email que já existe:

INSERT INTO usuarios (nome, email) VALUES ('Outro Joao', '[e-mail]');

Vai dar erro! ❌

Dica: UNIQUE permite valores NULL, mas é melhor combinar com NOT NULL se o campo for obrigatório e único.

---

3. DEFAULT: Valor Padrão, na Faixa! 🤷‍♂️➡️🎁

DEFAULT define um valor padrão para a coluna, usado quando não especificamos nada ao inserir.

Exemplo: Na tabela posts, que tal numero_likes começar com zero? Ou o status do usuário ser 'ativo' por padrão?

CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  texto_do_post TEXT NOT NULL,
  usuario_id uuid REFERENCES usuarios(id),
  data_publicacao TIMESTAMPTZ DEFAULT now(), -- data/hora atual
  numero_likes INT DEFAULT 0                  -- começa com zero
);

Inserir um post sem likes nem data:

INSERT INTO posts (texto_do_post, usuario_id) VALUES ('Meu post automático!', 'f47ac10b...');

O banco preenche numero_likes com 0 e data_publicacao com o horário atual automaticamente.

---

4. PRIMARY KEY (PK): O RG Único 🔑🆔

Já vimos, mas reforçando: PRIMARY KEY é especial. Junta NOT NULL + UNIQUE, garantindo que a coluna (ou conjunto) identifica única e obrigatoriamente cada linha.

CREATE TABLE usuarios (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  -- ...
);

Também pode ser composta por várias colunas:

CREATE TABLE tabela_exemplo (
  colunaA INT,
  colunaB INT,
  PRIMARY KEY (colunaA, colunaB)  -- PK composta
);

Cada tabela tem uma única chave primária.

---

5. FOREIGN KEY (FK): O Elo Secreto 🔗⛓️

Também já falamos: FK cria link entre tabelas, garantindo que o valor da FK exista na PK da tabela referenciada.

CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  texto_do_post TEXT NOT NULL,
  usuario_id uuid REFERENCES usuarios(id),  -- FK pra usuarios.id
  -- ...
);

Ou:

CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  texto_do_post TEXT NOT NULL,
  usuario_id uuid,
  FOREIGN KEY (usuario_id) REFERENCES usuarios(id)
);

---

Novidade: Ações da FK — ON DELETE e ON UPDATE

Lembra do problema de apagar um usuário que tem posts? Essas ações definem o que acontece:

• ON DELETE {ação}: o que fazer na tabela filha se apagar a linha na tabela pai.

• ON UPDATE {ação}: o que fazer na tabela filha se atualizar a PK da tabela pai (raro).

Ações possíveis:

• NO ACTION ou RESTRICT: Impede apagar ou atualizar na tabela pai se tiver filhos. (Mais seguro)

• CASCADE: Apaga/atualiza na tabela filha automaticamente. (Cuidado!)

• SET NULL: Define FK como NULL se pai for apagado. FK precisa aceitar NULL.

• SET DEFAULT: Define FK com valor padrão.

---

Exemplo perigoso, mas prático:

CREATE TABLE posts (
  usuario_id uuid,
  FOREIGN KEY (usuario_id) REFERENCES usuarios(id)
    ON DELETE CASCADE  -- Apaga posts se apagar usuário
);

---

Exemplo seguro:

CREATE TABLE posts (
  usuario_id uuid,  -- permite NULL
  FOREIGN KEY (usuario_id) REFERENCES usuarios(id)
    ON DELETE SET NULL  -- posts ficam sem autor
);

---

E no Supabase?

No editor de tabelas, ao criar ou editar FK, você escolhe as ações ON DELETE e ON UPDATE.

---

Ufa! Constraints são as guardiãs da ordem do banco de dados, mantendo tudo limpo, seguro e funcionando certinho.