Crear y modificar tablas de base de datos: restricciones

La definición de una tabla describe qué puede contener cada fila. No añade ninguna fila. En una tienda en línea, cada producto necesita campos separados para su identificador, nombre, precio y cantidad en existencias.

Construye la definición

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL,
  in_stock INTEGER DEFAULT 0
);

Lee de fuera hacia dentro. CREATE TABLE products da nombre a la tabla nueva. Los paréntesis contienen las definiciones de sus columnas. Cada línea indica un nombre de columna, un tipo y las reglas de esa columna. Las comas separan las definiciones; la última no lleva coma. El punto y coma termina la sentencia. Tras ejecutarse correctamente, SELECT * FROM products; devuelve cero filas.

Esta declaración de clave genera identificadores en SQLite. En PostgreSQL, utiliza id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY para generarlos. La declaración decimal también se comporta de forma distinta en estos sistemas; elegir un almacenamiento exacto forma parte de la elección del tipo.

Asigna una columna a cada dato

Una fila de cliente podría contener id, first_name, last_name, email y signup_date. Agrupar «Ana Ruiz, ana@example.com» en un campo dificulta buscar o comprobar el nombre y el correo por separado. Nombra los campos según lo que contienen. Los nombres cortos en minúsculas unidos por guiones bajos, como unit_price, son fáciles de reutilizar.

Evita las palabras clave como nombres: orders funciona, mientras que order sin comillas entra en conflicto con la palabra clave ORDER de SQL. Un nombre con espacios necesita comillas dobles, como en "order date", cada vez que lo utilices. PostgreSQL convierte los nombres sin comillas a minúsculas, por lo que Products y products sin comillas hacen referencia al mismo nombre.

Las comillas simples tienen otra función: encierran valores de texto como 'Desk lamp'. Las comillas dobles identifican nombres. PostgreSQL interpreta "Desk lamp" como un nombre de columna, no como el texto de un producto.

Comprueba lo que se ha creado

Una coma final antes de ) provoca un error de sintaxis. La falta de una coma también suele hacerlo, pero SQLite puede interpretar varias palabras como un único nombre de tipo. CREATE TABLE t (a INTEGER b TEXT); crea una columna llamada a, no dos columnas. Inspecciona la definición:

• Consola de SQLite: .schema products muestra la sentencia de creación.
• SQL de SQLite: PRAGMA table_info(products); enumera columnas y tipos.
• psql de PostgreSQL: \d products muestra columnas, tipos y restricciones.

CREATE TABLE IF NOT EXISTS products (...) evita un error cuando el nombre ya existe. No compara ni actualiza la definición anterior. Una tabla a la que le falte una columna necesaria seguirá igual.

Crea una copia puntual

CREATE TABLE cheap_products AS
SELECT name, price FROM products WHERE price < 10;

Esto crea columnas y copia las filas de la consulta. Los cambios posteriores en los productos no actualizan la copia. En SQLite y PostgreSQL, la tabla nueva no hereda la clave primaria ni las reglas NOT NULL o CHECK del origen.

CREATE, ALTER y DROP pertenecen al lenguaje de definición de datos, o DDL: modifican la estructura. INSERT, UPDATE y DELETE pertenecen al lenguaje de manipulación de datos, o DML: modifican filas. SELECT lee datos; los libros difieren en si lo incluyen en DML o asignan a las consultas su propia familia.

Elige un tipo según la función que deba cumplir el valor. Una cantidad debe permitir cálculos aritméticos. Un código postal de EE. UU. debe conservar sus caracteres, incluidos los ceros iniciales. Ambos pueden contener cifras, pero necesitan almacenamientos distintos.

Elige tipos numéricos y de texto

En PostgreSQL, NUMERIC(8, 2) tiene ocho cifras en total, dos tras la coma decimal. Su mayor valor positivo es 999 999,99. Insertar 12,345 almacena 12,35; 1 234 567,00 provoca un desbordamiento porque necesita siete cifras antes de la coma. DECIMAL es otro nombre de esta familia de tipos.

SQLite acepta NUMERIC(8, 2), pero no exige esa precisión ni esa escala. Almacena 19,99 en coma flotante y conserva 12,345 sin redondear. Almacena 1999 céntimos enteros para un importe exacto de 19,99. La coma flotante aproxima fracciones binarias: SELECT 0.1 + 0.2 = 0.3; de SQLite devuelve 0. PostgreSQL trata esos literales decimales sin conversión como valores numéricos exactos; conviértelos a DOUBLE PRECISION para ver el resultado aproximado.

Los números de texto se ordenan por caracteres: '100', '25', '9' aparecen en ese orden. Las cantidades numéricas necesitan columnas numéricas. El código postal '02139' debe ser texto; el almacenamiento como entero pierde su cero inicial.

El VARCHAR(20) de PostgreSQL rechaza textos de más de 20 caracteres. Su CHAR(n) rellena el texto más corto con espacios hasta una longitud fija. TEXT no tiene un límite de caracteres declarado. SQLite trata tanto VARCHAR(n) como CHAR(n) como texto, sin exigir la longitud ni añadir relleno.

Almacena fechas y valores sí/no

PostgreSQL tiene DATE, TIME, TIMESTAMP y BOOLEAN. Rechaza un DATE imposible como '2026-02-30'. SQLite no tiene un tipo de almacenamiento específico para fechas. Utiliza texto ISO como '2026-03-15', cuyo orden de caracteres coincide con el de las fechas. El texto de estilo estadounidense ordena mal las fechas de años distintos: '12/01/2025' se ordena después de '03/15/2026'.

