Los esquemas cambian. Siempre. Hace falta guardar el teléfono de los clientes, el VARCHAR(60) se queda corto, alguien se dio cuenta de que aquella columna se llamaba mal, marketing quiere una columna total en pedidos para no recalcularla en cada informe, y una regla de negocio que hasta ahora vivía en el código debería estar en un CHECK. La base de datos que creaste en 05-01 y llenaste en 05-02 no es un monumento: es un organismo en producción que va a mutar decenas de veces.

ALTER TABLE es la instrucción que lo permite. Su sintaxis se aprende en veinte minutos. Lo que separa a un profesional de un accidente no es la sintaxis: es saber qué operaciones bloquean la tabla y cuáles no, entender que en PostgreSQL una migración se puede deshacer con ROLLBACK y en MySQL no, conocer el patrón que permite cambiar un esquema sin parar el servicio, y aceptar la regla que rige toda la industria: ningún cambio de estructura se escribe a mano en una consola de producción.

Esta lección cubre las dos mitades, y cierra el módulo.

⚠️ Aviso de seguridad

ALTER TABLE es una operación destructiva e irreversible en sus efectos sobre los datos. Un DROP COLUMN elimina una columna entera y todo su contenido; un ALTER COLUMN TYPE puede truncar valores; un ADD CONSTRAINT puede rechazar filas existentes.

• Ejecuta todos los ejemplos sobre tu base de datos de prácticas (tiendaverde), nunca en producción.
• Haz una copia de seguridad previa: pg_dump -U curso_sql -d tiendaverde -f copia.sql.
• Trabaja dentro de BEGIN … ROLLBACK: en PostgreSQL el DDL es transaccional y puedes deshacerlo.
• En un sistema real, todo cambio de esquema debe ir revisado por el responsable de la base de datos, probado antes en un entorno equivalente al de producción y aplicado como migración versionada, nunca a mano.

1. ALTER TABLE: el mapa de operaciones
2. ADD COLUMN, con y sin DEFAULT
3. DROP COLUMN
4. RENAME COLUMN y RENAME TO
5. ALTER COLUMN TYPE y la cláusula USING
6. SET / DROP NOT NULL y SET / DROP DEFAULT
7. ADD / DROP CONSTRAINT, y la técnica NOT VALID + VALIDATE
8. Qué bloquea la tabla y qué no
9. DDL transaccional: PostgreSQL frente a MySQL
10. El patrón expand/contract
11. Migraciones versionadas
12. Qué hacer y qué no hacer en producción
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión del módulo

Las acciones más habituales:

Un detalle de sintaxis que ahorra mucho tiempo: varias acciones caben en una sola sentencia, separadas por comas. Y eso no es solo elegancia — es que la tabla se bloquea una vez en lugar de N:

Aviso sobre los objetos de esta lección. clientes.telefono, clientes.newsletter y pedidos.total son ejemplos puntuales: no forman parte del esquema canónico de TiendaVerde y no aparecerán en los módulos siguientes. Recarga tiendaverde.sql al terminar.

(Recarga tiendaverde.sql antes de seguir: los ejemplos de este apartado vuelven a añadir las dos columnas del anterior, esta vez una a una.)

La columna nace nulable y todas las filas existentes quedan con NULL. Es instantáneo independientemente del tamaño de la tabla: PostgreSQL solo anota la nueva columna en su catálogo, sin tocar un solo byte de datos.

Las quince filas tienen FALSE. Y aquí está una de las mejoras más importantes de PostgreSQL de la última década:

Desde PostgreSQL 11, añadir una columna con DEFAULT constante ya no reescribe la tabla. Antes, esta operación recorría y reescribía cada fila para grabar el valor: en una tabla de cien millones de filas eran horas de bloqueo exclusivo — el caso de estudio clásico de "cómo tumbar producción con una línea de SQL".

