SQLite DROP TABLE y ALTER TABLE: cambios de esquema

Los esquemas cambian. SQLite te deja cambiarlos — casi siempre.

Tarde o temprano vas a querer renombrar una tabla, añadir una columna, eliminar otra o reestructurarla por completo. SQLite cubre los casos más comunes directamente con DROP TABLE y ALTER TABLE, y para todo lo demás ofrece un patrón documentado que sirve como solución alternativa.

El detalle: el ALTER TABLE de SQLite es bastante más limitado que el de Postgres o MySQL. Saber qué puede y qué no puede hacer — y conocer el patrón de reconstrucción para lo que no puede — es prácticamente todo el truco.

DROP TABLE: eliminar una tabla y todo lo que cuelga de ella

DROP TABLE elimina la tabla, sus filas, sus índices y cualquier trigger definido sobre ella. No hay vuelta atrás:

CREATE TABLE scratch (
    id INTEGER PRIMARY KEY,
    note TEXT
);

INSERT INTO scratch (note) VALUES ('temporal'), ('también temporal');

DROP TABLE scratch;

SELECT name FROM sqlite_master WHERE type = 'table';

La tabla ya no existe. Si intentas consultarla ahora, obtendrás el error no such table: scratch.

Cuando no tengas la certeza de que la tabla exista —algo habitual en scripts de inicialización—, añade IF EXISTS para que la sentencia no haga nada si no la encuentra:

CREATE TABLE scratch (id INTEGER PRIMARY KEY);

DROP TABLE IF EXISTS scratch;
DROP TABLE IF EXISTS scratch;
SELECT 'ambos DROP se ejecutaron con éxito' AS result;

Sin IF EXISTS, el segundo DROP lanzaría un error. Con esa cláusula, ambos se ejecutan sin problema.

Las claves foráneas pueden bloquear un DROP

Si tienes activada la verificación de claves foráneas (PRAGMA foreign_keys = ON;) y otra tabla hace referencia a la que vas a eliminar, el DROP falla:

sqlite> PRAGMA foreign_keys = ON;
sqlite> DROP TABLE users;
Runtime error: FOREIGN KEY constraint failed

Tienes varias salidas: eliminar primero la tabla que referencia, borrar las filas que apuntan a ella, o definir la clave foránea con ON DELETE CASCADE desde el momento en que la creas. SQLite no va a romper en silencio la integridad referencial por ti.

ALTER TABLE en SQLite: las cuatro operaciones disponibles

El ALTER TABLE de SQLite admite exactamente cuatro operaciones:

CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    body TEXT
);

-- 1. Renombrar la tabla
ALTER TABLE posts RENAME TO articles;

-- 2. Renombrar una columna
ALTER TABLE articles RENAME COLUMN body TO content;

-- 3. Agregar una columna
ALTER TABLE articles ADD COLUMN published_at TEXT;

-- 4. Eliminar una columna (SQLite 3.35+)
ALTER TABLE articles DROP COLUMN published_at;

SELECT sql FROM sqlite_master WHERE name = 'articles';

Cada una de estas instrucciones se ejecuta como una sola sentencia. Las dos primeras prácticamente no cuestan nada: solo actualizan el esquema. ADD COLUMN también es rápido, ya que SQLite no reescribe la tabla, sino que se limita a registrar la definición de la nueva columna. DROP COLUMN, en cambio, es más pesado: SQLite tiene que reescribir todas las filas para eliminar físicamente los datos de esa columna.

ALTER TABLE ADD COLUMN con valor por defecto

Al añadir una columna nueva a una tabla existente, todas las filas arrancan con NULL, a menos que indiques un valor por defecto:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL
);

INSERT INTO users (email) VALUES ('ada@example.com'), ('boris@example.com');

ALTER TABLE users ADD COLUMN status TEXT NOT NULL DEFAULT 'active';

SELECT * FROM users;

Las dos filas existentes quedan con 'active'. Eso sí: el valor por defecto tiene que ser una constante. SQLite no te deja usar CURRENT_TIMESTAMP ni ninguna otra expresión no constante como default en ADD COLUMN, porque necesita un valor que pueda aplicar a todas las filas existentes sin evaluarlo fila por fila.

Si lo que quieres es un NOT NULL sin valor por defecto, vas a tener que añadir la columna como nullable, rellenarla con un UPDATE y luego reconstruir la tabla para añadir la restricción. Lo cual nos lleva directo a las limitaciones.

