CodeGym /Cursos /SQL SELF /Erros comuns ao trabalhar com dados

Erros comuns ao trabalhar com dados

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

Mexer com banco de dados é tipo a vida de dev: cheia de surpresas. Até o dev mais experiente pode dar uma escorregada, seja apagando dados sem querer, tentando inserir duplicata ou quebrando restrição de integridade. O importante não é só evitar esses vacilos, mas também saber como consertar se rolar. Bora ver alguns dos erros mais clássicos.

Erro nº1: Esquecer a condição WHERE

Esse é o erro mais clássico que a galera iniciante comete (e, fala sério, até dev velho de guerra já fez), que é esquecer de colocar o WHERE na query de update ou delete. Query sem WHERE atualiza ou apaga todas as linhas da tabela.

-- Exemplo do que NÃO fazer:
UPDATE students SET status = 'formado';

-- Ou assim:
DELETE FROM students;

Consequências: imagina rodar essa query e depois perceber que tua tabela students, com todos os dados dos estudantes, ficou vazia. E o pior: não tem como recuperar se tu não fez backup ou usou transação (e mesmo assim, já bate o desespero).

Como evitar: sempre coloca condição nas queries UPDATE e DELETE pra garantir que só as linhas certas vão ser alteradas ou apagadas.

-- O jeito certo:
UPDATE students
SET status = 'formado'
WHERE year_of_study = 4;

DELETE FROM students
WHERE status = 'expulso';

Outra dica: antes de deletar, sempre roda um SELECT pra conferir se a condição tá certinha:

-- Primeiro confere:
SELECT * FROM students WHERE status = 'expulso';

-- Depois deleta:
DELETE FROM students WHERE status = 'expulso';

Erro nº2: Quebrar unicidade dos dados (UNIQUE)

Se a tabela tem restrição UNIQUE, tentar inserir duplicata vai dar erro.

-- Erro por duplicar email:
INSERT INTO students (name, email) VALUES ('Otto Lin', 'otto.lin@email.com');
INSERT INTO students (name, email) VALUES ('Peter Pen', 'otto.lin@email.com');

Erro:

ERROR: duplicate key value violates unique constraint "students_email_key"

Como evitar: antes de inserir, confere se já não existe uma linha com esses valores.

-- Um jeito de fazer:
SELECT * FROM students WHERE email = 'otto.lin@email.com';

-- Ou usa UPSERT:
INSERT INTO students (name, email)
VALUES ('Peter Pen', 'otto.lin@email.com')
ON CONFLICT (email) DO NOTHING;

Erro nº3: Quebrar restrições de integridade (FOREIGN KEY)

Imagina que tu tem duas tabelas: students e enrollments, onde student_id em enrollments é foreign key pro id da students. Se tu tentar inserir em enrollments um student_id que não existe em students, vai dar erro.

INSERT INTO enrollments (student_id, course_id)
VALUES (999, 101); -- Erro, porque student_id 999 não existe

Como evitar?

  1. Sempre confere se o registro existe na tabela mãe antes de inserir na tabela relacionada:
SELECT * FROM students WHERE id = 999;
  1. Usa ON DELETE CASCADE pra que registros relacionados sejam apagados automaticamente quando o registro da tabela mãe for deletado (mas usa com cuidado).
CREATE TABLE enrollments (
    id SERIAL PRIMARY KEY,
    student_id INT REFERENCES students(id) ON DELETE CASCADE,
    course_id INT
);

Erro nº4: Tipos de dados errados

Quando tu insere ou atualiza dados, o PostgreSQL checa direitinho se o tipo bate. Se tentar colocar string em campo numérico, vai dar erro.

-- Erro por tipo incompatível:
INSERT INTO students (id, name) VALUES ('abc', 'Alex Go');

Erro:

ERROR: invalid input syntax for type integer

Como evitar? Fica ligado nos tipos dos valores que tu tá inserindo. Se os dados vêm de formulário do usuário, valida tudo na aplicação antes de mandar pro banco.

Erro nº5: Problemas com acesso concorrente (vazamento de dados)

Imagina dois usuários tentando atualizar o mesmo registro ao mesmo tempo. Sem isolamento de transação, pode rolar conflito fácil.

-- Usuário A:
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- Usuário B:
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;

Como evitar? Usa transações e níveis de isolamento pra evitar alteração simultânea dos dados.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

Erro nº6: Perda de dados por causa do TRUNCATE

TRUNCATE apaga todas as linhas da tabela sem chance de recuperar, porque esse comando não suporta ROLLBACK (não dispara triggers e é instantâneo).

-- Apaga tudo sem volta:
TRUNCATE TABLE students;

Como evitar: usa DELETE com condição no lugar do TRUNCATE se quiser poder desfazer.

BEGIN;
DELETE FROM students WHERE year_of_study = 1;
-- Se mudar de ideia:
ROLLBACK;

Erro nº7: Não usar transação em operações importantes

Se tu faz uma operação complexa com vários passos e rola erro no meio, os dados podem ficar bagunçados.

-- Passo 1: adiciona estudante
INSERT INTO students (name, email) VALUES ('Otto Lin', 'otto.lin@email.com');

-- Passo 2: matricula ele no curso
INSERT INTO enrollments (student_id, course_id) VALUES (LASTVAL(), 101); -- erro

Como evitar? Coloca tudo dentro de uma transação:

BEGIN;

INSERT INTO students (name, email) VALUES ('Ivan Ivanov', 'ivan.ivanov@email.com');
INSERT INTO enrollments (student_id, course_id) VALUES (LASTVAL(), 101);

COMMIT;

Se der erro em qualquer etapa, tu pode desfazer tudo:

ROLLBACK;

Erro nº8: Mexer com NULL sem querer

NULL sempre pega a galera de surpresa, porque não é igual a zero nem string vazia, e as comparações com ele podem dar resultado estranho.

-- Isso não funciona:
SELECT * FROM students WHERE email = NULL;

Como evitar? Usa IS NULL ou IS NOT NULL:

SELECT * FROM students WHERE email IS NULL;

Errar é normal, mas sabendo reconhecer e evitar esses vacilos, tu consegue trabalhar com dados de boa e sem susto. O PostgreSQL é rígido, mas justo: ele sempre vai te avisar se algo der ruim. Só lembra: erro não é inimigo, é professor.

1
Pesquisa/teste
Introdução às transações, nível 22, lição 4
Indisponível
Introdução às transações
Introdução às transações
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION