Diseñar tablas

1.CREATE TABLE: crear una tabla

Hasta ahora usábamos una tabla ya creada. CREATE TABLE define una nueva: su nombre y, para cada columna, su nombre, su tipo y sus restricciones.

CREATE TABLE nombre_tabla (
  columna1  TIPO  restricciones,
  columna2  TIPO  restricciones,
  ...
);

Un ejemplo completo: la tabla de clientes de la tienda.

CREATE TABLE clientes (
  id     INTEGER PRIMARY KEY,
  nombre TEXT    NOT NULL,
  email  TEXT    NOT NULL UNIQUE,
  edad   INTEGER CHECK (edad >= 18),
  pais   TEXT    DEFAULT 'Perú'
);

Lee cada línea como una frase:

• id INTEGER PRIMARY KEY: número entero que identifica cada cliente.
• nombre TEXT NOT NULL: texto obligatorio.
• email TEXT NOT NULL UNIQUE: obligatorio y no repetible entre clientes.
• edad INTEGER CHECK (edad >= 18): si se indica, debe ser 18 o más.
• pais TEXT DEFAULT 'Perú': si no se indica, vale 'Perú'.

Prueba a insertar un cliente indicando solo lo necesario:

INSERT INTO clientes (nombre, email, edad)
VALUES ('Ana Torres', 'ana@correo.com', 25);

SELECT * FROM clientes;

Resultado esperado (el país se rellenó solo)

2.Las restricciones de columna

Si una instrucción rompe una restricción, la base de datos la rechaza. Estos son los mensajes reales de SQLite para nuestra tabla clientes:

INSERT INTO clientes (nombre, email)
VALUES ('Otra Ana', 'ana@correo.com');

UNIQUE constraint failed: clientes.email

INSERT INTO clientes (nombre, email, edad)
VALUES ('Luis', 'luis@correo.com', 15);

CHECK constraint failed: edad >= 18

INSERT INTO clientes (email)
VALUES ('sin-nombre@correo.com');

NOT NULL constraint failed: clientes.nombre

Identificadores automáticos

Como vimos, las claves id suelen numerarse solas. La sintaxis depende del motor:

3.Elegir la clave primaria

Una buena clave primaria cumple tres cosas: es única, nunca está vacía y no cambia. Por eso suele usarse una clave sustituta (surrogate key): un número id sin significado propio, generado por la base de datos.

Esto no impide que el correo siga siendo único: se consigue con UNIQUE, como en la tabla clientes. Clave primaria (identifica) y valor único (evita repetidos) son dos ideas distintas.

4.Modificar y eliminar tablas

El diseño cambia con el tiempo. Estas instrucciones funcionan en SQLite y en PostgreSQL:

-- Añadir una columna
ALTER TABLE clientes ADD COLUMN telefono TEXT;

-- Renombrar una tabla
ALTER TABLE clientes RENAME TO usuarios;

-- Eliminar la tabla y TODOS sus datos
DROP TABLE usuarios;

-- Variantes seguras: no fallan si ya existe / si no existe
CREATE TABLE IF NOT EXISTS clientes (id INTEGER PRIMARY KEY);
DROP TABLE IF EXISTS clientes;

5.Normalización básica: un dato, un lugar

Diseñar bien una tabla es decidir qué datos van en cada tabla. La normalización es un conjunto de reglas para evitar la repetición y los errores que causa. Veamos un diseño ingenuo: todo en una sola tabla de pedidos.

Problemas de esta tabla:

• Varios valores en una celda (Teclado, Ratón): no se puede buscar, contar ni sumar bien. Rompe la primera forma normal (1FN): cada celda debe tener un solo valor.
• Datos repetidos: el nombre y el correo de Ana están en dos filas. Si cambia de correo, hay que corregirlo en todas, y si se olvida una, los datos se contradicen.
• Datos que dependen de otra cosa: el nombre y el correo dependen del cliente, no del pedido. Es lo que corrigen la 2FN y 3FN: cada dato debe depender de la clave de su tabla y de nada más.

La solución es repartir los datos en tablas, cada una sobre una sola cosa, enlazadas con claves:

6.Buenos nombres y hábitos

• Tablas en plural y en minúsculas: clientes, productos.
• Columnas en minúsculas con guion bajo: fecha_nacimiento, cliente_id. Sin espacios ni tildes ni la letra «ñ», para evitar tener que usar comillas.
• Evita palabras reservadas como order, user o group como nombre de tabla (por eso se usa pedidos y usuarios).
• Clave foránea: otra_tabla_en_singular_id, como cliente_id.
• Guarda el script de creación en un archivo .sql (como tienda.sql) y versiónalo con Git: es la documentación viva de tu diseño.

7.Pruébalo: laboratorio de restricciones

Activa o desactiva restricciones en la tabla usuarios y mira cómo cambia la instrucción CREATE TABLE. Luego intenta insertar filas y observa cuándo la base de datos las rechaza. Hay ya un usuario guardado: Ana con id 1 y el correo ana@mail.com. (Es una simulación: usa los mismos mensajes de error que SQLite.)

8.Errores frecuentes

• Olvidar NOT NULL en columnas obligatorias: acaban entrando filas sin nombre o sin correo.
• Usar el email o el nombre como clave primaria en lugar de un id.
• Guardar listas separadas por comas en una celda ('Teclado, Ratón'): crea otra tabla.
• Repetir los datos del cliente en cada pedido: si cambian, quedan versiones contradictorias.
• Coma sobrante después de la última columna en CREATE TABLE, o falta de coma entre dos columnas: error de sintaxis.
• Ejecutar CREATE TABLE dos veces: la segunda falla porque la tabla ya existe; usa IF NOT EXISTS o DROP TABLE IF EXISTS antes.
• Usar DROP TABLE sin copia: elimina la tabla y todo su contenido.
• Copiar sintaxis de un motor a otro (AUTOINCREMENT, SERIAL…): comprueba la documentación del motor que usas.

9.Glosario