Ahora PostgreSQL guarda el valor por omisión en el catálogo y lo devuelve "al vuelo" para las filas antiguas, escribiéndolo físicamente solo cuando esas filas se actualizan por otro motivo. La operación pasa de horas a milisegundos.

La excepción, que sigue siendo cara:

Si el DEFAULT no es constante —una función aleatoria, un NOW() que debe diferir por fila— cada fila necesita su propio valor y no hay atajo posible. La regla:

Nota de dialecto: MySQL 8 con InnoDB permite ADD COLUMN con ALGORITHM=INSTANT en muchos casos (columna al final de la tabla, sin cambio de formato de fila); si no, reconstruye. Oracle tiene una optimización equivalente desde 11g. SQLite añade columnas al final de forma barata pero no permite añadirlas con un DEFAULT no constante. SQL Server distingue entre añadir una columna nulable (instantáneo) y una NOT NULL con DEFAULT (instantáneo desde 2012 Enterprise, reescritura en el resto de ediciones).

También es instantáneo: PostgreSQL no borra los datos, marca la columna como eliminada en el catálogo y deja de mostrarla. El espacio se recupera cuando cada fila se reescribe (por un UPDATE o por un VACUUM FULL).

Eso tiene dos implicaciones que conviene conocer:

1. El dato sigue físicamente en disco hasta que se reescriba la fila. Si la columna contenía información sensible, un DROP COLUMN no es un borrado seguro.
2. La operación es irreversible desde SQL una vez confirmada. No hay UNDROP.

Si algo depende de la columna (una restricción, una vista, un índice), DROP COLUMN falla:

Con CASCADE se lleva por delante lo que dependa:

Y con eso acabas de destruir la columna más importante del catálogo y su restricción. CASCADE en ALTER TABLE merece el mismo respeto que en DELETE.

Ambas son puramente de catálogo: instantáneas, sin tocar datos, y reversibles con otro RENAME.

Y ambas son, en un sistema con aplicaciones conectadas, de las operaciones más peligrosas que existen. El motivo no es técnico: es que en el instante en que confirmas el cambio, todo el código que menciona el nombre antiguo deja de funcionar:

Un ALTER TABLE de dos segundos ha roto la aplicación entera. Y no hay ventana de transición: o el código usa el nombre viejo, o usa el nuevo.

La regla: un RENAME en producción nunca se hace de golpe. Se hace con el patrón expand/contract del apartado 10, o no se hace. Y si el nombre es feo pero funciona, muchas veces la respuesta correcta es dejarlo feo.

Deshacemos los dos cambios antes de seguir:

Ampliar la precisión de un NUMERIC funciona directamente, porque todos los valores existentes caben en el tipo nuevo. Lo mismo ocurre al pasar de VARCHAR(60) a VARCHAR(120) o a TEXT: PostgreSQL reconoce esos casos como compatibles a nivel binario y no reescribe nada.

Reducir, en cambio, puede fallar:

Y esto es una buena noticia: PostgreSQL comprueba todas las filas antes de aplicar el cambio, y si una sola no cabe, aborta sin tocar nada. Nunca trunca en silencio.

Nota de dialecto: MySQL, según su modo SQL, sí puede truncar en silencio al reducir un VARCHAR. Con sql_mode en STRICT_TRANS_TABLES (el valor por omisión desde MySQL 5.7) da error; con el modo relajado, recorta el texto y emite un aviso que casi nadie lee. Es una de las diferencias de comportamiento más peligrosas entre motores.

Cuando la conversión no es automática, PostgreSQL te lo dice y te ofrece la salida:

Un intento directo de convertir el texto a fecha:

USING recibe una expresión que calcula el valor nuevo a partir del antiguo, fila a fila:

USING admite cualquier expresión, no solo conversiones. Por ejemplo, para pasar lineas_pedido.descuento de fracción (0.10) a porcentaje entero (10):

Tres avisos sobre ALTER COLUMN TYPE:

Falla si hay filas con NULL… salvo que en TiendaVerde todos los clientes tengan ciudad, que es el caso. Probemos con una que sí tiene nulos:

Los diez pedidos web lo impiden, y correctamente: ese NULL significa algo (04-03).

La operación inversa siempre funciona, porque relajar una restricción nunca puede invalidar datos existentes:

Los valores por omisión funcionan igual, y son puro catálogo:

Cambiar el DEFAULT no afecta a las filas existentes. Solo cambia lo que se rellenará en las inserciones futuras. Es un error clásico esperar lo contrario.

Aquí se cobra la insistencia de 05-01 en nombrar las restricciones: para quitar una hay que nombrarla, y no puedes nombrar lo que no sabes cómo se llama.

Funciona porque ninguno de los 20 productos tiene un coste superior a su precio. Si lo hubiera, PostgreSQL rechazaría el ALTER TABLE entero:

Quitarla:

Y las otras tres familias:

Añadir un CHECK o una FOREIGN KEY obliga a PostgreSQL a comprobar todas las filas existentes, y lo hace con un bloqueo exclusivo. En una tabla de diez millones de filas eso puede ser un minuto largo durante el cual nadie puede leer ni escribir.

La solución en dos tiempos:

Qué hace exactamente NOT VALID:

Es decir: NOT VALID te da la protección hacia el futuro de inmediato, y deja la comprobación del histórico para un momento tranquilo. Es la técnica estándar para añadir restricciones a tablas grandes en producción.

Y comprobar qué restricciones están sin validar:

Deshacemos el ejemplo:

Este es el apartado que separa una migración inocua de una caída de producción.

PostgreSQL protege cada operación con un nivel de bloqueo. El más agresivo es ACCESS EXCLUSIVE: mientras se mantiene, ninguna otra sesión puede ni siquiera leer la tabla. Todas las consultas se quedan esperando.

Y ahora lo verdaderamente importante, que casi nadie explica:

Una operación "instantánea" no es inofensiva si no consigue el bloqueo.

Un ALTER TABLE ADD COLUMN tarda un milisegundo… una vez que ha obtenido el ACCESS EXCLUSIVE. Si en ese momento hay una consulta larga leyendo la tabla, el ALTER se pone a esperar. Y mientras espera, PostgreSQL encola detrás de él a todas las consultas nuevas, porque los bloqueos se conceden por orden de llegada.

Un ALTER TABLE de un milisegundo acaba de dejar la tabla inaccesible cinco minutos. La protección estándar:

Si en tres segundos no consigue el bloqueo, aborta con canceling statement due to lock timeout en lugar de bloquear la base. Se reintenta más tarde. Poner lock_timeout en toda migración es una de las prácticas más rentables que existen.

Esta es una diferencia crítica entre motores, y cambia por completo cómo se escribe una migración.

En PostgreSQL, el DDL es transaccional:

Como si nunca hubiera pasado. Los dos ALTER TABLE se han deshecho.

La consecuencia práctica es enorme: en PostgreSQL puedes envolver una migración de quince pasos en BEGIN … COMMIT y tener la garantía de que o se aplica entera o no se aplica nada. Si el paso 12 falla, el esquema queda exactamente como estaba.

En MySQL y Oracle, cada sentencia DDL confirma implícitamente la transacción en curso. Si una migración de quince pasos falla en el doce, los once primeros ya están aplicados y no hay forma de deshacerlos. Por eso en esos motores toda migración necesita su script de reversión escrito a mano, y por eso las herramientas del apartado 11 insisten tanto en el concepto de down migration.

Si trabajas con MySQL, interioriza esto: no existe la red de seguridad. Cada paso de la migración debe ser reversible por sí solo, y el orden importa muchísimo más.

Cómo se cambia un esquema sin parar el servicio.

El problema de fondo: la base de datos y la aplicación se despliegan por separado, y durante un rato conviven la versión antigua y la nueva del código. Cualquier cambio que rompa a una de las dos provoca errores. Un RENAME COLUMN, como viste, rompe la versión antigua en el instante en que se confirma.

Expand/contract (también llamado parallel change) resuelve esto descomponiendo el cambio en cinco fases, cada una compatible hacia adelante y hacia atrás:

La clave es que en ningún momento existe un estado en el que la aplicación pueda fallar: entre la fase 1 y la 5, ambas versiones del código funcionan.

TiendaVerde calcula el total de cada pedido sumando sus líneas y añadiendo los portes. Es correcto (01-05 lo justificaba: nada de agregados precalculados), pero los informes del módulo 4 repiten esa expresión una y otra vez, y con volumen alto el coste se nota. Dirección pide una columna total desnormalizada.

Fase 1 — Expand: añadir la columna, nulable.

Instantáneo, nulable, sin DEFAULT. El código antiguo sigue funcionando: no sabe que la columna existe y no la necesita.

Fase 2 — Doble escritura. Se despliega una versión de la aplicación que, además de crear el pedido y sus líneas, rellena total. Los pedidos nuevos tienen valor; los antiguos siguen a NULL. Ningún cambio de esquema en esta fase — es puro despliegue de código.

Fase 3 — Backfill: rellenar hacia atrás.

Con las herramientas de este módulo, sin subconsultas, en dos pasos:

Fíjate en el AND pe.total IS NULL: hace el UPDATE idempotente (05-03) y, sobre todo, garantiza que el backfill no pisa los valores que la fase 2 ya está escribiendo en tiempo real. Es el detalle que convierte un backfill peligroso en uno seguro.

En una tabla real el backfill se haría por lotes —WHERE total IS NULL AND id BETWEEN 1 AND 10000, repetido— para no mantener una transacción gigante bloqueando filas.

Fase 4 — Cambiar la lectura, y verificar.

Antes de que los informes empiecen a usar la columna nueva, hay que comprobar que coincide con el cálculo en vivo:

(8 primeras de 20 filas.)

Y la comprobación global, que es la que de verdad importa:

846,20 €: exactamente la cifra canónica del módulo 4 (727,95 € de producto + 118,25 € de portes). Veinte pedidos, ninguno sin rellenar. El backfill es correcto.

En esta fase, lo profesional es dejar la comparación funcionando unos días con una alerta: si alguna vez total deja de coincidir con la suma de las líneas, es que la doble escritura tiene un agujero.

Fase 5 — Contract: consolidar y limpiar.

Ahora que todas las filas tienen valor, la columna puede ser obligatoria. Y se retira del código el cálculo antiguo.

Queda un problema abierto, y conviene decirlo con claridad: pedidos.total es un agregado precalculado y hay que mantenerlo sincronizado. Si mañana alguien modifica una línea de pedido con un UPDATE directo, total queda obsoleto y nadie se entera. Las tres soluciones —un trigger que lo recalcule, una vista materializada, o una columna generada si la fórmula viviera en la misma fila— son del módulo 10. Es exactamente la advertencia de 01-05, sección 8: desnormaliza con medidas en la mano, y documenta cómo vas a mantenerlo al día.

El mismo patrón, aplicado a un cambio de forma. Supón que TiendaVerde hubiera nacido con una única columna nombre_completo y quisieras separarla:

Fíjate en lo que nunca se hace: un RENAME COLUMN de golpe, ni un DROP COLUMN antes de que nadie la lea. Cada fase es reversible y ninguna rompe la versión anterior del código.

Todo lo anterior tiene un requisito previo que no es técnico:

Un cambio de esquema no es un comando: es un fichero versionado en el repositorio.

Un fichero numerado, con nombre descriptivo, que contiene un cambio de esquema y (idealmente) su reversión:

Una herramienta de migración mantiene en la propia base de datos una tabla de control con las migraciones ya aplicadas, y al arrancar aplica solo las que faltan, en orden.

Por qué esto es innegociable:

Todas resuelven el mismo problema y difieren sobre todo en si el cambio se escribe en SQL o en el lenguaje de la aplicación. Escribirlo en SQL puro (Flyway, Sqitch, golang-migrate) da control total sobre lock_timeout, NOT VALID y CONCURRENTLY; escribirlo en el lenguaje de la aplicación (Alembic, Rails, Django) da portabilidad entre motores y reversión automática, al precio de perder el control fino que necesitan las tablas grandes.

1. Una migración = un cambio. Si el fichero hace cinco cosas y la tercera falla en producción, no sabrás en qué estado ha quedado (y en MySQL, además, no podrás deshacerlo).
2. Siempre con script de reversión. Aunque tu motor tenga DDL transaccional, escribir el down te obliga a pensar si el cambio es reversible. Muchas veces descubrirás que no lo es — un DROP COLUMN no se deshace — y eso es información valiosísima antes de aplicarlo.
3. Probada en un entorno igual al de producción. No en tu portátil con 20 filas: en una copia con volumen realista. Un ALTER COLUMN TYPE que tarda 40 ms con 20 filas tarda 40 minutos con 40 millones.
4. Con copia de seguridad previa y verificada. Y verificada significa restaurada alguna vez, no "el cron dice que funciona".
5. Nunca a mano en la consola de producción. Ni "solo esta vez", ni "es un cambio pequeño", ni "es urgente". El cambio que no está en el repositorio no existe, y el siguiente entorno que se cree no lo tendrá.

Y un corolario que sale de la fase 2 del expand/contract: las migraciones que rompen la compatibilidad hacia atrás deben partirse en varias. V003 añade la columna, V004 la rellena, V005 la hace obligatoria — cada una desplegable por separado, y entre ellas se despliega el código que las necesita.

La regla que resume las dos tablas: en producción, la pregunta no es "¿funciona este ALTER TABLE?", sino "¿qué pasa mientras se ejecuta, y qué pasa si falla a la mitad?". Si no sabes responder a las dos, la migración no está lista.

• Escribir ALTER TABLE a mano en producción. El error raíz del que salen casi todos los demás.
• Creer que ADD COLUMN con DEFAULT siempre reescribe la tabla. Desde PostgreSQL 11 no lo hace, salvo que el DEFAULT sea volátil.
• Creer que una operación "instantánea" es inofensiva. Necesita el ACCESS EXCLUSIVE, y si no lo consigue encola toda la carga detrás. lock_timeout, siempre.
• RENAME de golpe. Rompe el código antiguo en el instante del COMMIT. Expand/contract, o no lo hagas.
• ALTER COLUMN TYPE sin USING cuando la conversión no es automática. El HINT de PostgreSQL te dice exactamente qué escribir.
• Reducir un VARCHAR sin comprobar los datos. PostgreSQL aborta; MySQL en modo relajado trunca en silencio.
• ADD CONSTRAINT sin NOT VALID en tablas grandes. Escaneo completo con bloqueo exclusivo.
• Esperar que cambiar el DEFAULT actualice las filas existentes. No lo hace: solo afecta a las inserciones futuras.
• Usar DROP COLUMN como borrado seguro de datos sensibles. El dato sigue en disco hasta que la fila se reescriba.
• Suponer que el DDL es transaccional en todas partes. En PostgreSQL, SQL Server y SQLite sí; en MySQL y Oracle, no: una migración a medias se queda a medias.
• Backfill en una sola transacción gigante. Bloquea filas, infla el WAL y si falla hay que empezar de cero. Por lotes.
• Backfill que pisa la doble escritura. Añade WHERE columna IS NULL para tocar solo lo que falta.
• Migraciones sin script de reversión. Escribirlo es la forma más barata de descubrir que el cambio no es reversible.
• Consejo: \d tabla antes y después de cada ALTER TABLE. Comprobar lo que has hecho cuesta dos segundos.
• Consejo: envuelve las migraciones en BEGIN … COMMIT si tu motor lo permite. En PostgreSQL, quince cambios pasan a ser atómicos.
• Consejo: mide el tiempo en una copia con volumen real antes de tocar producción. Es la diferencia entre una ventana de mantenimiento de cinco minutos y una de cinco horas.

Trabaja sobre la base recién recargada, dentro de BEGIN … ROLLBACK.

TiendaVerde quiere registrar el canal por el que entra cada pedido (web o telefono), un dato que hasta ahora se deducía indirectamente de si empleado_id era NULL.

1. Añade a pedidos una columna canal VARCHAR(10), obligatoria, con valor por omisión 'web' y protegida con un CHECK con nombre que solo admita 'web' y 'telefono'.
2. Rellena hacia atrás: los pedidos con comercial asignado son 'telefono'; el resto, 'web'.
3. Comprueba el resultado agrupando por canal.
4. Responde: ¿por qué el paso 1 no requiere reescribir la tabla? ¿Y qué habría pasado si hubieras puesto el CHECK antes de rellenar los datos?

Un compañero te pasa este fichero de migración para revisarlo antes de aplicarlo a producción, donde productos tiene 4 millones de filas y lineas_pedido 90 millones:

1. Identifica todos los problemas, indicando para cada uno si es de bloqueo, de compatibilidad, de reversibilidad o de proceso.
2. Estima cuáles de las seis operaciones son instantáneas y cuáles no.
3. Reescribe la migración como debería estar, partiéndola en los ficheros que haga falta.

Aplica el patrón expand/contract completo para añadir a clientes una columna total_gastado NUMERIC(10,2) que acumule lo que cada cliente ha comprado (producto + portes).

1. Escribe las cinco fases, indicando en cada una qué es cambio de esquema, qué es cambio de código y qué es cambio de datos.
2. Ejecuta las fases 1, 3 y 5 sobre TiendaVerde (la 2 y la 4 son de aplicación).
3. Verifica que la suma de total_gastado de todos los clientes coincide con el total de pedidos del curso.
4. Discute: ¿debe la columna ser NOT NULL? ¿Qué valor tienen los tres clientes sin pedidos, y qué implica eso?

Solución 1

Diez y diez, exactamente el reparto que 01-06 describía: la mitad del canal es web. Y las tres formas de COUNT de 04-04 confirman la coherencia: en el canal telefono los 10 pedidos tienen comercial, en web ninguno. Los portes suman 72,15 € + 46,10 € = 118,25 €, la cifra canónica del módulo 4 — y de paso revelan algo que no se había mirado nunca: el canal telefónico paga bastantes más portes, porque concentra los pedidos a Portugal y Francia.

4. Las dos preguntas.

Por qué no reescribe la tabla: el DEFAULT 'web' es una constante, y desde PostgreSQL 11 eso se guarda en el catálogo y se devuelve al vuelo para las filas antiguas. Si el valor por omisión hubiera sido algo volátil, sí habría reescrito las 20 filas (irrelevante aquí, decisivo con 20 millones).

Qué habría pasado con el CHECK antes de los datos: en este caso concreto, nada malo, porque el DEFAULT 'web' deja todas las filas con un valor válido. Pero si hubiéramos añadido la columna nulable y sin DEFAULT y luego el CHECK, tampoco habría fallado: las 20 filas tendrían NULL, y un CHECK que se evalúa a UNKNOWN se acepta (05-01, apartado 3.5). El CHECK habría pasado sin protestar y con la columna vacía. Es la trampa clásica: el orden importa, pero el CHECK no siempre te avisa de que has hecho las cosas al revés. El NOT NULL sí lo habría hecho.

En una tabla grande el orden correcto y seguro sería: añadir la columna nulable → backfill por lotes → ADD CONSTRAINT ... NOT VALID → VALIDATE CONSTRAINT → SET NOT NULL.

Solución 2

1 y 2. Los problemas, operación por operación:

Y dos problemas de proceso que afectan al fichero entero:

• Seis cambios heterogéneos en una migración. Viola la primera regla de oro: si falla el cuarto, quedas a medias (en PostgreSQL el ROLLBACK te salva; en MySQL, no).
• Sin lock_timeout. Cualquiera de estas operaciones puede encolar toda la carga detrás de sí.

Estimación de tiempos con esos volúmenes: las operaciones 2, 3 y 4 se cuentan en minutos u horas cada una; la 5, en varios minutos. La migración completa dejaría el catálogo inaccesible durante todo ese tiempo.

3. La versión correcta, partida en ficheros:

Y las tres operaciones restantes:

La lección del ejercicio: la mayor parte de una revisión de migraciones consiste en decir que no. De seis operaciones, una está bien planteada y cinco no deberían aplicarse tal como están.

Solución 3

1. Las cinco fases:

2. Ejecución de las fases 1, 3 y 5:

La tentación es hacerlo de una sentencia, uniendo clientes, pedidos y lineas_pedido:

gastos_envio vive en pedidos, y tras el JOIN cada pedido aparece tantas veces como líneas tenga: los portes se multiplicarían y la suma total daría 278,70 € en lugar de 118,25 €. Es exactamente el error que el módulo 3 avisó tres veces y el 4 liquidó.

La forma correcta es agregar en dos etapas, reutilizando la tabla totales_pedido del apartado 10:

Sofia Moreira Costa encabeza el ranking con 131,68 € en dos pedidos, por delante de Lucía, que ha hecho tres. Y los tres últimos, con NULL, son los clientes sin pedidos de 01-06.

3. Verificación:

846,20 €: la cifra canónica del curso (727,95 € de producto + 118,25 € de portes). Doce clientes con compras y tres sin ninguna, exactamente los huecos deliberados de 01-06. Las tres formas de COUNT de 04-04 vuelven a hacer todo el trabajo de verificación.

4. La discusión. ¿Debe ser NOT NULL?

No hay respuesta universal, y esa es la respuesta correcta. Depende de si "no ha comprado" y "ha comprado 0 €" son el mismo hecho de negocio. En TiendaVerde no lo son: Núria, Hugo e Inés nunca han pedido nada, y esa es información. Si se quiere NOT NULL por comodidad aritmética, hay que documentar que el 0 significa dos cosas y añadir una columna pedidos_realizados INTEGER NOT NULL DEFAULT 0 que sí las distinga.

Es exactamente la discusión de 04-03, sección 11 —diseñar con NULL, con centinelas o con NOT NULL— y la prueba de que una decisión de esquema nunca es solo técnica.

Y el problema abierto, el mismo que con pedidos.total: esta columna es un agregado precalculado y hay que mantenerla sincronizada. Cada pedido nuevo, cada línea modificada y cada devolución la dejan obsoleta. La solución —un trigger, o una vista materializada que se refresque— es del módulo 10. Mientras no exista, la columna es una bomba de relojería, y por eso la fase 2 del patrón (la doble escritura) no es opcional: es la única que evita que el dato se pudra.

ALTER TABLE cierra el módulo 5 y con él, tu capacidad de operar sobre una base de datos completa:

• Las operaciones de ALTER TABLE: ADD COLUMN (instantánea, incluso con DEFAULT constante desde PostgreSQL 11, salvo que sea volátil), DROP COLUMN (instantánea, irreversible y no un borrado seguro), RENAME (instantánea y la más peligrosa, porque rompe el código antiguo en el acto), ALTER COLUMN TYPE con USING para las conversiones no triviales, SET/DROP NOT NULL, SET/DROP DEFAULT —que no toca las filas existentes—, y ADD/DROP CONSTRAINT, donde se cobra la insistencia de 05-01 en nombrarlas.
• NOT VALID + VALIDATE CONSTRAINT: protección inmediata para las filas nuevas y comprobación del histórico sin bloquear lecturas ni escrituras. La técnica estándar en tablas grandes.
• Qué bloquea y qué no, con la tabla de niveles; y el detalle que de verdad tumba producción: una operación instantánea que no consigue el ACCESS EXCLUSIVE encola toda la carga detrás de sí. SET LOCAL lock_timeout es la protección.
• DDL transaccional: en PostgreSQL, SQL Server y SQLite un ALTER TABLE se puede deshacer con ROLLBACK y una migración de quince pasos es atómica; en MySQL y Oracle no, y una migración que falla a la mitad se queda a la mitad.
• Expand/contract: añadir lo nuevo → escribir en ambos → rellenar hacia atrás → cambiar la lectura → eliminar lo viejo. Cinco fases en las que nunca existe un estado que rompa la aplicación. Demostrado con pedidos.total, cuyo backfill idempotente (WHERE total IS NULL) cuadró en los 846,20 € canónicos del curso.
• Migraciones versionadas: un fichero numerado por cambio, en el repositorio, revisado como código, aplicado por una herramienta (Flyway, Liquibase, Alembic, Rails, Django, Laravel, Sqitch). Y las cinco reglas de oro: una migración = un cambio, siempre con reversión, probada con volumen realista, con copia de seguridad verificada, y jamás a mano en producción.

Y con esto se cierra el módulo 5. Repasa lo que has ganado en seis lecciones. Sabes crear tablas con CREATE TABLE y declarar las seis restricciones que llevabas cinco módulos leyendo, entendiendo por qué CHECK acepta los nulos, por qué UNIQUE admite varios y por qué GENERATED BY DEFAULT es lo que obliga a aquel bloque de setval. Sabes insertar con INSERT, listando siempre las columnas, en lotes, y recuperando con RETURNING el id que necesitas para colgar las líneas de un pedido. Sabes modificar con UPDATE, con un protocolo de cinco pasos y una transacción abierta, entendiendo que todas las asignaciones se evalúan sobre la fila antigua y que precio * 1.05 no es idempotente. Sabes borrar con DELETE, distinguirlo de TRUNCATE, predecir qué se lleva por delante cada ON DELETE, y —lo más importante— decidir si hay que borrar, porque activo = FALSE existe justo para no hacerlo. Sabes fusionar con ON CONFLICT y con MERGE, y por qué mirar-y-luego-decidir nunca es seguro. Y sabes cambiar el esquema sin tumbar el servicio.

Ha cambiado algo más que el repertorio de instrucciones: ha cambiado el nivel de responsabilidad. En los módulos 2 a 4, un error tuyo devolvía un número equivocado. Desde este módulo, un error tuyo modifica datos reales. Por eso aquí has aprendido tantos hábitos como sintaxis: escribir el SELECT antes que el UPDATE, contar las filas, abrir la transacción, comprobar el RETURNING, hacer copia antes, poner lock_timeout, versionar la migración. Ninguno de esos hábitos aparece en la referencia del lenguaje, y todos separan a quien lleva años tocando bases de datos de quien lleva un mes.

Con TiendaVerde ya puedes hacerlo todo: consultarla, cruzarla, agregarla, poblarla, corregirla y hacerla evolucionar. Lo que aún no puedes es transformar y presentar lo que sacas de ella. Sigues devolviendo nombre y apellidos en dos columnas cuando quieres una; sigues escribiendo ROUND(...) a mano sin conocer sus hermanas; sigues sin poder extraer el año de una fecha, calcular la antigüedad de un cliente, poner un texto en mayúsculas, convertir un tipo en otro de forma explícita, sustituir un NULL por un valor legible, ni clasificar filas en categorías según una condición. En el módulo 6, Funciones, llegan las herramientas que faltan: funciones de cadena para componer y limpiar texto, funciones numéricas para redondear y calcular con criterio, funciones de fecha y hora para responder por fin a "¿cuántos días tardó ese pedido?", CAST y COALESCE para convertir tipos y domar los nulos que llevas dos módulos esquivando, y CASE para meter lógica condicional dentro de una consulta. A partir de ahí, tus consultas dejarán de devolver datos y empezarán a devolver respuestas.