Errores típicos al crear y modificar tablas

¡Hola, futuros cracks de PostgreSQL! El tema de hoy va de una de las habilidades más valiosas en programación — evitar errores. Obvio que no vas a poder esquivar todos, sobre todo si recién empiezas con SQL. Pero pillar rápido los errores típicos — eso sí es posible. Es como caminar por una habitación oscura llena de esquinas: te das un par de golpes, pero luego ya sabes dónde está todo. Yo te voy a ayudar a esquivar esos "bordes afilados" al crear y modificar tablas.

Error 1: Elección incorrecta del tipo de dato

Trabajar con tipos de datos es como buscar la llave correcta para una cerradura. Si eliges el "tipo" equivocado, la tabla puede funcionar mal o ser menos eficiente.

Ejemplo de error:

Quieres crear una columna para guardar números de teléfono y por costumbre eliges el tipo INTEGER. Suena lógico, porque los números son números, ¿no? Pero el problema es que INTEGER no sirve para datos que:

• Empiezan por cero (0123456789 se convierte en 123456789).
• Tienen símbolos como "+" o espacios.

-- Incorrecto:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Uy uy
);

-- Correcto:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Sirve para todos los formatos de número
);

¿Cómo evitarlo?
Analiza bien la naturaleza de los datos que vas a guardar antes de elegir el tipo de dato. Si tienes dudas, échale un ojo a la documentación oficial de PostgreSQL sobre tipos de datos.

Error 2: Ignorar restricciones NOT NULL, CHECK, UNIQUE

Las restricciones ayudan a mantener la integridad de los datos. Si te olvidas de ellas, tu tabla puede acabar hecha un caos, con valores vacíos donde no deberían estar.

Ejemplo de error: Creas una tabla para guardar estudiantes y se te olvida que el nombre y la edad son obligatorios.

-- Incorrecto:
CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER
);

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Uy, ¿qué es esto?!

Opción correcta:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Nombre obligatorio
    age INTEGER CHECK (age > 0) -- Edad debe ser positiva
);

¿Cómo evitarlo?
Pon siempre restricciones para los campos obligatorios. Es como un "mecanismo de defensa" que evita que entren datos problemáticos.

Error 3: Problemas con la unicidad

A veces se te puede olvidar poner la restricción UNIQUE en una columna que debería tener valores únicos. Eso lleva a datos duplicados.

Ejemplo de error: Creas una tabla para guardar emails, pero se te olvida añadir UNIQUE.

-- Incorrecto:
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'); -- ¡Ese email ya existe!

Opción correcta:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Emails únicos
);

¿Cómo evitarlo?
Pon siempre UNIQUE si los valores deben ser únicos. Si quieres más flexibilidad, puedes usar CONSTRAINT con un nombre para identificar la restricción:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100),
    CONSTRAINT unique_email UNIQUE (email)
);

Error 4: Error al modificar tablas (ALTER TABLE)

Usar ALTER TABLE puede ser traicionero, sobre todo si ya tienes datos en la tabla. Por ejemplo, puedes olvidar los valores permitidos en una columna, lo que lleva a errores con los datos existentes.

Ejemplo de error: Quieres añadir la restricción NOT NULL a una columna que ya existe, pero hay valores NULL en esa columna.

-- Incorrecto:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- ¡Error!

Si ya hay filas con NULL en la tabla, PostgreSQL no te dejará añadir la restricción.

¿Qué hacer?

Antes de añadir restricciones, asegúrate de que los datos cumplen los requisitos. Por ejemplo:

UPDATE students SET name = 'Desconocido' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;

Error 5: Borrar tablas o datos sin comprobar

Borrar una tabla con DROP TABLE o datos con DELETE — es algo que no se puede deshacer. Así que antes de borrar, revisa bien qué vas a eliminar.

Ejemplo de error:

DROP TABLE courses; -- Uy, ¡esa no era la tabla!

¿Cómo evitarlo?

Usa el comando \dt en psql para ver qué tablas existen y asegúrate de borrar la correcta.

O usa DROP TABLE IF EXISTS para evitar errores si intentas borrar una tabla que no existe:

DROP TABLE IF EXISTS courses;

Error 6: Problemas con tablas temporales

Las tablas temporales desaparecen al final de la sesión. Si por error intentas usar una tabla temporal y la sesión ya terminó, te va a dar error.

Ejemplo de error:

CREATE TEMP TABLE temp_students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

-- Terminas la sesión y luego...
SELECT * FROM temp_students; -- Error: ¡la tabla ya no existe!

¿Cómo evitarlo?

Guarda los datos temporales que necesites entre sesiones en tablas normales o documenta su uso solo dentro de una sesión.

Error 7: Olvidar restricciones al testear

Muchas veces, cuando desarrollas, puedes saltarte algunas restricciones pensando "bueno, ya las pondré luego". Pero en la práctica, ese "luego" se olvida fácil.

Ejemplo de error:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- Insertamos datos:
INSERT INTO test_table (name) VALUES ('Nombre duplicado');
INSERT INTO test_table (name) VALUES ('Nombre duplicado'); -- Empiezan los problemas...

¿Cómo evitarlo?

Crea las tablas con restricciones desde el principio, incluso en la fase de pruebas:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Te ahorra dolores de cabeza
);