Una marca de tiempo añade una hora, como en '2026-03-15 14:30:00'. PostgreSQL utiliza TRUE y FALSE para los booleanos; SQLite almacena 1 y 0 y acepta esas palabras clave. MySQL trata BOOLEAN como un entero pequeño; SQL Server utiliza BIT.

Comprende qué exige el sistema

Las tablas normales de SQLite utilizan afinidad de tipo, una preferencia de almacenamiento. Una columna INTEGER convierte '5' en 5, pero acepta 'abc' como texto. PostgreSQL rechaza el texto que no puede convertirse en un entero. SQLite 3.37.0 y posteriores admiten tablas STRICT, cuyos tipos permitidos son INT, INTEGER, REAL, TEXT, BLOB y ANY.

Para los pedidos, elige un id entero, un correo de texto, una fecha DATE de PostgreSQL o de texto ISO de SQLite, NUMERIC(10, 2) de PostgreSQL o céntimos enteros de SQLite para el total, y un booleano o un indicador 0/1 para el pago. NULL significa ausente o desconocido; no es un tipo ni equivale a cero o a una cadena vacía. Una columna lo acepta salvo que una regla lo prohíba.

Una restricción hace que la base de datos rechace datos que incumplen una regla declarada. La comprobación se ejecuta al insertar o actualizar filas, independientemente de la aplicación que envíe la sentencia. Las distintas reglas protegen distintas partes de un registro de producto.

Combina reglas en una tabla

Esta definición de SQLite genera la clave y comprueba los demás campos. Para PostgreSQL, sustituye la línea de la clave por una clave primaria de identidad.

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  sku TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL CHECK (price > 0),
  in_stock INTEGER NOT NULL DEFAULT 0 CHECK (in_stock >= 0)
);

NOT NULL exige un valor. UNIQUE impide repetir un SKU. CHECK (price > 0) rechaza los precios iguales a cero o negativos. Las existencias tienen un valor predeterminado de 0 y deben mantenerse no negativas. La declaración numérica de SQLite no proporciona aritmética decimal exacta, así que utiliza céntimos enteros cuando la exactitud sea importante.

Distingue entre omitir y asignar NULL

Inserta una lámpara de escritorio con SKU 'LAMP-01', nombre 'Desk lamp' y precio 24,99, omitiendo las existencias de la lista de columnas. La inserción se realiza correctamente y recibe existencias 0. Proporcionar existencias NULL no solicita el valor predeterminado: incumple NOT NULL.

Una taza de café con precio -3,50 incumple la comprobación del precio. Un segundo producto con SKU 'LAMP-01' incumple UNIQUE, aunque su nombre y precio sean distintos. Un bolígrafo sin nombre incumple NOT NULL. Lee la regla o columna mencionada en el error y corrige los datos de entrada.

La cadena vacía es un valor real. name TEXT NOT NULL acepta '' en SQLite y PostgreSQL. Añade CHECK (name <> '') para rechazarla. Oracle trata la cadena vacía como NULL, por lo que allí la misma entrada queda sujeta a otra regla.

Comprueba combinaciones y valores ausentes

Una regla de columna va después de su tipo. Una regla de tabla es un elemento independiente dentro de la definición de la tabla y puede comparar columnas:

CHECK (end_date >= start_date),
UNIQUE (order_id, product_id)

La primera rechaza una fecha de fin anterior a la de inicio. La segunda rechaza un par repetido: un producto puede aparecer en pedidos distintos, pero no dos veces en el mismo pedido. Una tabla puede tener varias restricciones de unicidad.

Una comprobación rechaza una fila cuando su condición es falsa. Si el precio es NULL, price > 0 es desconocido, por lo que se supera la comprobación. Por eso el precio del producto también necesita NOT NULL. PostgreSQL, SQLite y MySQL normalmente permiten varios valores NULL con UNIQUE; SQL Server permite uno en una restricción de unicidad de una sola columna. PostgreSQL 15 y posteriores ofrecen UNIQUE NULLS NOT DISTINCT cuando los valores ausentes también deben entrar en conflicto. Las versiones de MySQL anteriores a 8.0.16 ignoraban las reglas CHECK.

Asigna un nombre útil a una regla con CONSTRAINT price_positive CHECK (price > 0). El nombre ayuda a identificarla en un error y a eliminarla después. Una restricción comprueba exactamente su expresión: CHECK (email LIKE '%@%') detecta que falta una arroba, pero no puede detectar un error de escritura en una dirección que cumple el patrón.

Una clave primaria identifica una fila de forma fiable. Puede ser una columna o una combinación, pero una tabla tiene como máximo una clave primaria. La clave debe ser única y estar presente, de modo que otras sentencias puedan identificar una fila sin depender de su descripción.

Elige un identificador estable

Una clave natural es un identificador existente del mundo real, como el ISBN de un libro. Una clave sustituta es un identificador artificial, a menudo un entero generado. El correo de un cliente puede cambiar; un identificador de cliente generado puede mantenerse igual mientras eso ocurre.

Una clave compuesta identifica una combinación:

PRIMARY KEY (order_id, product_id)

Un pedido puede contener varios productos y un producto puede aparecer en varios pedidos. El par identifica una línea de pedido. Ninguna de las columnas necesita ser única por sí sola.

PostgreSQL, MySQL y SQL Server exigen claves primarias sin valores ausentes. Las tablas normales de SQLite conservan una excepción histórica: una clave primaria distinta de INTEGER PRIMARY KEY puede contener NULL. Utiliza code TEXT PRIMARY KEY NOT NULL para una clave de texto. Las tablas STRICT de SQLite también cierran esta brecha.

Deja que la base de datos genere el número

Omite id de la lista de columnas de la inserción para solicitar un valor generado. Un simple INTEGER PRIMARY KEY de PostgreSQL no lo genera. El código antiguo de PostgreSQL suele utilizar SERIAL.

En SQLite, INTEGER PRIMARY KEY es un alias del número interno de fila. Empieza con los identificadores generados 1, 2 y 3, y después elimina 3. El siguiente identificador generado normal vuelve a ser 3, uno más que el máximo actual. Con INTEGER PRIMARY KEY AUTOINCREMENT, es 4: no se reutiliza un número que haya tenido una fila confirmada. Un número de una inserción revertida sí puede reutilizarse. Esta garantía más fuerte requiere trabajo adicional, así que elígela cuando sea importante no reutilizar números.

Lee los identificadores sin tratarlos como recuentos

Los huecos son normales. Las eliminaciones los dejan, y PostgreSQL no devuelve los números a la secuencia tras inserciones fallidas o revertidas. Utiliza COUNT(*) para contar filas y una marca de tiempo para el momento de un suceso. El mayor identificador no responde de forma fiable a ninguna de esas preguntas.

La forma GENERATED ALWAYS de PostgreSQL normalmente rechaza un identificador explícito como 50. GENERATED BY DEFAULT y SERIAL aceptan valores explícitos, pero proporcionar 50 no hace avanzar el generador más allá de 50. Un valor generado posteriormente puede entrar en conflicto con él.

Para utilizar la clave de una fila nueva en una fila relacionada, recupera la clave:

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

RETURNING funciona en PostgreSQL y SQLite 3.35.0 y posteriores. SQLite también ofrece last_insert_rowid(), MySQL ofrece LAST_INSERT_ID() y SQL Server utiliza OUTPUT. Lee el resultado de la inserción en lugar de adivinar el siguiente identificador.

El customer_id de un pedido debe apuntar a un cliente que exista. Una clave foránea hace que la base de datos compruebe ese vínculo. La tabla que contiene la referencia es la hija; la tabla a la que apunta es la padre.

Declara y aplica el vínculo

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers(id)
);

Aquí customers debe existir primero y su id debe ser una clave primaria o única. Haz coincidir los tipos de ambos lados. La forma de tabla, FOREIGN KEY (customer_id) REFERENCES customers(id), declara el mismo vínculo por separado de la columna.

Con la aplicación de las restricciones activada, un pedido para el cliente 99 falla si no existe el cliente 99. Actualizar un pedido para asignarlo a ese cliente inexistente también falla. Una clave foránea que admita nulos puede contener NULL, que significa que no hay una fila vinculada; NOT NULL hace obligatorio el vínculo.

En SQLite, ejecuta PRAGMA foreign_keys = ON; en cada conexión nueva antes de iniciar una transacción. Un cambio de configuración dentro de una transacción no tiene efecto. PostgreSQL y SQL Server aplican las restricciones de clave foránea normalmente, al igual que el motor predeterminado de MySQL, InnoDB.

Predice la eliminación de una fila padre

Utiliza los clientes 1, Ana, y 2, Ben. Los pedidos 101 y 102 pertenecen a Ana; 103 pertenece a Ben. Considera la eliminación del cliente 1 con distintas declaraciones:

SET NULL necesita una columna que admita nulos. SET DEFAULT sigue teniendo que cumplir la clave foránea: un valor predeterminado no ausente debe identificar una fila padre existente. Un valor predeterminado NULL funciona cuando se permiten vínculos ausentes.

Elige según el significado de los datos. Las líneas de pedido suelen pertenecer por completo a su pedido, por lo que la cascada puede ser adecuada. Los pedidos que deben conservarse requieren una acción de bloqueo cuando alguien intenta eliminar a su cliente. Un vínculo opcional con un proveedor puede establecerse en NULL. Aplicar cascadas en todas partes permite que una eliminación borre más registros de lo que sugiere el nombre de su tabla.

Trabaja en orden de dependencias

Crea las tablas padre antes que las hijas e inserta las filas padre antes que las filas que hacen referencia a ellas. Al eliminar datos o tablas relacionados, trabaja de hijas a padres. Una acción ON UPDATE ofrece las mismas opciones cuando cambia la clave de la fila padre; ON UPDATE CASCADE copia la clave nueva a las hijas.

RESTRICT comprueba de inmediato. NO ACTION, la opción predeterminada, puede esperar hasta el final de la sentencia o, con una restricción diferible, hasta el final de la transacción. Ambas bloquean una eliminación normal que dejaría referencias sin correspondencia. Mantén estables los identificadores generados para que cambiar los datos de un cliente no obligue a cambiar todas las referencias a ese cliente.

INSERT añade filas a una tabla existente. Su lista de columnas establece la correspondencia entre los valores que proporcionas y los campos que los reciben. Escribe esa correspondencia de forma explícita para que un cambio posterior en la tabla no altere sin avisar el significado de tus datos de entrada.

Asigna los valores por posición

INSERT INTO products (sku, name, price, in_stock)
VALUES ('LAMP-01', 'Desk lamp', 24.99, 12);

Lee los pares en orden: SKU recibe 'LAMP-01', el nombre recibe 'Desk lamp', el precio recibe 24,99 y las existencias reciben 12. Debe haber cuatro valores para estas cuatro columnas. Una discrepancia, como dos valores para tres columnas, provoca un error.

