CodeGym /Cursos /SQL SELF /Erros comuns ao criar e alterar tabelas

Erros comuns ao criar e alterar tabelas

SQL SELF
Nível 18 , Lição 4
Disponível

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 (0123456789 vira 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
);
2
Tarefa
SQL SELF, nível 18, lição 4
Bloqueado
Criação de tabela com o tipo de dado correto
Criação de tabela com o tipo de dado correto
2
Tarefa
SQL SELF, nível 18, lição 4
Bloqueado
Adicionando restrições a uma tabela existente
Adicionando restrições a uma tabela existente
1
Pesquisa/teste
Mudando a estrutura das tabelas, nível 18, lição 4
Indisponível
Mudando a estrutura das tabelas
Mudando a estrutura das tabelas
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION