E aí, futuros mestres do PostgreSQL! O papo de hoje é sobre uma das skills mais valiosas na programação — evitar erros. Não dá pra fugir de todos, principalmente se você tá começando com SQL. Mas sacar rapidinho os erros mais comuns é totalmente possível. É tipo andar no escuro num quarto cheio de quina: você bate umas vezes, mas depois já sabe onde tá tudo. E eu vou te ajudar a não tropeçar nos "cantos afiados" quando for criar e alterar tabelas.
Erro 1: Escolha errada do tipo de dado
Trabalhar com tipos de dados é tipo escolher a chave certa pra uma fechadura. Se você pega a "chave" errada, ou seja, o tipo de dado errado, sua tabela pode funcionar mal ou ficar menos eficiente.
Exemplo de erro:
Você quer criar uma coluna pra guardar números de telefone e, por costume, escolhe o tipo INTEGER. Parece lógico, já que número é número, né? Mas o problema é que INTEGER não serve pra dados que:
- Começam com zero (
0123456789vira só123456789). - Têm símbolos tipo "+" ou espaços.
-- Errado:
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
phone_number INTEGER -- Opa opa
);
-- Certo:
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
phone_number VARCHAR(15) -- Serve pra qualquer formato de número
);
Como evitar?
Analisa direitinho o tipo de dado que você vai guardar antes de escolher o tipo. Se ficar na dúvida, dá uma olhada na documentação oficial do PostgreSQL sobre tipos de dados.
Erro 2: Ignorar constraints NOT NULL, CHECK, UNIQUE
Constraints ajudam a manter a integridade dos dados. Se você esquecer delas, sua tabela pode virar uma bagunça, tipo ter valores vazios onde não devia.
Exemplo de erro: Você cria uma tabela pra guardar estudantes e esquece que nome e idade são obrigatórios.
-- Errado:
CREATE TABLE students (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
age INTEGER
);
INSERT INTO students (name, age) VALUES (NULL, NULL); -- Eita, que isso?!
Jeito certo:
CREATE TABLE students (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL, -- Nome é obrigatório
age INTEGER CHECK (age > 0) -- Idade tem que ser positiva
);
Como evitar?
Sempre coloca constraints nos campos obrigatórios. É tipo um "mecanismo de proteção" que impede dados zoados de entrarem.
Erro 3: Problemas com unicidade
Às vezes você esquece de colocar a constraint UNIQUE numa coluna que deveria ter valores únicos. Isso acaba gerando dados duplicados.
Exemplo de erro: Você cria uma tabela pra guardar emails, mas esquece de colocar UNIQUE.
-- Errado:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(100)
);
INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO users (email) VALUES ('user@example.com'); -- Já tem esse email!
Jeito certo:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(100) UNIQUE -- Emails únicos
);
Como evitar?
Sempre coloca UNIQUE se o valor tem que ser único. Se quiser mais controle, pode usar CONSTRAINT com nome pra identificar a constraint:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(100),
CONSTRAINT unique_email UNIQUE (email)
);
Erro 4: Erro ao alterar tabelas (ALTER TABLE)
Usar ALTER TABLE pode ser traiçoeiro, principalmente se já tem dados na tabela. Por exemplo, você pode esquecer dos valores válidos numa coluna e acabar tendo erro com os dados que já existem.
Exemplo de erro: Você quer adicionar NOT NULL numa coluna que já existe, mas tem valores NULL nela.
-- Errado:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Erro!
Se já tiver linhas com NULL na tabela, o PostgreSQL não vai deixar você adicionar a constraint.
O que fazer?
Antes de adicionar constraints, garante que os dados estão certinhos. Por exemplo:
UPDATE students SET name = 'Desconhecido' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;
Erro 5: Deletar tabelas ou dados sem conferir
Deletar uma tabela com DROP TABLE ou dados com DELETE é uma ação que não tem volta. Então, sempre confere o que tá deletando antes.
Exemplo de erro:
DROP TABLE courses; -- Opa, era a tabela errada!
Como evitar?
Usa o comando \dt no psql pra ver quais tabelas existem e ter certeza que tá deletando a certa.
Ou usa DROP TABLE IF EXISTS pra evitar erro se tentar deletar uma tabela que nem existe:
DROP TABLE IF EXISTS courses;
Erro 6: Problemas com tabelas temporárias
Tabelas temporárias somem no fim da sessão. Se você tentar usar uma tabela temporária depois que a sessão acabou, vai dar erro.
Exemplo de erro:
CREATE TEMP TABLE temp_students (
id SERIAL PRIMARY KEY,
name VARCHAR(100)
);
-- Terminou a sessão, aí...
SELECT * FROM temp_students; -- Erro: a tabela não existe mais!
Como evitar?
Guarda dados temporários que precisam durar entre sessões em tabelas normais ou documenta direitinho que elas só existem na sessão atual.
Erro 7: Esquecer constraints nos testes
Muitas vezes, durante o desenvolvimento, você pode pular algumas constraints achando que "depois coloca". Mas, na real, esse "depois" pode nunca chegar.
Exemplo de erro:
CREATE TABLE test_table (
id SERIAL PRIMARY KEY,
name VARCHAR(50)
);
-- Inserindo dados:
INSERT INTO test_table (name) VALUES ('Nome Duplicado');
INSERT INTO test_table (name) VALUES ('Nome Duplicado'); -- Começa a dor de cabeça...
Como evitar?
Já cria as tabelas com constraints, mesmo na fase de teste:
CREATE TABLE test_table (
id SERIAL PRIMARY KEY,
name VARCHAR(50) UNIQUE -- Salva você de muita dor de cabeça
);
GO TO FULL VERSION