Llevas cinco módulos leyendo el esquema de TiendaVerde sin haber escrito ni una línea de él. Sabes que clientes.email es UNIQUE, que lineas_pedido.pedido_id es ON DELETE CASCADE, que puntuacion está protegida con un CHECK de 1 a 5 y que todas las claves primarias son id INTEGER GENERATED BY DEFAULT AS IDENTITY. Lo sabes porque lo has leído en la lección 01-06 y porque los errores de PostgreSQL te lo han recordado más de una vez. Lo que no sabes todavía es cómo se declara todo eso.

Aquí empieza el otro lado del lenguaje: el DDL, el sublenguaje de definición de datos del que hablaba 01-01. En esta lección aprenderás la sintaxis completa de CREATE TABLE —columnas, tipos y las seis restricciones, una a una—, por qué conviene ponerles nombre, cómo funcionan de verdad las columnas de identidad y en qué se diferencian de los SERIAL de toda la vida, qué son las columnas generadas, cómo crear tablas temporales o a partir de una consulta, y cómo se borran respetando el orden que impone la integridad referencial. Al terminar podrás leer el script tiendaverde.sql de arriba abajo entendiendo por qué cada decisión es la que es, y podrás escribir uno tuyo.

1. Del catálogo muerto a la tienda viva
2. Anatomía de CREATE TABLE
3. Las restricciones, una a una
4. A nivel de columna o a nivel de tabla
5. Nombrar las restricciones y por qué importa
6. Columnas de identidad: IDENTITY, SERIAL y el resto de motores
7. Columnas generadas
8. IF NOT EXISTS, CREATE TABLE AS SELECT y tablas temporales
9. DROP TABLE y el orden que impone la integridad referencial
10. Recorrido comentado del DDL de TiendaVerde
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

El módulo 4 se cerró con una frase: "una tienda que no puede dar de alta un producto, registrar un pedido, corregir un precio ni cancelar una compra no es una tienda: es un catálogo muerto". Cruzar al otro lado empieza aquí, y empieza por lo más básico: antes de poder insertar una fila hay que tener dónde ponerla.

Un recordatorio de 01-01 sobre los cinco sublenguajes de SQL, ahora con el módulo 5 situado en el mapa:

Y un cambio de mentalidad que conviene interiorizar ya: el DDL define las reglas que la base de datos hará cumplir por ti. Cada NOT NULL, cada CHECK, cada FOREIGN KEY que escribas es un error que tu aplicación no podrá cometer nunca, ni hoy ni dentro de tres años, ni desde el código, ni desde un script, ni desde una consola abierta a las tres de la mañana. Es la diferencia entre confiar en que todo el mundo se acuerde de validar y que sea imposible no validar.

La forma general:

Empecemos por la tabla más simple de TiendaVerde, categorias, tal cual está en el script del curso:

Tres columnas y cuatro decisiones ya tomadas:

Fíjate en que descripcion no lleva NULL explícito. En SQL, una columna admite nulos salvo que digas lo contrario. Escribir descripcion TEXT NULL es legal y significa exactamente lo mismo; el curso no lo hace porque añade ruido.

Dentro de psql, \d te devuelve la definición real tal como la ve el motor:

Esa salida es tu mejor herramienta de diagnóstico durante todo el módulo. Te dice los tipos, si admiten nulos, los valores por omisión, los índices que respaldan la PK y el UNIQUE, y qué otras tablas dependen de esta. Cógele cariño.

SQL tiene seis restricciones declarativas. Estas son, en orden de menor a mayor alcance:

La más simple y la más olvidada.

Cualquier INSERT o UPDATE que deje esa columna sin valor se rechaza:

La decisión de si una columna admite nulos no es técnica, es de negocio, y ya la tomaste conceptualmente en 04-03. En TiendaVerde:

Regla práctica: declara NOT NULL por defecto y admite nulos solo cuando tengas una respuesta clara a la pregunta "¿qué significa que aquí no haya nada?". Una columna nulable sin semántica documentada es una fuente garantizada de bugs.

El valor que se usa si el INSERT no menciona la columna:

Los tres casos que verás en la práctica:

Ese matiz de la función es importante y confunde a mucha gente: DEFAULT CURRENT_DATE no congela la fecha en que creaste la tabla. Cada fila recibe la fecha del día en que se insertó.

Y las tres columnas omitidas (activo, fecha_alta y la propia id) se rellenan con sus valores por omisión. DEFAULT es lo que hace que un INSERT corto siga produciendo una fila completa y coherente.

DEFAULT no es una restricción. No impide nada: solo rellena huecos. Si insertas NULL explícitamente en una columna con DEFAULT, se guarda NULL (o falla, si hay NOT NULL). El DEFAULT solo actúa cuando omites la columna.

Marca la columna —o el conjunto de columnas— que identifica cada fila. Implica UNIQUE y NOT NULL a la vez, y solo puede haber una por tabla.

Forma simple, a nivel de columna:

Forma compuesta, obligatoriamente a nivel de tabla, porque afecta a varias columnas:

Se lee: "un producto no puede llevar dos veces la misma etiqueta". La PK compuesta es la regla de negocio; no hace falta ningún UNIQUE adicional.

Esta era exactamente la alternativa que 01-05 planteó para lineas_pedido y que TiendaVerde no eligió:

Habría significado "un producto solo puede aparecer una vez en cada pedido", y eso impediría facturar dos líneas del mismo producto con descuentos distintos. Por eso lineas_pedido tiene su propio id.

Impide valores repetidos. A diferencia de PRIMARY KEY, puedes tener tantos como quieras y sí admite nulos.

Al intentar registrar dos veces el mismo email:

Único compuesto, a nivel de tabla:

Ojo con la semántica del UNIQUE compuesto: prohíbe repetir la combinación, no cada columna por separado. El mismo cliente puede reseñar veinte productos y el mismo producto puede recibir veinte reseñas; lo que no puede haber es dos filas con el mismo par.

UNIQUE y los NULL: retomando 04-03

Aquí vuelve la lógica de tres valores. Como NULL no es igual a NULL, una columna UNIQUE puede contener muchas filas nulas:

Tres nulos conviven sin problema en una columna UNIQUE, mientras que un segundo 'A' habría fallado. Desde PostgreSQL 15 puedes cambiar ese comportamiento:

Con eso, el segundo NULL daría error. Es útil cuando el nulo significa "sin código" y quieres que solo pueda haber una fila así.

Nota de dialecto: este comportamiento no es universal. PostgreSQL, Oracle y SQLite permiten varios nulos en una columna única; SQL Server permite solo uno (trata todos los NULL como iguales a efectos del índice único). Si migras un esquema entre motores, es una de las trampas más silenciosas.

Y una nota que verás desarrollada en el módulo 8: tanto PRIMARY KEY como UNIQUE se implementan creando un índice por debajo. Por eso son restricciones baratas de comprobar y por eso ocupan espacio en disco. Las estructuras y el coste, en su momento.

Restringe los valores admisibles con una expresión booleana. Es la restricción más expresiva y la más infrautilizada.

TiendaVerde usa seis tipos de CHECK. Estos son los reales del script:

Cada uno protege una regla que el tipo por sí solo no garantiza. SMALLINT admite 7 y admite −3; el CHECK es lo que impide una reseña de 7 estrellas. NUMERIC(4,2) admite 99.99; el CHECK es lo que impide un descuento del 9999 %.

Un CHECK con más de una columna debe declararse a nivel de tabla, porque a nivel de columna solo puede referirse a la suya:

Fíjate en el coste IS NULL OR. Sin él, la restricción sería inútil de una forma sutil: NULL <= precio da UNKNOWN, y un CHECK que da UNKNOWN se considera satisfecho. Es la regla que más sorprende de los CHECK:

Es decir, CHECK deja pasar los nulos salvo que los prohíbas expresamente. Si quieres exigir valor, eso es trabajo de NOT NULL, no del CHECK.

Qué no puede hacer un CHECK:

• No puede consultar otras tablas. CHECK (precio > (SELECT AVG(precio) FROM productos)) no es válido: PostgreSQL rechaza subconsultas en un CHECK. Para reglas entre tablas están las claves foráneas y, si no bastan, los triggers del módulo 10.
• No puede usar funciones no deterministas. CHECK (fecha_alta <= CURRENT_DATE) está desaconsejado y PostgreSQL lo permite pero avisa en la documentación: una fila válida hoy podría dejar de serlo mañana, y una restauración de copia de seguridad fallaría sin motivo aparente.

La restricción que conecta las tablas y garantiza la integridad referencial de 01-05. Tiene dos sintaxis equivalentes:

La forma completa:

Y las cinco acciones posibles, ya conocidas de 01-05, ahora con su sintaxis:

La distinción NO ACTION / RESTRICT es sutil y casi siempre irrelevante: NO ACTION permite que otra parte de la misma sentencia arregle la situación antes de la comprobación final; RESTRICT no. En la práctica, ambos se traducen en "no me dejes hacerlo".

Aplicado al esquema real:

Dos FK en la misma tabla con acciones opuestas, y las dos correctas: una línea no existe sin su pedido (CASCADE), pero un producto vendido no debe poder borrarse jamás (RESTRICT), porque destruiría el histórico de facturación.

Sobre ON UPDATE: se dispara cuando cambia la clave primaria del padre. Con claves subrogadas no se usa nunca, porque un id autoincremental no cambia. Es precisamente una de las ventajas de las claves subrogadas que 01-05 enumeraba. Si tu PK fuera natural (un código de artículo, un NIF), ON UPDATE CASCADE pasaría a ser imprescindible.

Once claves foráneas, cuatro CASCADE, tres SET NULL y cuatro RESTRICT. Verás las tres acciones en funcionamiento, con recuentos antes y después, en la lección 05-04.

Todas las restricciones salvo NOT NULL y DEFAULT se pueden escribir de dos formas.

A nivel de columna, justo detrás del tipo:

A nivel de tabla, al final, como elementos separados por comas:

Cuándo usar cada una:

Si no le pones nombre, PostgreSQL genera uno siguiendo un patrón fijo:

Por eso todos los errores que has ido viendo en el curso tienen esa forma: categorias_nombre_key, resenas_puntuacion_check, pedidos_cliente_id_fkey.

El patrón funciona bien mientras hay una restricción por columna. En cuanto hay dos, PostgreSQL empieza a numerar:

demo_nombres_precio_check1. ¿Cuál de las dos era? Imposible saberlo sin mirar la definición. Y ahora imagina ese nombre en un mensaje de error, a las once de la noche, en un log de producción.

La versión con nombres explícitos:

Y el error deja de ser un jeroglífico:

Aplicado a TiendaVerde, la tabla pedidos quedaría así:

Las tres razones por las que merece la pena esa verbosidad:

1. Mensajes de error legibles. chk_pedidos_estado te dice qué regla has roto sin abrir el esquema.
2. Migraciones. Para quitar o modificar una restricción hay que nombrarla: ALTER TABLE pedidos DROP CONSTRAINT chk_pedidos_estado; (lección 05-06). Con nombres autogenerados, cada migración empieza con una búsqueda arqueológica en information_schema.
3. Portabilidad y reproducibilidad. Dos entornos creados con scripts ligeramente distintos pueden acabar con ..._check y ..._check1 intercambiados. Los nombres explícitos eliminan esa lotería.

Una convención de nombres razonable y muy extendida:

Por qué el script del curso no los usa. tiendaverde.sql prescinde de los nombres explícitos deliberadamente: así los mensajes de error que ves en las lecciones son los que PostgreSQL genera de fábrica, que es lo que te encontrarás al conectarte a cualquier base de datos ajena. En un proyecto tuyo, nómbralas.

Todas las PK de TiendaVerde son así:

Detrás hay una secuencia: un objeto del motor que va entregando números crecientes. Cuando insertas sin indicar id, PostgreSQL pide el siguiente valor a la secuencia.

Son dos variantes con una diferencia importante:

Con ALWAYS:

TiendaVerde usa BY DEFAULT justamente porque su script de carga inserta los id a mano (INSERT INTO categorias (id, nombre, ...) VALUES (1, ...)), y eso permite que los ejemplos del curso hablen del "cliente 7" o del "pedido 12" con ids estables y reproducibles. El precio de esa comodidad es el bloque de setval del final del script, que verás explicado en 05-02.

Si el id de tu tabla no se va a fijar nunca a mano, GENERATED ALWAYS es más seguro: elimina de raíz la posibilidad de desajustar la secuencia.

Antes de PostgreSQL 10 no existía IDENTITY y se usaba el pseudotipo SERIAL:

SERIAL no es un tipo real: es azúcar sintáctico que PostgreSQL expande a tres cosas:

Sabrás reconocer SERIAL en cualquier esquema antiguo; escribe IDENTITY en el tuyo.

Es una de las divergencias más grandes entre dialectos:

Nota de dialecto: si escribes DDL que deba funcionar en varios motores, la columna de identidad será casi siempre lo primero que tengas que bifurcar. Es una de las razones por las que las herramientas de migración del apartado final de 05-06 existen.

Una columna generada es una columna cuyo valor se calcula a partir de otras columnas de la misma fila. No se inserta ni se actualiza: el motor la mantiene.

Ahora la expresión que llevas escribiendo desde 02-02 —cantidad * precio_unitario * (1 - descuento)— vive en el esquema, no en cada consulta:

Y si intentas escribir en ella:

Reglas de las columnas generadas en PostgreSQL 16:

• Deben ser STORED (se guardan en disco). Las VIRTUAL (calculadas al leer) aún no están soportadas.
• La expresión debe ser inmutable: solo columnas de la misma fila y funciones deterministas. Nada de CURRENT_DATE, ni subconsultas, ni otras tablas.
• No puede tener DEFAULT ni ser columna de identidad.

Es una decisión de diseño con argumentos en ambos sentidos:

TiendaVerde no la usa, por dos razones didácticas y una práctica: escribir la expresión a mano es exactamente lo que te ha enseñado a pensar en importes durante tres módulos; el descuento como fracción ya es una decisión de diseño explicada; y con 47 filas el ahorro sería cero. En un sistema real con millones de líneas y una decena de aplicaciones consultando, la balanza se inclina claramente a favor.

Nota de dialecto: las columnas generadas son bastante portables. MySQL 5.7+ las tiene con GENERATED ALWAYS AS (...) STORED | VIRTUAL; SQLite 3.31+ igual; SQL Server las llama computed columns (AS expresión [PERSISTED]); Oracle usa GENERATED ALWAYS AS (...) VIRTUAL. La sintaxis varía poco, pero quién soporta VIRTUAL sí varía, y PostgreSQL es de los que no.

Evita el error si la tabla ya existe:

Es un aviso, no un error, y la sentencia se da por buena. Suena cómodo, pero úsalo con cuidado: si la tabla existe con una definición distinta, IF NOT EXISTS no la corrige, la ignora en silencio. Para scripts de creación desde cero, DROP TABLE IF EXISTS seguido de CREATE TABLE (lo que hace tiendaverde.sql) es más honesto: garantiza que la estructura resultante es exactamente la que has escrito. Para migraciones de verdad, ninguna de las dos: fichero versionado y ALTER TABLE (lección 05-06).

Crea una tabla a partir del resultado de una consulta, deduciendo columnas y tipos:

La salida no es CREATE TABLE, es SELECT 7: te está diciendo cuántas filas ha copiado.

Lo que CTAS copia y lo que no, y esto es la fuente de disgustos número uno:

Es decir: productos_caros.id no es clave primaria y admite duplicados y nulos. CTAS crea un contenedor de datos, no una tabla bien definida. Sus usos legítimos son tres: copias de seguridad rápidas antes de un UPDATE peligroso (verás justamente eso en 05-03), tablas intermedias de análisis, y materializar el resultado de una consulta costosa.

Si solo quieres la estructura, sin datos:

Y si lo que quieres es una copia con las restricciones, la instrucción es otra:

LIKE ... INCLUDING ALL sí copia valores por omisión, restricciones, índices e identidad —pero no los datos ni las claves foráneas—. Es lo más parecido a "clonar la tabla" que ofrece PostgreSQL.

Una tabla temporal existe solo dentro de tu sesión y desaparece al desconectarte:

Propiedades que la hacen útil:

• Aislada: otra sesión no la ve, y puede tener una tabla temporal con el mismo nombre sin interferir.
• Efímera: se borra al cerrar la sesión, o al terminar la transacción si añades ON COMMIT DROP.
• Oculta la tabla real: si creas una TEMP TABLE productos, tus consultas pasarán a leer la temporal. Muy práctico para pruebas; muy peligroso si se te olvida.

Para trabajos de un solo paso, las CTE del módulo 10 suelen ser mejores. Las temporales brillan cuando necesitas releer el resultado intermedio varias veces.

• RESTRICT (por omisión): falla si algún otro objeto depende de la tabla.
• CASCADE: borra también los objetos dependientes (restricciones de otras tablas, vistas...).
• IF EXISTS: no protesta si la tabla no existe.

Intenta borrar categorias con TiendaVerde cargada:

productos.categoria_id la referencia. Con CASCADE:

Lee bien ese NOTICE: no ha borrado la tabla productos, ha borrado su restricción de clave foránea. DROP TABLE ... CASCADE elimina las dependencias, no las tablas hijas. Aun así, el resultado es que productos se queda sin la barrera que protegía su categoria_id, lo cual casi nunca es lo que querías.

La integridad referencial impone un orden estricto, y es la razón de la estructura de tiendaverde.sql:

Por eso el script del curso empieza así:

Nueve DROP en orden inverso al de creación, con IF EXISTS (para que funcione la primera vez, cuando no hay nada) y con CASCADE (por si el orden fallara). Es lo que hace el script idempotente: puedes ejecutarlo cien veces y siempre dejará la base en el mismo estado.

También podrías escribirlo en una sola sentencia, que resuelve el orden sola:

Aviso. DROP TABLE es irreversible en cuanto confirmas la transacción y no pregunta. En PostgreSQL puedes protegerte con BEGIN; ... ROLLBACK;, porque su DDL es transaccional (lección 05-06); en MySQL, no. Y hay un caso especial de las relaciones reflexivas: clientes.referido_por_id y empleados.jefe_id apuntan a su propia tabla, así que ninguna tabla externa las bloquea, pero un DROP de clientes sin CASCADE seguirá fallando por pedidos y resenas.

Ahora sí: el script de 01-06, leído con todo lo aprendido. Estas son las decisiones y su porqué.

empleados sigue el mismo patrón con jefe_id, y con un detalle extra: salario NUMERIC(10,2) CHECK (salario >= 0) es nulable, porque en la práctica no todo el mundo tiene acceso a ese dato.

Ya la has visto entera en el apartado 3.6. Solo un recordatorio de por qué precio_unitario está ahí duplicando productos.precio: no es redundancia, son datos distintos. Uno es el precio actual del catálogo, el otro el precio facturado. Las líneas 1 y 4 del conjunto de datos lo demuestran: 11,95 € y 17,50 € frente a los 12,50 € y 18,90 € de hoy. Es la desnormalización deliberada de 01-05, sección 8.

Aquí hay una decisión que conviene mirar de frente: resenas no tiene ninguna restricción que garantice que el cliente haya comprado ese producto, ni que impida que reseñe dos veces lo mismo. Lo comprobaste en el ejercicio 3 de 01-06: insertar una reseña del cliente 14 sobre un producto que nunca compró funciona.

Es intencionado, y encierra una lección importante: una restricción declarativa solo puede mirar la fila que se está insertando y, como mucho, la existencia de la clave en otra tabla. "Este cliente compró este producto" exige recorrer pedidos y lineas_pedido, y eso no cabe en un CHECK ni en una FOREIGN KEY. Necesitarías un trigger (módulo 10) o lógica de aplicación.

La regla: la base de datos protege las invariantes estructurales; la aplicación protege las reglas de proceso. Confundir ambas cosas lleva o bien a esquemas ingenuos, o bien a esquemas imposibles de mantener.

• Olvidar el NOT NULL. Una columna sin él admite nulos, y descubrirlo en producción con un AVG que devuelve un número raro es caro. Declara NOT NULL por defecto y justifica cada excepción.
• Usar FLOAT o REAL para dinero. 0.1 + 0.2 no da 0.3 en coma flotante. Siempre NUMERIC(10,2) (01-04).
• Creer que un CHECK impide los nulos. Un CHECK que da UNKNOWN se acepta. Si necesitas valor, es NOT NULL; si necesitas cubrir el nulo dentro del CHECK, escribe col IS NULL OR ....
• Poner ON DELETE SET NULL en una columna NOT NULL. La tabla se crea, pero el primer borrado del padre falla con null value ... violates not-null constraint. Las dos declaraciones son incompatibles en el momento de la verdad.
• Usar CASCADE por comodidad. Un DELETE puede propagarse por media base de datos en silencio. Resérvalo para composición real (05-04).
• No nombrar las restricciones. Funciona hasta la primera migración; después, cada DROP CONSTRAINT empieza con una búsqueda en information_schema.
• Crear tablas en orden alfabético. El orden lo manda la integridad referencial: padres antes que hijos, y al revés para borrar.
• Confiar en CREATE TABLE AS SELECT como copia fiel. No copia PK, ni UNIQUE, ni CHECK, ni FK, ni identidad, ni índices. Para eso está LIKE ... INCLUDING ALL.
• Confundir CREATE TABLE IF NOT EXISTS con una migración. Si la tabla existe con otra estructura, la ignora en silencio y te deja dos entornos distintos.
• Consejo: escribe el DDL en un fichero versionado, nunca a mano en la consola. Es el germen de las migraciones de 05-06 y la única forma de que dos entornos sean iguales.
• Consejo: \d tabla antes de escribir cualquier INSERT. Te ahorra la mitad de los errores del módulo.
• Consejo: prueba tus restricciones. Escribe un INSERT que deba fallar y comprueba que falla. Una restricción que nunca has visto saltar puede no estar haciendo lo que crees.
• Consejo: indexa las claves foráneas. PostgreSQL indexa la PK y los UNIQUE, pero no las FK. Sin ese índice los JOIN y los borrados en cascada se arrastran (módulo 8).

TiendaVerde quiere lanzar un programa de cupones de descuento. Escribe el CREATE TABLE de la tabla cupones con estos requisitos, usando restricciones con nombre explícito:

• id entero, clave primaria generada por el motor, sin poder forzarse a mano.
• codigo texto de hasta 20 caracteres, obligatorio y único.
• descripcion texto libre opcional.
• descuento fracción entre 0.01 y 0.50, obligatoria (mismo criterio que lineas_pedido.descuento).
• fecha_inicio y fecha_fin, ambas obligatorias, con fecha_fin posterior o igual a fecha_inicio.
• usos_maximos entero opcional; si tiene valor, debe ser mayor que 0.
• usos_actuales entero obligatorio, con valor por omisión 0 y nunca negativo.
• cliente_id opcional: si el cupón es nominal, apunta a un cliente; si ese cliente se borra, el cupón debe quedar sin titular en lugar de desaparecer.
• activo booleano obligatorio, por omisión cierto.

Para cada una de estas seis afirmaciones, di si es verdadera o falsa y justifícalo en una frase. Si puedes, compruébalo ejecutándolo.

1. Una columna UNIQUE no puede contener dos filas con NULL en PostgreSQL.
2. PRIMARY KEY (pedido_id, producto_id) permite que un producto aparezca dos veces en el mismo pedido.
3. CHECK (coste <= precio) rechaza una fila con coste a NULL.
4. DEFAULT CURRENT_DATE guarda la fecha en que se creó la tabla.
5. CREATE TABLE copia AS SELECT * FROM productos produce una tabla con la misma clave primaria.
6. Con GENERATED ALWAYS AS IDENTITY, el script de carga de TiendaVerde funcionaría igual.

Este DDL tiene cinco problemas. Encuéntralos, explica qué consecuencia tiene cada uno y reescribe la tabla corregida.

Solución 1

Los cuatro puntos que había que acertar:

Solución 2

Solución 3

Los cinco problemas:

Y de propina, dos mejoras que no son errores pero sí malos hábitos: SERIAL en obra nueva y ninguna restricción con nombre.

Ya sabes escribir el esquema que llevabas cinco módulos leyendo:

• CREATE TABLE declara columnas con su tipo y sus restricciones, a nivel de columna (una sola columna) o a nivel de tabla (varias, obligatoriamente).
• Las seis restricciones: NOT NULL (obligatoriedad), DEFAULT (relleno, no restricción, evaluado en cada inserción), CHECK (dominio de una fila, y acepta los nulos porque UNKNOWN se da por bueno), UNIQUE (que sí admite varios NULL en PostgreSQL, retomando 04-03), PRIMARY KEY (simple o compuesta) y FOREIGN KEY con sus ON DELETE / ON UPDATE.
• Nombrar las restricciones (CONSTRAINT chk_pedidos_estado ...) convierte pedidos_estado_check1 en un mensaje de error legible y hace posibles las migraciones de 05-06.
• Las columnas de identidad: GENERATED BY DEFAULT (permite forzar el id, y por eso la usa TiendaVerde) frente a GENERATED ALWAYS (más seguro), frente al antiguo SERIAL; y las cuatro sintaxis incompatibles de MySQL, SQLite, SQL Server y Oracle.
• Las columnas generadas (GENERATED ALWAYS AS (...) STORED) pueden meter en el esquema la fórmula del importe de línea, con sus ventajas y su coste.
• IF NOT EXISTS (que ignora en silencio una definición distinta), CTAS (que copia datos pero ninguna restricción) y CREATE TEMP TABLE (aislada y efímera).
• DROP TABLE con RESTRICT/CASCADE, y el orden que impone la integridad referencial: crear de padres a hijos, borrar de hijos a padres. Es la estructura exacta de tiendaverde.sql y la razón de que sea idempotente.
• Y el recorrido comentado del esquema real, con la frontera bien marcada: la base de datos protege las invariantes estructurales; las reglas de proceso —"solo puede reseñar quien compró"— son de la aplicación o de un trigger del módulo 10.

Ya tienes dónde poner los datos. En la siguiente lección, Instrucción INSERT, empezarás a ponerlos: por qué hay que listar siempre las columnas, cómo insertar cuarenta filas en una sola sentencia, qué hace realmente el bloque de setval del final del script del curso, cómo recuperar con RETURNING el id que acaba de generar el motor —la pieza que te faltaba para registrar un pedido y sus líneas—, cómo insertar el resultado de una consulta con INSERT ... SELECT, y qué significa exactamente cada uno de los cuatro errores que un INSERT puede darte.