Sin la lista, los valores siguen el orden de columnas declarado en la tabla. SQLite exige proporcionar todas las columnas; PostgreSQL permite menos y asigna valores predeterminados a las columnas finales. Una lista explícita evita depender de cualquiera de estos comportamientos. También te permite colocar las columnas en un orden claro para los datos de entrada.

Un par intercambiado puede ser peor que un error de sintaxis. Proporcionar 9,99 como nombre y 'Desk lamp' como precio hace que PostgreSQL rechace el precio no numérico. La afinidad normal de SQLite puede almacenar el texto del nombre «9.99» y el texto del precio «Desk lamp» sin dar error. Vuelve a leer la fila insertada con SELECT para comprobar la correspondencia.

Escribe correctamente los valores literales

El apóstrofo duplicado almacena un solo apóstrofo. Los números no llevan símbolos monetarios ni separadores de millares; una coma separa valores, por lo que una coma dentro de un importe sin comillas cambia el número de valores. 'NULL' es el texto de cuatro letras «NULL», no un valor ausente.

Deja que los campos omitidos se rellenen solos

Una columna omitida recibe su valor predeterminado, o NULL si no tiene ninguno. Una clave generada recibe un valor generado. Este último comportamiento depende de la declaración: INTEGER PRIMARY KEY de SQLite genera identificadores; PostgreSQL requiere una declaración de identidad para este fin. Una clave primaria entera simple de PostgreSQL omitida de una inserción provoca un error porque su valor sería NULL.

PostgreSQL, MySQL y SQL Server permiten DEFAULT como marcador de valor. SQLite no lo acepta dentro de una lista VALUES; omite esa columna en su lugar. Un NULL explícito nunca solicita el valor predeterminado.

Añade varias filas juntas

INSERT INTO customers (first_name, last_name, email) VALUES
  ('Ana', 'Ruiz', 'ana@example.com'),
  ('Ben', 'Okafor', 'ben@example.com'),
  ('Chloe', 'Nguyen', 'chloe@example.com');

En una tabla vacía cuya clave generada empieza en 1, reciben los identificadores 1, 2 y 3. Con la gestión normal de restricciones, la sentencia de varias filas se ejecuta correctamente en su conjunto o falla en su conjunto. Si una fila infringe una regla, no se inserta ninguna de las filas de esta sentencia.

Un error UNIQUE señala una clave o valor duplicado; NOT NULL señala datos ausentes; CHECK señala una condición incumplida; y un error de clave foránea señala un vínculo no válido. Corrige el valor o la correspondencia prevista antes de volver a intentarlo.

No es necesario escribir las filas de una en una. Una consulta puede proporcionar las filas de una inserción, y una regla de conflicto puede indicar qué debe ocurrir cuando un valor único ya existe. Ambas funciones dependen de seleccionar con precisión los datos previstos.

Copia el resultado de una consulta

INSERT INTO archived_orders (id, customer_id, order_date, total)
SELECT id, customer_id, order_date, total
FROM orders
WHERE order_date < '2026-01-01';

No hay cláusula VALUES: la consulta proporciona los valores. Haz corresponder sus columnas seleccionadas con la lista de destino por posición. La tabla de destino debe existir y sus reglas siguen aplicándose.

Revisa primero el SELECT por separado. Los pedidos 201, 202 y 204 tienen las fechas 2025-11-03, 2025-12-19 y 2025-10-30 y los totales 45,00, 120,50 y 60,00. Los pedidos 203 y 205 tienen fechas de 2026. La consulta devuelve tres filas que suman 225,50 y la inserción copia esas tres. También puede copiar cero filas cuando el filtro no encuentra nada.

Una segunda ejecución intenta copiarlas de nuevo. Una clave primaria en el destino hace que eso falle en lugar de almacenar duplicados sin avisar. INSERT ... SELECT es una operación de copia; no elimina las filas de origen ni mantiene sincronizadas las dos tablas.

Las importaciones de archivos suelen pasar primero por una tabla de preparación. La consola de SQLite utiliza .import --csv file.csv staging; psql utiliza \copy. En una consulta posterior, TRIM(email) elimina los espacios de los extremos y NULLIF(TRIM(email), '') convierte un correo vacío o compuesto solo por espacios en NULL. Las restricciones de destino comprueban entonces las filas limpias.

Lee el resultado de una escritura

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

El resultado proporciona el identificador de cliente generado para utilizarlo en una fila relacionada. PostgreSQL y SQLite 3.35.0 y posteriores admiten RETURNING en inserciones, actualizaciones y eliminaciones. MySQL utiliza LAST_INSERT_ID() para un identificador generado; SQL Server utiliza OUTPUT.

Decide cómo gestionar los duplicados

Con stock (sku TEXT PRIMARY KEY, qty INTEGER NOT NULL), supón que 'LAMP-01' tiene una cantidad de 12. Una inserción simple que propone el mismo SKU y una cantidad de 20 falla. En SQLite y PostgreSQL:

INSERT INTO stock (sku, qty) VALUES ('LAMP-01', 20)
ON CONFLICT (sku) DO UPDATE
SET qty = stock.qty + excluded.qty;

stock.qty es el 12 existente. excluded.qty es el 20 propuesto. Esta forma almacena 32, lo que corresponde a una entrega adicional. SET qty = excluded.qty almacena 20, lo que corresponde a un recuento de sustitución. DO NOTHING conserva 12 y omite la fila en conflicto. Cada variante parte de la misma cantidad original de 12.

Una inserción o actualización combina insertar una fila nueva con actualizar cuando hay un conflicto. El destino del conflicto debe tener una protección de unicidad adecuada. La familia equivalente de MySQL es ON DUPLICATE KEY UPDATE. Un INSERT simple no corrige un cliente existente: crea otra fila o provoca un error de unicidad. Utiliza UPDATE para una fila que sabes que existe y una inserción o actualización cuando la fila podría existir ya.

UPDATE modifica valores de filas que ya existen. Indica una tabla, asigna valores nuevos con SET y después elige las filas de destino con WHERE. Las restricciones de la tabla comprueban los valores resultantes.

Asigna valores a uno o varios campos

UPDATE products
SET price = 22.50, in_stock = 30
WHERE id = 3;

El producto con clave 3 recibe ambos valores; las demás filas conservan los suyos. Las asignaciones utilizan comas. Escribir SET price = 22.50 AND in_stock = 30 no significa hacer dos asignaciones. PostgreSQL lo rechaza; SQLite trata el lado derecho como una expresión booleana y puede almacenar 0 o 1 en el precio.

Omitir WHERE es SQL válido y aplica el cambio a todas las filas. UPDATE products SET price = 0; establece el precio de todos los productos en cero si las reglas de la tabla lo permiten. Una vista previa con la condición prevista muestra si el destino es una fila, varias o ninguna.

Calcula a partir del valor almacenado

UPDATE products
SET price = price * 1.10;

Un precio de 20,00 pasa a ser 22,00 tras un aumento del 10 %. Un precio de 19,99 da un resultado sin redondear de 21,989. PostgreSQL almacena 21,99 en una columna NUMERIC(8, 2). SQLite no exige la escala, por lo que SET price = ROUND(price * 1.10, 2) solicita dos decimales. Para almacenar dinero con exactitud en SQLite, conserva céntimos enteros y haz explícita la decisión de redondeo de los céntimos.

La expresión debe incluir el valor anterior cuando el cambio es relativo. SET in_stock = in_stock - 1 resta una unidad; SET in_stock = 1 sustituye el recuento por uno.

En SQLite y PostgreSQL, todas las expresiones del lado derecho leen la fila anterior a la actualización. UPDATE t SET a = b, b = a; intercambia los valores de una fila de 1 y 2 a 2 y 1. La actualización de una sola tabla de MySQL evalúa las asignaciones de izquierda a derecha, por lo que la misma forma deja ambos en 2. No traslades esta suposición de un sistema a otro.

Ten presentes las reglas y los valores ausentes

Utiliza SET phone = NULL para vaciar un campo de teléfono. Para encontrar valores de teléfono ausentes, utiliza WHERE phone IS NULL. La igualdad con NULL no los encuentra.

Considera los precios 12,00, 3,00 y 8,50 protegidos por CHECK (price > 0). Restar 5 a todos los precios haría que el segundo fuera -2,00. Con la gestión normal de restricciones, ese fallo deshace toda la sentencia, por lo que incluso los precios que serían válidos se mantienen sin cambios.

Una actualización de clave primaria también debe cumplir las claves foráneas relacionadas. Un cambio de clave bloqueado falla mientras las filas hijas apunten a la clave anterior; ON UPDATE CASCADE les transmite el nuevo valor. Mantener estables los identificadores generados evita este trabajo adicional cuando cambian los datos descriptivos.

Interpreta el número de filas afectadas

psql informa de un resultado como UPDATE 3; changes() de SQLite informa del recuento de la última sentencia de cambio. Ambos incluyen las filas seleccionadas y actualizadas aunque el valor asignado sea igual al anterior. Un recuento de tres no garantiza tres valores visiblemente distintos. Compara el recuento con la vista previa e inspecciona después los campos relevantes, o utiliza RETURNING para ver directamente las filas afectadas.

DELETE elimina filas completas. Deja la tabla preparada para volver a contener filas. Para vaciar un campo se utiliza UPDATE ... SET column = NULL; DELETE email FROM customers no es SQL válido.

Sigue una eliminación filtrada

La tienda tiene estos pedidos:

DELETE FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

El pedido 201 cumple ambas pruebas, al igual que 204. El pedido 203 está cancelado, pero es demasiado reciente; 202 es suficientemente antiguo, pero está enviado. La sentencia elimina dos filas y conserva 202, 203 y 205. DELETE FROM orders; sin la condición eliminaría los cinco.

Utiliza datos relacionados para elegir filas

DELETE FROM order_items
WHERE order_id IN (
  SELECT id FROM orders WHERE status = 'cancelled'
);

La consulta interna produce los identificadores de los pedidos cancelados. IN comprueba el order_id de cada línea frente a esa lista. Ejecuta la consulta interna por separado para inspeccionar las claves y después revisa las filas de las líneas con la misma condición.

Las claves foráneas también afectan a la eliminación. Una fila padre con filas hijas que la referencian puede estar protegida por NO ACTION o RESTRICT; una cascada elimina las filas hijas; SET NULL las conserva, pero borra el vínculo. Comprueba esas acciones al valorar el efecto de eliminar una fila padre, porque la tabla nombrada directamente puede no ser la única que cambie.

Elige qué debe conservarse

PostgreSQL, MySQL, SQL Server y Oracle admiten TRUNCATE; SQLite no. Sus reglas de transacciones y dependencias varían según la base de datos. Una sentencia que parece una operación de vaciado rápido también debe ajustarse a esas reglas.

