Errores típicos al trabajar con datos

Trabajar con una base de datos es como la vida de un programador: llena de sorpresas. Incluso el desarrollador más experimentado puede meter la pata, ya sea borrando datos por accidente, intentando meter un duplicado o rompiendo restricciones de integridad. Pero lo importante no es solo evitar estos errores, sino también saber cómo arreglarlos si pasan. Vamos a ver algunos de los errores más típicos.

Error nº1: Falta la condición WHERE

El error más clásico que cometen los novatos (y, seamos sinceros, a veces hasta los cracks), es olvidarse de poner el WHERE en una consulta de actualización o borrado. Las consultas sin WHERE actualizan o borran todas las filas de la tabla.

-- Ejemplo de lo que NO hay que hacer:
UPDATE students SET status = 'graduated';

-- O así:
DELETE FROM students;

Consecuencias: imagina que después de ejecutar esa consulta te das cuenta de que tu tabla students, con todos los datos de los estudiantes, está vacía. Y lo peor: no puedes recuperar los datos si no tienes una copia de seguridad o usaste transacciones (y aun así, menudo susto).

¿Cómo evitarlo?: siempre pon condiciones en las consultas UPDATE y DELETE para dejar claro qué filas quieres cambiar o borrar.

-- Así sí:
UPDATE students
SET status = 'graduated'
WHERE year_of_study = 4;

DELETE FROM students
WHERE status = 'expelled';

Otro truco: antes de borrar, ejecuta siempre un SELECT para asegurarte de que la condición está bien puesta:

-- Primero comprobamos:
SELECT * FROM students WHERE status = 'expelled';

-- Luego borramos:
DELETE FROM students WHERE status = 'expelled';

Error nº2: Violación de unicidad de datos (UNIQUE)

Si la tabla tiene una restricción UNIQUE, intentar meter un duplicado te va a dar error.

-- Error 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');

Error:

ERROR: duplicate key value violates unique constraint "students_email_key"

¿Cómo evitarlo?: antes de insertar, comprueba si ya existe una fila con esos valores.

-- Una forma de hacerlo:
SELECT * FROM students WHERE email = 'otto.lin@email.com';

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

Error nº3: Violación de restricciones de integridad (FOREIGN KEY)

Supón que tienes dos tablas: students y enrollments, donde student_id en enrollments es una clave foránea que apunta al id de students. Si intentas meter un registro en enrollments con un student_id que no existe en students, te va a saltar un error.

INSERT INTO enrollments (student_id, course_id)
VALUES (999, 101); -- Error, porque student_id 999 no existe

¿Cómo evitarlo?

1. Comprueba siempre que existe el registro en la tabla padre antes de insertar en la tabla relacionada:

SELECT * FROM students WHERE id = 999;

2. Usa la restricción ON DELETE CASCADE para que los registros relacionados se borren automáticamente al borrar el registro padre (pero ojo, úsalo con cabeza).

CREATE TABLE enrollments (
    id SERIAL PRIMARY KEY,
    student_id INT REFERENCES students(id) ON DELETE CASCADE,
    course_id INT
);

Error nº4: Tipos de datos incorrectos

Al insertar o actualizar datos, PostgreSQL es muy estricto con los tipos de datos. Si intentas meter una cadena en un campo numérico, te va a dar error.

-- Error por incompatibilidad de tipos:
INSERT INTO students (id, name) VALUES ('abc', 'Alex Go');

Error:

ERROR: invalid input syntax for type integer

¿Cómo evitarlo?: fíjate bien en los tipos de datos de los valores que insertas. Si los datos vienen de un formulario de usuario, valídalos siempre en la app.

Error nº5: Problemas de acceso concurrente (fuga de datos)

Imagina que dos usuarios intentan actualizar la misma fila a la vez. Sin una buena gestión de transacciones, es fácil que haya conflictos.

-- Usuario A:
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- Usuario B:
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;

¿Cómo evitarlo?: usa transacciones y niveles de aislamiento para evitar cambios simultáneos en los datos.

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

Error nº6: Pérdida de datos por culpa de TRUNCATE

TRUNCATE borra todas las filas de la tabla sin posibilidad de recuperarlas, porque este comando no soporta ROLLBACK (no lanza triggers y es instantáneo).

-- Borra todo para siempre:
TRUNCATE TABLE students;

¿Cómo evitarlo?: usa DELETE con condición en vez de TRUNCATE si quieres poder deshacer los cambios.

BEGIN;
DELETE FROM students WHERE year_of_study = 1;
-- Si te arrepientes:
ROLLBACK;

Error nº7: No usar transacciones en operaciones importantes

Si haces una operación compleja de varios pasos y algo falla en medio, los datos pueden quedar en un estado inconsistente.

-- Paso 1: añadimos un estudiante
INSERT INTO students (name, email) VALUES ('Otto Lin', 'otto.lin@email.com');

-- Paso 2: lo matriculamos en un curso
INSERT INTO enrollments (student_id, course_id) VALUES (LASTVAL(), 101); -- error

¿Cómo evitarlo?: mete estas operaciones en una transacción:

BEGIN;

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

COMMIT;

Si en algún paso hay un error, puedes deshacer los cambios:

ROLLBACK;

Error nº8: Trabajar por accidente con NULL

NULL suele dar sorpresas, porque no es ni cero ni cadena vacía, y las comparaciones con él pueden dar resultados raros.

-- Esto no funciona:
SELECT * FROM students WHERE email = NULL;

¿Cómo evitarlo?: usa IS NULL o IS NOT NULL:

SELECT * FROM students WHERE email IS NULL;

Los errores típicos son inevitables, pero si sabes cómo reconocerlos y evitarlos, podrás trabajar con datos de forma segura y eficiente. PostgreSQL es un guardián estricto pero justo de tus datos, y siempre te va a avisar si algo va mal. Recuerda: los errores no son enemigos, son maestros.