Por qué importa el nombre
En equipos chicos, el nombre de una migración se ve dos veces: cuando la creás y cuando debuggeás un error en producción. En equipos grandes, se ve cien veces más: en code review, en deploys, en rollbacks. Un nombre claro ahorra minutos cada vez.
El patrón estándar
YYYYMMDDHHMMSS_verbo_objeto.sql (o .rb, .php, etc).
El timestamp con segundos garantiza orden incluso cuando varias personas crean migraciones
el mismo día. El verbo describe la operación. El objeto es la tabla o el campo afectado.
Verbos comunes
- create: crear una nueva tabla.
- drop: eliminar una tabla.
- add: agregar columna o índice.
- remove: quitar columna o índice.
- rename: renombrar tabla o columna.
- change: modificar tipo o constraint.
- backfill: poblar datos en una nueva columna.
Convenciones por framework
Rails usa el formato YYYYMMDDHHMMSS_create_users.rb con la
clase CreateUsers < ActiveRecord::Migration[7.0]. Laravel:
2024_01_15_103000_create_users_table.php. Knex:
20240115103000_create_users.js. Flyway:
V1.2.3__create_users.sql (versionado, no timestamp).
Migraciones reversibles
Toda migración debería tener un up y un down. El
down revierte. Esto te salva en producción cuando algo anda mal: el rollback
es tan simple como ejecutar el down. Migraciones irreversibles (drop column
con datos) son una decisión que hay que documentar.
Migraciones grandes y zero-downtime
Renombrar una columna en una tabla de millones de filas bloquea la base. El patrón zero-downtime es: 1) agregá la columna nueva, 2) escribí en ambas, 3) backfill, 4) cambiá las lecturas a la nueva, 5) dejá de escribir la vieja, 6) borrá la vieja. Cada paso es una migración independiente, y el código convive con ambas durante un sprint.
Migraciones de datos vs schema
Mantené migraciones de schema (DDL: CREATE, ALTER, DROP) separadas de migraciones de datos
(DML: UPDATE, INSERT). Nombres como backfill_users_locale o
fix_orders_currency dejan claro qué hace. Las DDL deberían ser idempotentes
cuando es posible (CREATE TABLE IF NOT EXISTS).
Reviews y orden
En el PR, mostrale al revisor el SQL que se va a ejecutar (EXPLAIN si es
complejo), el plan de rollback y el impacto estimado. Para tablas con tráfico alto,
coordiná el deploy en horario de bajo uso. Las herramientas como gh-ost o pt-osc permiten
ALTERs sin lock en MySQL.