Conserva el historial con una eliminación lógica

UPDATE customers
SET deleted_at = '2026-03-15'
WHERE id = 7;

Una eliminación lógica marca la fila sin borrarla. Puede conservar el historial y permitir la restauración borrando la marca. Las consultas de clientes activos deben incluir WHERE deleted_at IS NULL; de lo contrario, los clientes marcados siguen apareciendo. Marcar los datos no los borra.

Una eliminación confirmada no puede deshacerse con un ROLLBACK posterior. La restauración necesita una copia guardada o una copia de seguridad. Dentro de una transacción abierta, una reversión aún puede restaurar las filas eliminadas. Comprueba los identificadores seleccionados y el recuento de filas afectadas antes de hacer permanente el resultado.

Elegir las filas suele ser la parte más difícil de un cambio. El mismo filtro que resulta inofensivo en una consulta puede eliminar o actualizar demasiado al reutilizarlo en una escritura. Convierte la regla prevista en una condición y después inspecciona qué filas selecciona realmente.

Revisa la condición exacta

SELECT id, status, order_date FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Esta vista previa devuelve los pedidos 201 y 204 en el ejemplo de la tienda con cinco pedidos. Reutiliza exactamente esa condición en la eliminación. Reescribirla al cambiar la orden crea una selección nueva sin comprobar.

Para una fila concreta, utiliza su clave primaria: WHERE id = 42 selecciona como máximo una fila. Un nombre descriptivo como 'Desk lamp' puede ser compartido por varios productos.

Agrupa las alternativas explícitamente

AND tiene mayor precedencia que OR. Compara:

WHERE status = 'cancelled'
   OR status = 'expired' AND order_date < '2026-01-01'

con:

WHERE (status = 'cancelled' OR status = 'expired')
  AND order_date < '2026-01-01'

La primera acepta todos los pedidos cancelados, con independencia de la fecha, más los pedidos vencidos anteriores a 2026. Selecciona 201, 203 y 204. La segunda aplica la prueba de fecha a ambos estados y selecciona 201 y 204. El pedido 203 muestra la diferencia porque está cancelado en 2026.

Incluye los valores ausentes de forma deliberada

WHERE customer_id = NULL no selecciona filas. Los valores ausentes necesitan IS NULL o IS NOT NULL. Una prueba negativa también tiene una omisión: status <> 'shipped' no incluye un estado ausente, porque su comparación es desconocida.

Si el estado ausente pertenece al grupo previsto, escribe:

WHERE status <> 'shipped' OR status IS NULL

Al añadir otra condición, agrupa toda esta alternativa con paréntesis para que ambas ramas cumplan esa condición.

La búsqueda por patrones puede abarcar más que la descripción prevista. LIKE '%lamp%' coincide con «Desk lamp» y «Clamp». El LIKE predeterminado de SQLite también ignora las mayúsculas y minúsculas de las letras inglesas, así que encuentra «Lamp shade». Un patrón es útil para encontrar posibles coincidencias, pero inspecciónalas antes de modificarlas.

Elige una comparación de listas para una lista

UPDATE orders SET status = 'on hold'
WHERE customer_id IN (
  SELECT id FROM customers WHERE state = 'CA'
);

La subconsulta puede proporcionar varios identificadores de cliente; IN comprueba la pertenencia. Sustituir IN por = solicita un único resultado escalar. PostgreSQL rechaza varias filas en ese caso, mientras que SQLite utiliza solo la primera fila devuelta sin avisar y omite a los demás clientes.

Después del cambio, compara el recuento de filas afectadas con la vista previa. PostgreSQL y SQLite también permiten añadir RETURNING * para mostrar las filas afectadas. Para una escritura arriesgada, inicia una transacción antes de modificar los datos, inspecciona el resultado y después elige COMMIT o ROLLBACK.

Una transacción agrupa sentencias relacionadas en una unidad de trabajo. Decides conservar sus cambios juntos con COMMIT o deshacerlos juntos con ROLLBACK. La propiedad de todo o nada se llama atomicidad, la A de ACID.

Conserva ambos lados de una transferencia

La cuenta de Maya, con identificador 1, tiene 500,00. La cuenta de Leo, con identificador 2, tiene 120,00. Transferir 75,00 requiere dos cambios:

BEGIN;
UPDATE accounts SET balance = balance - 75.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 75.00 WHERE id = 2;
SELECT id, balance FROM accounts WHERE id IN (1, 2);
COMMIT;

La primera actualización deja a Maya con 425,00. La segunda deja a Leo con 195,00. La comprobación muestra ambos saldos antes de confirmar y el total se mantiene en 620,00. Para estos saldos decimales exactos, utiliza NUMERIC de PostgreSQL; en SQLite, una versión con importes monetarios exactos almacena 50 000 y 12 000 céntimos y transfiere 7500 céntimos.

Sin una transacción explícita y con confirmación automática, la primera actualización podría hacerse permanente antes de que se ejecute la segunda. Un fallo entre ambas conservaría el cargo sin el abono. Una transacción da a las dos actualizaciones una sola decisión final de conservar o deshacer. Si falla una sentencia, gestiona el error antes de decidir que la transferencia está completa.

Comprende el límite predeterminado

Con la confirmación automática de la base de datos, cada sentencia independiente que se ejecuta correctamente se confirma como su propia transacción. Este es el comportamiento inicial habitual de SQLite, PostgreSQL, MySQL y SQL Server. Una biblioteca de programación o un cliente pueden elegir otra configuración e iniciar una transacción por ti.