Limitaciones de ALTER TABLE en SQLite

Cosas que funcionan en Postgres o MySQL, pero no en SQLite:

• Cambiar el tipo de una columna (ALTER COLUMN ... TYPE ...).
• Cambiar el valor por defecto de una columna sobre la marcha.
• Añadir o quitar NOT NULL, CHECK, UNIQUE o PRIMARY KEY en una columna ya existente.
• Añadir una clave foránea a una columna existente.
• Reordenar columnas.

Cualquiera de estas operaciones te lanza un error de sintaxis. SQLite directamente no tiene cláusula ALTER COLUMN. Y la respuesta oficial es siempre la misma: reconstruir la tabla.

El patrón para reconstruir una tabla

Cuando ALTER TABLE se queda corto, la receta es: creas una tabla nueva con el esquema que quieres, copias los datos, eliminas la antigua y renombras la nueva para que ocupe su lugar. Envuélvelo todo en una transacción para que sea todo o nada:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT,
    age TEXT
);

INSERT INTO users (email, age) VALUES ('ada@example.com', '36'), ('boris@example.com', '41');

BEGIN;

CREATE TABLE users_new (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    age INTEGER CHECK (age > 0)
);

INSERT INTO users_new (id, email, age)
SELECT id, email, CAST(age AS INTEGER) FROM users;

DROP TABLE users;
ALTER TABLE users_new RENAME TO users;

COMMIT;

SELECT * FROM users;

Ahora users.age es un entero con una restricción CHECK y email quedó como NOT NULL. Los datos se vinieron con todo.

Algunas cosas que conviene tener presentes cuando hagas esto en producción:

• Desactiva las claves foráneas mientras dure la operación. Si otras tablas referencian a la tuya, ejecuta PRAGMA foreign_keys = OFF; antes de la transacción y PRAGMA foreign_keys = ON; al terminar. Si no, el DROP TABLE fallará. Ojo: este pragma no se puede modificar dentro de una transacción, así que tienes que hacerlo por fuera.
• Recrea los índices y triggers. Al borrar la tabla vieja también se eliminan sus índices y triggers. Vuelve a crearlos sobre la tabla nueva después del renombrado.
• Revisa las vistas. Las vistas que referencian la tabla siguen apuntando al nombre viejo en su SQL almacenado. Reconstruye las que dependan de columnas que hayan cambiado.

El patrón de reconstruir tabla en SQLite es verboso, pero confiable. Es justo lo que hacen herramientas de migraciones como Alembic o Rails por debajo cuando trabajan contra SQLite.

Eliminar varias tablas en SQLite

No existe una sola sentencia para hacer sqlite drop table sobre varias tablas a la vez: tienes que ejecutar un DROP TABLE por cada una. Si quieres agruparlas, mételas dentro de una transacción:

CREATE TABLE a (id INTEGER);
CREATE TABLE b (id INTEGER);
CREATE TABLE c (id INTEGER);

BEGIN;
DROP TABLE a;
DROP TABLE b;
DROP TABLE c;
COMMIT;

SELECT name FROM sqlite_master WHERE type = 'table';

Si las metes dentro de una transacción, o se ejecutan los tres DROP o no se ejecuta ninguno. Resulta útil cuando estás desmontando tablas relacionadas y la operación podría fallar a mitad por las claves foráneas.

Lo que te llevas

• DROP TABLE elimina una tabla junto con sus índices y triggers. Usa IF EXISTS para que tus scripts sean idempotentes.
• ALTER TABLE en SQLite solo hace cuatro cosas: renombrar la tabla, renombrar una columna, añadir una columna y eliminar una columna.
• Para cualquier otra cosa —cambiar tipos, añadir constraints nuevos o claves foráneas a columnas ya existentes— toca reconstruir la tabla dentro de una transacción.
• Cuando reconstruyas, no pierdas de vista las claves foráneas, los índices, los triggers y las vistas. Esos no viajan con los datos automáticamente.

Lo que viene: meter datos en las tablas

Hasta aquí has dedicado un capítulo entero a las tablas y a las restricciones que les dan forma. Toca llenarlas. El siguiente capítulo arranca con INSERT, incluyendo la variante de inserción de varias filas, los valores por defecto y cómo gestiona SQLite las inserciones que chocan con tus constraints.