Respuesta.

Historia de la pregunta

El cambio en el esquema de la tabla se ha vuelto relevante con la amplia difusión de metodologías ágiles. Los proyectos evolucionan, los requisitos cambian — con el tiempo, necesariamente surge la necesidad de agregar/cambiar/eliminar columnas. En las bases de datos productivas en funcionamiento, esos cambios son especialmente arriesgados.

Problema

La modificación de la estructura puede llevar a:

bloqueos prolongados
pérdida o migración incorrecta de datos antiguos
violación de restricciones externas, disparadores o lógica de la aplicación

Los cambios son especialmente complicados en tablas grandes (millones de filas), que son utilizadas activamente por otros servicios.

Solución

Un trabajo adecuado a través de ALTER TABLE — cambios por etapas, creación de copias de datos, pruebas en el entorno de desarrollo, limitación del tiempo de inactividad. Uso de transacciones, migraciones por etapas y copias de seguridad antes de cambios drásticos. En bases de datos de alta carga, a menudo se utilizan algoritmos de ALTER "en línea".

Ejemplo de código:

-- Agregar una nueva columna con valor predeterminado
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- Población gradual de nuevas columnas
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

Características clave:

Se recomienda crear nuevas columnas primero, y luego transferir datos gradualmente
Realizar operaciones grandes fuera de las horas pico
Siempre hacer copias de seguridad y pruebas automáticas

Preguntas tramposas.

¿Se ejecuta ALTER TABLE de forma atómica?

A menudo no: cambiar la tabla puede tomar mucho tiempo. En caso de fallo, parte de los cambios puede revertirse, pero parte puede quedar en estado pendiente. Por lo tanto, solo algunas bases de datos (por ejemplo, PostgreSQL) implementan protección transaccional en comandos DDL.

¿Se puede cambiar sin dolor el tipo de columna de INTEGER a VARCHAR?

No siempre: si hay datos antiguos en la columna que no corresponden al nuevo formato, o si hay objetos relacionados (índices, disparadores, claves), la base de datos puede no permitir el cambio o los datos pueden corromperse.

¿ALTER TABLE siempre impone un bloqueo exclusivo en toda la tabla?

Depende de la base de datos: en MySQL y versiones antiguas de SQL Server, cualquier operación ALTER a menudo bloquea completamente la tabla hasta su finalización, pero las bases de datos modernas admiten "DDL en línea", reduciendo el tiempo de bloqueo.

Errores típicos y anti-patrones

Cambiar la estructura sin copias de seguridad
Migrar tablas grandes sin pruebas en el entorno de desarrollo
Renombrar columnas sin verificar dependencias (por ejemplo, claves externas, procedimientos)
ALTER masivo durante horas de alta carga

Ejemplo de la vida real

Caso negativo

Un ingeniero de DevOps realizó cambios masivos en tres tablas importantes a través de ALTER TABLE y eliminó columnas antiguas. No tuvo en cuenta que estas columnas estaban vinculadas a claves externas y disparadores. Durante la ejecución de ALTER, la base de datos estuvo ocupada 20 minutos — durante ese tiempo, los servicios "cayeron" debido a la falta de los campos necesarios.

Ventajas:

Los cambios se implementaron según el TDR

Desventajas:

Pérdida de funcionalidad de parte de los servicios
Tiempo de inactividad del negocio de casi media hora
Recuperación laboriosa de dependencias y restauración de datos eliminados

Caso positivo

Un analista planeó la adición de una columna en varias etapas: primero se creó la columna con un valor predeterminado, se realizó una carga de prueba en las copias, y solo luego se realizó el ALTER real por la noche, informando a todos los desarrolladores sobre la ventana de migración inminente.