BEGIN; inicia una transacción explícita en SQLite y PostgreSQL. SQLite y SQL Server también utilizan BEGIN TRANSACTION; PostgreSQL y MySQL aceptan START TRANSACTION. Oracle inicia una transacción con un cambio de datos y normalmente espera a COMMIT en herramientas como SQL*Plus, salvo que esté activada la confirmación automática.

COMMIT termina la transacción y conserva sus cambios. ROLLBACK la termina y deshace sus cambios sin confirmar. Una reversión posterior no puede traspasar una confirmación anterior.

Inspecciona y deshaz

BEGIN;
DELETE FROM orders;
SELECT * FROM orders;
ROLLBACK;

Tu conexión ve una tabla vacía en el SELECT y vuelve a ver los cinco pedidos después de la reversión. El resultado vacío era real dentro de la transacción, pero aún no era permanente. Las demás conexiones normalmente no ven los cambios sin confirmar.

Una transacción solo puede protegerte de una selección de filas equivocada si inspeccionas y decides deshacerla. SQL puede actualizar correctamente una fila no deseada: ninguna regla de la base de datos sabe qué cuenta querías indicar. Compara los identificadores, valores y recuentos devueltos con el resultado previsto antes de confirmar.

Mantén las transacciones breves y finalízalas. Las transacciones abiertas pueden mantener bloqueos que hacen esperar a otras conexiones; SQLite solo permite un escritor a la vez. Cerrar una conexión con una transacción sin terminar revierte sus cambios pendientes. Cuando una biblioteca inicia una transacción automáticamente, el programa debe invocar su método de confirmación para conservar el trabajo.

Una sentencia fallida no tiene el mismo efecto en todas las bases de datos. Debes saber qué sigue pendiente antes de decidir cómo recuperarte. Un punto de guardado puede ofrecer un punto de retorno más cercano dentro de una transacción abierta.

Sigue un error

Después de la transferencia, Maya tiene 425,00 y Leo tiene 195,00. La tabla tiene CHECK (balance >= 0). Inicia una transacción y resta 30,00 a Maya: su saldo pendiente es 395,00. Después intenta restar 300,00 a Leo. Eso dejaría su saldo en -105,00, por lo que la segunda sentencia falla.

En SQLite, confirmar en este punto conservaría solo el cargo de Maya. En PostgreSQL, COMMIT sobre la transacción fallida la termina con una reversión. Un procedimiento claro de recuperación es ejecutar ROLLBACK, corregir la causa y volver a ejecutar las sentencias relacionadas. Ambos saldos vuelven entonces a 425,00 y 195,00 antes del intento corregido.

Deshaz una parte posterior con un punto de guardado

BEGIN;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
SAVEPOINT after_first;
UPDATE accounts SET balance = balance + 10 WHERE id = 2;
ROLLBACK TO after_first;
COMMIT;

El punto de guardado va después del aumento de Maya. ROLLBACK TO deshace el aumento posterior de Leo, pero conserva el de Maya. Los saldos finales son 435,00 y 195,00. No termina la transacción exterior; eso lo hace COMMIT.

RELEASE after_first elimina el punto de guardado sin deshacer los cambios posteriores. No es una confirmación permanente independiente dentro de la transacción exterior. PostgreSQL también permite que ROLLBACK TO sobre un punto de guardado establecido antes de un error elimine el estado fallido y continúe desde ese punto.

Comprueba si los cambios de estructura pueden revertirse

SQLite y PostgreSQL permiten CREATE TABLE, ALTER TABLE y DROP TABLE dentro de transacciones. Por ejemplo, BEGIN; DROP TABLE orders; ROLLBACK; restaura la tabla y sus filas.

El DDL normal sobre tablas permanentes en MySQL y Oracle provoca confirmaciones implícitas. Un CREATE TABLE, ALTER TABLE, DROP TABLE o TRUNCATE TABLE puede confirmar cambios anteriores pendientes además de realizar su propia operación estructural. Una reversión posterior no puede deshacer ese trabajo anterior. No supongas que una transacción que engloba un script hace que todos los dialectos de bases de datos se comporten igual.

Para un cambio de datos arriesgado, inicia la transacción, ejecuta la escritura, inspecciona sus valores y su recuento y después confirma o revierte. Por ejemplo, inspecciona los precios de iluminación después de UPDATE products SET price = ROUND(price * 1.10, 2) WHERE category = 'lighting';. Toma la decisión pronto para que la transacción no mantenga otros trabajos en espera.

ALTER TABLE modifica la estructura de una tabla existente y conserva sus filas. UPDATE modifica los valores que contienen esas filas. Añadir un campo de descuento requiere ALTER TABLE; aumentar los descuentos ya almacenados requiere UPDATE.

Añade y renombra campos

ALTER TABLE customers ADD COLUMN phone TEXT;
ALTER TABLE customers RENAME COLUMN phone TO mobile;
ALTER TABLE customers RENAME TO clients;

SQLite y PostgreSQL comparten estas formas. Una columna nueva asigna a las filas existentes su valor predeterminado, o NULL cuando no tiene ninguno. ADD COLUMN active INTEGER NOT NULL DEFAULT 1 asigna a cada fila actual un valor activo de 1. Añadir email TEXT NOT NULL sin valor predeterminado falla en una tabla con datos porque las filas existentes carecerían de un valor obligatorio.

SQLite admite RENAME COLUMN desde la versión 3.25.0 y DROP COLUMN desde la 3.35.0. Al renombrar, actualiza el código de la aplicación y las consultas guardadas que hagan referencia al nombre anterior. El SQL externo a la base de datos no puede descubrir automáticamente el nombre nuevo.

Rellena los datos antes de exigirlos

En PostgreSQL, añade una columna que admita nulos, rellena las filas existentes con valores adecuados y solo entonces hazla obligatoria:

ALTER TABLE customers ADD COLUMN email TEXT;
UPDATE customers SET email = 'unknown@example.com'
WHERE email IS NULL;
ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

Esto ilustra cómo rellenar un campo obligatorio; no declara el correo como único. Una columna real de correo único necesita valores válidos distintos. SET NOT NULL falla si quedan valores ausentes. PostgreSQL también permite modificar un tipo con ALTER COLUMN price TYPE NUMERIC(10, 2), establecer un valor predeterminado y añadir una comprobación con nombre. Las filas existentes deben cumplir cualquier regla nueva.

Elimina un campo o reconstruye una tabla

ALTER TABLE customers DROP COLUMN mobile; elimina el campo y todos sus valores almacenados. Las dependencias pueden bloquear la operación. SQLite rechaza eliminar una columna de clave primaria, única, indexada o de clave foránea, o una utilizada por otro objeto del esquema. PostgreSQL puede eliminar objetos dependientes con CASCADE, incluida una vista que utilice la columna.

SQLite no puede modificar el tipo de una columna existente ni añadir restricciones de clave primaria, unicidad, clave foránea o comprobación a columnas existentes con un simple ALTER. La versión 3.53.0 añade ALTER COLUMN ... SET NOT NULL y DROP NOT NULL, pero no la edición general de restricciones. Una columna recién añadida puede tener una comprobación o una referencia permitida, pero no puede tener PRIMARY KEY ni UNIQUE; con las claves foráneas activadas, una referencia añadida necesita un valor predeterminado NULL.

Para un cambio más amplio en SQLite:

1. Registra los índices, disparadores y vistas que deben volver a crearse. Si las claves foráneas están activadas, desactívalas antes de la transacción.
2. Inicia una transacción y crea una tabla nueva con las reglas deseadas.
3. Copia las filas utilizando columnas explícitas en INSERT INTO new_products (...) SELECT ... FROM products;.
4. Elimina la tabla anterior y renombra la nueva como products.
5. Vuelve a crear los objetos dependientes y ejecuta PRAGMA foreign_key_check;. Resuelve cualquier problema indicado antes de confirmar.
6. Confirma y restablece después la aplicación de las restricciones de clave foránea si estaba activada antes.

MySQL modifica las definiciones con MODIFY COLUMN; SQL Server utiliza ALTER COLUMN. Expresa un cambio estructural con la sintaxis admitida por la base de datos de destino antes de ejecutarlo.

DROP TABLE elimina tanto el contenedor como su contenido. Después de DROP TABLE archived_orders;, las consultas no pueden leer esa tabla porque ya no existe. Sus restricciones, índices y disparadores se eliminan con ella.

Elige el nivel de eliminación

DROP TABLE IF EXISTS archived_orders; evita un error si la tabla no existe. Aun así, elimina una tabla existente y sus datos. Un script de preparación que elimina y vuelve a crear tablas es destructivo cuando se ejecuta en una base de datos con registros que quieres conservar.

Respeta los vínculos entre tablas

Elimina las tablas hijas antes que las padre, invirtiendo el orden habitual de creación. En PostgreSQL, eliminar customers mientras una clave foránea de pedidos depende de ella falla. DROP TABLE customers CASCADE; también elimina la clave foránea dependiente y las vistas dependientes. La tabla de pedidos y sus filas se conservan, pero la relación con los clientes deja de exigirse.

Este CASCADE de PostgreSQL es distinto del ON DELETE CASCADE de una clave foránea. El primero elimina objetos dependientes de la base de datos durante un cambio de estructura. El segundo elimina filas hijas cuando se elimina una fila padre. Saber qué acción se utiliza evita una predicción incorrecta sobre los datos que se conservan.

Con la aplicación de las restricciones de clave foránea de SQLite activada, eliminar una tabla realiza primero una eliminación implícita de sus filas. Las filas hijas que las referencian pueden bloquearla. Si la relación declara ON DELETE CASCADE, esas filas hijas pueden eliminarse; SET NULL puede borrar sus vínculos. Por tanto, eliminar una tabla requiere prestar la misma atención a las referencias que eliminar filas, además de atender a la estructura de tabla que se elimina.

Conserva una vía de recuperación

Antes de eliminar o reconstruir una tabla con datos reales, conserva una copia utilizable. Una copia interna rápida de los datos es:

CREATE TABLE products_backup AS
SELECT * FROM products;

En SQLite y PostgreSQL, esto conserva los datos seleccionados, pero no las restricciones originales. No constituye una reconstrucción completa de la definición de la tabla. Una exportación o una copia de seguridad de la base de datos conserva los datos de recuperación fuera de la tabla que se modifica.

SQLite y PostgreSQL también permiten probar una eliminación de tabla dentro de una transacción:

BEGIN;
DROP TABLE archived_orders;
ROLLBACK;

La reversión restaura la tabla y sus filas porque la eliminación no se confirmó. Una vez confirmada, no puede revertirse ejecutando ROLLBACK después. En las bases de datos con confirmaciones implícitas de DDL, envolver la eliminación en sintaxis de transacción no proporciona esta posibilidad de deshacer. Inspecciona la base de datos de destino y las tablas implicadas antes de ejecutar un script de reconstrucción.