Ya tienes dónde poner los datos. Toca ponerlos. INSERT es la instrucción que añade filas a una tabla y, en apariencia, es la más simple del módulo: nombre de tabla, columnas, valores, punto. Pero detrás de esa simplicidad hay decisiones que separan un script que aguanta cinco años de uno que se rompe en la primera refactorización: listar o no listar las columnas, insertar una fila o cuarenta en una sola sentencia, dejar que el motor genere el id o forzarlo (y qué desastre silencioso provoca lo segundo), y cómo recuperar el id recién creado para poder insertar las líneas del pedido que acabas de registrar.

En esta lección aprenderás las cinco formas de INSERT, entenderás por fin qué hace el bloque de setval con el que termina tiendaverde.sql, sabrás diagnosticar de un vistazo cada uno de los cuatro errores que un INSERT puede darte, y terminarás registrando un pedido completo con sus tres líneas usando RETURNING, que es exactamente lo que hace una tienda online cada vez que alguien pulsa "Confirmar compra".

1. La sintaxis, y por qué hay que listar siempre las columnas
2. Insertar varias filas en una sola sentencia
3. DEFAULT y DEFAULT VALUES
4. La columna de identidad: omitirla, forzarla y setval
5. RETURNING: recuperar lo que acabas de insertar
6. INSERT ... SELECT: insertar el resultado de una consulta
7. Los cuatro errores de un INSERT y su diagnóstico
8. El orden de inserción cuando hay claves foráneas
9. ON CONFLICT DO NOTHING, de pasada
10. Carga masiva: COPY y \copy frente a INSERT
11. Ejemplo completo: alta de producto y registro de un pedido
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Un alta de proveedor:

Esa salida de psql merece una explicación, porque desconcierta a todo el mundo la primera vez:

Cada vez que ejecutes un INSERT, mira el segundo número. Si esperabas 5 filas y pone INSERT 0 3, algo va mal.

SQL permite omitir la lista de columnas si das un valor para todas, en el orden exacto de la tabla:

Funciona. Y es una bomba de relojería, por cuatro motivos:

La regla, sin excepciones: lista siempre las columnas. Cuesta veinte caracteres y te ahorra una clase entera de bugs. Es, con diferencia, el hábito más rentable de esta lección.

Con la lista explícita puedes además omitir las columnas que tengan DEFAULT o admitan nulos, y ponerlas en el orden que quieras:

id lo genera la identidad, email queda NULL (es nulable) y activo toma su DEFAULT TRUE. Tres columnas rellenas sin escribirlas.

Basta separar las tuplas por comas:

Es la forma que usa tiendaverde.sql en sus nueve bloques de carga, y no es solo cuestión de comodidad: es muchísimo más rápido.

Un INSERT de N filas no cuesta lo mismo que N INSERT de una fila:

Los tres primeros costes son fijos por sentencia y suelen dominar. En la práctica, insertar 1 000 filas con una sola sentencia frente a 1 000 sentencias sueltas puede ser entre 10 y 50 veces más rápido, y la mayor parte de esa diferencia viene del tercer punto: sin una transacción explícita, cada INSERT suelto se confirma a disco por su cuenta.

Límites prácticos: no hagas una sentencia con 100 000 tuplas. El texto de la consulta se vuelve enorme y el consumo de memoria del servidor también. Lotes de 500 a 5 000 filas son el punto dulce habitual. Y si hablamos de millones, la herramienta ya no es INSERT sino COPY (apartado 10).

La palabra clave DEFAULT puede aparecer como valor, y significa "usa el valor por omisión de esta columna":

stock toma 0, activo toma TRUE y fecha_alta toma CURRENT_DATE. Es idéntico a haber omitido las tres columnas, y de hecho omitirlas es preferible: se lee mejor. DEFAULT como valor solo resulta útil cuando construyes la sentencia desde un programa y te sale más cómodo mantener fija la lista de columnas.

DEFAULT VALUES inserta una fila con todos los valores por omisión:

(La fecha será la del día en que lo ejecutes.) Es un caso raro, pero existe: tablas de "reserva de identificador" o de estado inicial que se rellenan después.

Este apartado explica, por fin, el bloque más críptico de tiendaverde.sql.

Como no has dado id, PostgreSQL pide el siguiente valor a la secuencia asociada. Es lo correcto y lo que harás el 99 % de las veces.

Como TiendaVerde declara sus identidades GENERATED BY DEFAULT, puedes dar el id a mano:

Funciona… y no toca la secuencia. La secuencia sigue creyendo que el último valor entregado es el 6. Así que el siguiente INSERT sin id:

La secuencia ha entregado el 7, que ya estaba ocupado. Ese es el desajuste de la secuencia, y es uno de los fallos más desconcertantes que existen: la sentencia que falla es correcta y el error apunta a un id que tú no has escrito.

setval reposiciona la secuencia. La forma robusta, que no exige saber cómo se llama la secuencia:

Ahora el siguiente INSERT sin id pedirá el 8 y funcionará. Y aquí está la explicación de las nueve líneas finales del script del curso:

tiendaverde.sql inserta todos los id a mano —para que las lecciones puedan hablar del "cliente 7" o del "pedido 12" con ids estables y reproducibles—, así que al terminar la carga las nueve secuencias están en 1. Sin ese bloque, el primer INSERT sin id de cualquier tabla fallaría por clave duplicada. Ese es el detalle que 01-06 dejó anunciado "para el módulo 5".

Tres funciones útiles alrededor de las secuencias:

Cómo evitar todo esto: declara las identidades GENERATED ALWAYS AS IDENTITY (05-01) y no las fuerces nunca. TiendaVerde usa BY DEFAULT por una razón didáctica concreta; tu esquema no tiene por qué.

Y un detalle que sorprende: las secuencias no se deshacen con un ROLLBACK. Si una transacción consume el valor 21 y luego aborta, ese 21 se pierde para siempre. Es deliberado —de lo contrario dos sesiones concurrentes tendrían que esperarse—, y significa que los id autogenerados tienen huecos. No son un contador de filas ni deben usarse como tal.

Un INSERT normal solo te dice cuántas filas ha metido. RETURNING, extensión de PostgreSQL, te devuelve las filas insertadas, con sus valores generados incluidos:

Ahí tienes el id que ha generado el motor (21, el siguiente al 20), el activo que ha puesto el DEFAULT y la fecha_alta que ha puesto CURRENT_DATE. Todo eso lo habrías tenido que ir a buscar con un SELECT posterior… que, además, no sería fiable en un sistema con varios usuarios: entre tu INSERT y tu SELECT puede haber entrado otro pedido.

RETURNING admite lo mismo que un SELECT: columnas, expresiones, alias y *.

El caso canónico es insertar un padre y sus hijos: un pedido y sus líneas. Sin RETURNING, la secuencia sería:

1. INSERT INTO pedidos ...
2. SELECT MAX(id) FROM pedidos ← aquí está el fallo
3. INSERT INTO lineas_pedido (pedido_id, ...) VALUES (ese_id, ...)

El paso 2 es una condición de carrera: si otro cliente confirma su compra entre tu paso 1 y tu paso 2, MAX(id) te devuelve el pedido de otro y le cuelgas tus líneas. En una tienda con tráfico real esto no es una posibilidad teórica: pasa. RETURNING lo resuelve de raíz porque devuelve tu fila, no la última de la tabla.

Dos avisos sobre esta tabla. LAST_INSERT_ID() de MySQL es por conexión, así que es seguro frente a otros usuarios pero se pisa a sí mismo si haces dos INSERT seguidos. Y en SQL Server hay que preferir SCOPE_IDENTITY() a @@IDENTITY: el segundo devuelve el id generado por cualquier ámbito, incluidos los triggers, lo cual es una fuente clásica de errores.

RETURNING funciona igual en UPDATE (05-03) y en DELETE (05-04), y ahí es todavía más útil: te deja ver exactamente qué has cambiado o qué has borrado.

En lugar de VALUES, un INSERT puede alimentarse de una consulta. Es DML puro: no estás anidando una subconsulta (eso es el módulo 7), estás conectando la salida de un SELECT con la entrada de un INSERT.

Las columnas se emparejan por posición, no por nombre. Es la trampa clásica: si el SELECT devuelve (nombre, precio) y la lista de destino dice (precio, nombre), PostgreSQL se quejará por tipos incompatibles… o no se quejará y te dejará los datos cruzados.

Antes de archivar los pedidos entregados, guardamos una foto:

14 filas, los 14 pedidos entregados. fecha_archivo no aparece en la lista de destino, así que toma su DEFAULT CURRENT_DATE en todas.

El proveedor 5 (EcoNordic Supplies) está inactivo. Verde Atlántico (proveedor 3) se ofrece a suministrar los mismos artículos con un 8 % de recargo en el coste. En lugar de teclear cuatro altas:

Cuatro altas con una sentencia. Fíjate en lo que hace el SELECT: transforma mientras copia. Concatena un sufijo al nombre, sustituye el proveedor_id por una constante, recalcula el coste y pone el stock a cero. Ese es el verdadero valor de INSERT ... SELECT: no es copiar, es copiar transformando.

Comprobación de los costes, redondeados a dos decimales: 6,00 × 1,08 = 6,48; 6,90 × 1,08 = 7,452 → 7,45; 1,20 × 1,08 = 1,296 → 1,30; 8,70 × 1,08 = 9,396 → 9,40.

Todo lo que sabes del módulo 2 sirve aquí, ORDER BY y LIMIT incluidos:

(ROW_NUMBER() es una función de ventana del módulo 10; aquí solo numera las filas del ranking.)

Y ojo con un matiz: ORDER BY dentro de un INSERT ... SELECT no garantiza el orden físico de las filas en la tabla destino, porque en el modelo relacional una tabla es un conjunto sin orden (01-05). Solo determina qué filas entran cuando hay LIMIT. Para leerlas ordenadas necesitarás un ORDER BY en el SELECT, siempre.

Un INSERT puede fallar por cuatro motivos, uno por cada tipo de restricción. Conocer los mensajes literales te ahorra horas.

El DETAIL te muestra la fila completa tal como habría quedado, con los valores por omisión ya aplicados. Es muy útil: ahí ves qué columnas se rellenaron solas.

El nombre de la restricción te dice qué columna. Si fuera categorias_pkey, sería el id: probablemente el desajuste de secuencia del apartado 4.

El nombre de la restricción identifica la regla. Aquí es la puntuación de 1 a 5, y por eso 05-01 insistía tanto en nombrarlas: chk_resenas_puntuacion habría sido igual de claro; resenas_check1 no lo habría sido.

is not present in table es la firma inconfundible de una FK rota: has referenciado algo que no existe.

Un detalle importante: cuando un INSERT multifila falla, no se inserta ninguna fila. Una sentencia es atómica: o entra entera o no entra nada. Si insertas 500 tuplas y la 337 viola un CHECK, las 499 restantes tampoco se guardan.

La integridad referencial impone el mismo orden que imponía a CREATE TABLE en 05-01: primero los padres, después los hijos.

Intenta saltártelo y verás por qué:

Primero la categoría, después el producto:

Las relaciones reflexivas tienen un matiz propio. clientes.referido_por_id apunta a la misma tabla, así que el referidor debe existir antes que el referido. En el script del curso funciona porque los clientes están ordenados por id y ninguno es referido por otro de id mayor. Si no fuera así, tendrías dos opciones: insertar primero con referido_por_id a NULL y actualizarlo después (05-03), o usar una restricción diferida (DEFERRABLE INITIALLY DEFERRED), que pospone la comprobación al final de la transacción. Esta última pertenece de lleno al modelo transaccional del módulo 9.

Si intentas insertar una fila que viola un UNIQUE, el INSERT falla. A veces lo que quieres es que no falle y simplemente no haga nada:

Cero filas insertadas, cero errores. Es tremendamente útil para scripts que deben poder reejecutarse (cargas de datos maestros, semillas de desarrollo).

Su hermana mayor, ON CONFLICT ... DO UPDATE, resuelve el clásico "insértalo si no existe y actualízalo si existe". Eso es el UPSERT, y tiene lección propia: 05-05.

Para volúmenes grandes, INSERT no es la herramienta. PostgreSQL tiene COPY, diseñada específicamente para mover datos entre un fichero y una tabla:

\copy es el comando equivalente de psql, que lee el fichero en tu máquina y lo envía por la conexión. No necesita permisos especiales y es el que usarás casi siempre:

También funciona en sentido inverso, para exportar:

Comparativa honesta:

La regla: decenas o cientos de filas → INSERT multifila. Miles o millones → COPY. Y si necesitas transformar mientras cargas, el patrón profesional es de dos pasos: COPY a una tabla de staging sin restricciones, y de ahí INSERT ... SELECT transformando hacia la tabla definitiva. Ese patrón reaparecerá en 05-05 y en el módulo 11.

Equivalentes por motor: MySQL tiene LOAD DATA INFILE, SQL Server tiene BULK INSERT y la utilidad bcp, Oracle tiene SQL*Loader y las external tables, y SQLite tiene el comando .import de su consola. Ninguno es compatible con los demás.

Cerramos con lo que hace una tienda de verdad. Trabajamos sobre la base recién cargada.

Huerta del Turia (proveedor 1) incorpora garbanzos a la categoría Alimentación:

Tres columnas omitidas y tres columnas rellenas solas: id por la identidad, activo y fecha_alta por sus DEFAULT. Exactamente el trabajo que 05-01 dejó declarado en el DDL.

Pau Llorens Vidal (cliente 6) llama por teléfono. Le atiende Óscar Peris Blasco (empleado 4). Quiere dos aceites, una miel y tres infusiones, con portes de 4,95 €.

Paso 1: la cabecera, con RETURNING.

El pedido es el 21. Ese número no lo hemos elegido nosotros: nos lo ha dicho el motor.

Paso 2: las tres líneas, en una sola sentencia.

Los precios se copian del catálogo en el momento de la venta —es la desnormalización deliberada de precio_unitario (01-05)— y aquí eso significa: 12,50 €, 9,75 € y 3,25 €.

Las líneas 48, 49 y 50, a continuación de las 47 que ya había.

Paso 3: comprobar el pedido completo.

44,50 € de producto más 4,95 € de portes: 49,45 €. Todo el módulo 4 aplicado a una fila que has creado tú.

Lo que falta y por qué. Un sistema real haría estas dos inserciones dentro de una misma transacción, para que sea imposible que quede una cabecera sin líneas si algo falla en medio. Y descontaría el stock de los tres productos. Lo primero lo empezarás a usar en la próxima lección y lo estudiarás a fondo en el módulo 9; lo segundo es un UPDATE, y también es de la próxima lección.

Recuerda recargar. Si has ejecutado estos ejemplos, tu base ya no coincide con la del curso: hay 21 o más productos, 21 pedidos y 50 líneas. Vuelve a lanzar tiendaverde.sql antes de continuar.

• Omitir la lista de columnas. Funciona hoy y se rompe el día que alguien toque la tabla. Lista siempre las columnas.
• Insertar el id a mano en una identidad BY DEFAULT. La secuencia se queda atrás y el siguiente INSERT automático falla con duplicate key ... _pkey. Arréglalo con setval o, mejor, no lo hagas.
• Usar SELECT MAX(id) para saber qué acabas de insertar. Es una condición de carrera. Usa RETURNING.
• Emparejar mal las columnas en un INSERT ... SELECT. Se emparejan por posición. Léelas dos veces.
• Insertar hijos antes que padres. is not present in table. Padres primero, siempre.
• Creer que un INSERT multifila inserta lo que puede. Es atómico: si falla una tupla, no entra ninguna.
• Confundir NULL con DEFAULT. VALUES (NULL) guarda NULL (o falla con NOT NULL); VALUES (DEFAULT) aplica el valor por omisión. Omitir la columna equivale a lo segundo.
• Escribir los decimales con coma. 12,50 no es un número en SQL: es invalid input syntax for type numeric (01-03).
• Cargar un millón de filas con INSERT. Para eso está COPY. Y si necesitas transformar, COPY a staging y luego INSERT ... SELECT.
• Copiar productos.precio en precio_unitario desde la tabla en lugar de fijarlo. El precio de la línea es el del momento de la venta; si lo enlazas al catálogo, mañana cambiarán tus facturas antiguas.
• Consejo: mira siempre el segundo número de INSERT 0 N. Es el único que te dice si ha hecho lo que esperabas.
• Consejo: usa RETURNING incluso cuando no lo necesites. Ver la fila resultante con sus DEFAULT aplicados es la forma más rápida de comprobar que el DDL hace lo que crees.
• Consejo: para datos maestros reejecutables, ON CONFLICT DO NOTHING. Convierte un script frágil en uno idempotente.

TiendaVerde incorpora un proveedor y dos productos suyos. Escribe las sentencias necesarias, en el orden correcto, cumpliendo estos requisitos:

1. Alta del proveedor Cooperativa La Safor, de España, con email [email protected], activo. Recupera su id con RETURNING.
2. Alta de dos productos suyos en una sola sentencia, ambos de la categoría Alimentación (id 1):
   • Almendra marcona ecológica 250 g, precio 7,90 €, coste 4,20 €, stock 60.
   • Naranjas de Valencia ecológicas 5 kg, precio 11,50 €, coste 6,00 €, stock 35.
   • En los dos, activo y fecha_alta deben quedar en sus valores por omisión, sin escribirlos.
3. Una consulta que muestre el proveedor nuevo con sus dos productos y el margen de cada uno.

Predice qué ocurre con cada una de estas sentencias sobre la base recién recargada, y si falla, di qué restricción se rompe y cuál sería el mensaje. Después compruébalo.

El equipo de análisis quiere una tabla de resumen mensual de ventas de 2025 para no recalcularla en cada informe.

1. Crea la tabla ventas_mensuales con: mes (texto AAAA-MM, clave primaria), pedidos (entero, obligatorio), lineas (entero, obligatorio), unidades (entero, obligatorio), facturacion (NUMERIC(10,2), obligatorio, no negativo) y fecha_calculo (DATE, obligatorio, por omisión hoy).
2. Puéblala con un INSERT ... SELECT a partir de los pedidos de 2025.
3. Comprueba el resultado y verifica que la suma de la columna facturacion coincide con la facturación de producto de 2025.

Solución 1

Tres decisiones que había que tomar bien: el orden (proveedor antes que productos, porque es el padre de la FK), una sola sentencia para los dos productos, y omitir activo y fecha_alta en lugar de escribirlos. Y un detalle: el id 6 del proveedor no se ha escrito en ningún sitio; se ha recuperado con RETURNING y se ha usado en el INSERT siguiente. En una aplicación real, ese valor viajaría en una variable.

Solución 2

a) Falla. CHECK de cantidad:

CHECK (cantidad > 0): una línea de cero unidades no es una venta. Fíjate en que descuento sí se ha rellenado con su DEFAULT 0.00 antes de comprobar la restricción.

b) Falla. UNIQUE del email:

Es la protección de la clave natural de 01-05. El id sería distinto, pero el email es único: la base impide registrar dos veces a la misma persona. Este es exactamente el escenario que resolverá el UPSERT de 05-05.

c) Funciona.

Se crea la empleada 9, con jefe_id 2 (Andrés Company Talens, que existe), salario a NULL (la columna es nulable) y ciudad a NULL. Ninguna restricción se viola: salario no es obligatorio y su CHECK (salario >= 0) da UNKNOWN con un nulo, lo que se considera satisfecho (05-01).

d) Falla. CHECK del estado:

'preparando' no está en el dominio ('pendiente','pagado','enviado','entregado','cancelado'). Observa el DETAIL: empleado_id ha quedado a NULL (pedido web) y gastos_envio ha tomado su DEFAULT 0.00. La fila estaba casi bien.

e) Falla. FOREIGN KEY:

Sobre la base recién recargada solo hay 20 pedidos. El pedido 21 es el que creamos en el apartado 11, no el que hay ahora. Es un recordatorio de por qué conviene recargar el script entre bloques de ejercicios.

Solución 3

Diez meses, 16 pedidos y 603,52 € de facturación de producto en 2025. Los otros 4 pedidos y 124,43 € corresponden a 2026: 603,52 + 124,43 = 727,95 €, la cifra canónica del módulo 4. Cuadra.

Dos observaciones sobre el diseño de esta tabla. La primera: mes como CHAR(7) en formato AAAA-MM es clave primaria natural y ordena alfabéticamente igual que cronológicamente, que es justo la razón por la que ese formato se usa tanto. La segunda, más importante: esta tabla es un agregado precalculado, es decir, desnormalización deliberada (01-05, sección 8). Su gran problema es la sincronización: si mañana entra un pedido con fecha de 2025, la tabla queda obsoleta y nadie se entera. Las soluciones —vistas materializadas y triggers— son del módulo 10.

INSERT es la puerta de entrada de los datos, y ya la dominas:

• La sintaxis INSERT INTO tabla (columnas) VALUES (...), y la regla que no admite excepciones: lista siempre las columnas. La forma sin lista depende del orden físico de la tabla y se rompe en cuanto alguien la toca.
• La salida INSERT 0 N: el 0 es una reliquia, la N es lo que importa.
• Varias filas en una sentencia, que es lo que hace el script del curso y lo que debes hacer tú: entre 10 y 50 veces más rápido, porque el coste dominante es fijo por sentencia.
• DEFAULT como valor y DEFAULT VALUES para una fila entera por omisión; y la equivalencia entre poner DEFAULT y simplemente omitir la columna.
• La columna de identidad: omitirla es lo normal, forzarla es legal con BY DEFAULT y desajusta la secuencia, y el arreglo es setval(pg_get_serial_sequence(...), MAX(id)) — que es exactamente lo que hacen las nueve líneas finales de tiendaverde.sql. Las secuencias no se deshacen con ROLLBACK: los id tienen huecos y no cuentan filas.
• RETURNING, la extensión que devuelve la fila insertada con sus valores generados, y que elimina la condición de carrera de SELECT MAX(id). Con sus equivalentes por motor: LAST_INSERT_ID(), SCOPE_IDENTITY(), OUTPUT.
• INSERT ... SELECT para poblar históricos y duplicar catálogos transformando mientras copia; las columnas se emparejan por posición.
• Los cuatro errores de un INSERT, con su mensaje literal y su tabla de diagnóstico; y el hecho de que un INSERT multifila es atómico.
• El orden de inserción: padres antes que hijos, siempre.
• COPY y \copy para carga masiva, de 5 a 20 veces más rápidos, y el patrón profesional de staging + INSERT ... SELECT.
• Y el caso completo: alta de producto y registro del pedido 21 con sus tres líneas y sus 49,45 € de total, encadenando dos INSERT con RETURNING.

Sabes crear tablas y llenarlas. Lo que aún no sabes es corregir. En la siguiente lección, Instrucción UPDATE, cambia el tono: hasta ahora, un error tuyo creaba una fila de más que podías borrar; a partir de ahora, un error tuyo puede sobrescribir veinte filas correctas y dejarte sin forma de saber qué había antes. Verás el protocolo profesional para que eso no ocurra —escribir primero el SELECT, contar las filas, y solo entonces convertirlo en UPDATE—, el hábito de trabajar con BEGIN y ROLLBACK como red de seguridad, y todo lo que UPDATE sabe hacer: varias columnas a la vez, cálculos sobre el valor anterior, actualizaciones a partir de otra tabla con FROM, y RETURNING para ver exactamente qué has cambiado.