DEV Community: 404Room

Migraciones en Laravel

404Room — Tue, 15 Sep 2026 04:51:38 +0000

Seguramente en algún punto dentro del desarrollo de nuestra base de datos hemos atravesado por alguna de estas fases: Análisis de requerimientos donde definimos las reglas de negocio, Diseño de la Solución donde modelamos la información (Modelo Conceptual) y la representamos de forma gráfica, y la Implementación (Modelo Físico) donde básicamente llevamos a la realidad la manera en que se almacenará nuestra información, es decir, donde creamos la base de datos, las tablas, las columnas, generamos los índices, establecemos las restricciones, etc.

Es en esta fase de implementación donde por lo regular hacemos uso de un gestor de base de datos como Mysql, Oracle, PostgreSQL, SQL Server, Mongodb, etc, para llevar a cabo las tareas previamente mencionadas, y es en esta fase donde haremos mayor énfasis.

Por lo común, las tareas dentro del Modelo Físico se llevan a cabo de forma manual, por ejemplo, directamente a través de un cliente en consola o a través de una interfaz gráfica como Mysql Workbench o DBeaver. Otra manera de lidiar con esta tarea es a través de la codificación de un script que automatice esta tarea por nosotros. En cualquier caso, llegar a ejecutar los cambios de nuestra db de alguna de estas formas puede llegar a ser complicada y/o engorrosa.

Con Laravel, todas estas tareas pueden ser llevadas a cabo de una forma más sencilla y gestionable a través del uso de las migraciones.

Una migración nos permite crear y alterar el esquema de nuestras tablas, generar índices, establecer restricciones, etc, sin embargo, también actúa como una especie de control de versiones sobre nuestra base de datos, esto es, si eventualmente necesitamos consultar un cambio anterior o decidimos que la versión inicial o previa era la que se necesita, en lugar de reescribir todo, simplemente lanzando algunos comandos podemos volver hacia atrás en la línea de tiempo de nuestra db.

Creando nuestra primera migración

Para crear una migración simplemente ejecutamos el siguiente comando:

> php artisan make:migration create_posts_table

Con esto se habrá generado un archivo de migración que tendrá por objetivo crear la tabla de nuestras publicaciones.

Por defecto, Laravel ubica los archivos de migración en database/migrations, además, podemos notar que el nombre del archivo de migración generado posee una nomenclatura que lo identifica:

Sin embargo, lo realmente interesante se encuentra dentro de nuestro archivo de migración recién generado:

class CreatePostsTable extends Migration
{
  /**
  * Run the migrations.
  *
  * @return void
  */
  public function up()
  {
    Schema::create('posts', function (Blueprint $table) {
      $table->id();
      $table->string('title');
      $table->string('url')->unique();
      $table->mediumText('excerpt')->nullable();
      $table->text('body')->nullable();
      $table->timestamp('published_at')->nullable();
      $table->timestamps();
    });
  }

  /**
  * Reverse the migrations.
  *
  * @return void
  */
  public function down()
  {
    Schema::dropIfExists('posts');
  }
}

Dentro del cuerpo de esta Clase podemos identificar 2 métodos:

Dentro del método up() se encuentra aquel código que altera de alguna manera nuestra tabla, por ejemplo, agregar columnas, cambiar el tipo de dato de una columna, generar índices, establecer restricciones, etc. Este método es invocado en el momento que ejecutamos la migración.
El método down() hace lo opuesto, esto es, ejecutar código que revierta lo realizado por el método up(). Este método es invocado en el momento en que decidimos revertir la migración.

Ejecutando una migración

Existen múltiples maneras de correr una migración, sin embargo, la manera más sencilla de hacerlo es con el siguiente comando:

> php artisan migrate

Esto básicamente ejecuta el método up() de nuestra migración. En este punto, se ha creado la tabla posts dentro de nuestra base de datos.

Revirtiendo una migración

Si nuestra intención es deshacer cualquier operación realizada por la ejecución de las migraciones previas, simplemente ejecutamos:

> php artisan migrate:rollback

Esto básicamente ejecuta el método down() de nuestra migración. En este punto, se ha removido la tabla posts dentro de nuestra base de datos.

Migraciones e identificadores de Lote

Creo que esta parte es una de las más importantes y un poco engañosas de entender. Si inspeccionamos la base de datos de nuestro proyecto veremos que existe una tabla llamada migrations que es la encargada de llevar a cabo el control de nuestras migraciones.

Dentro de esta tabla podemos identificar una columna llamada batch. El valor de esta columna es utilizada por Laravel para determinar el orden de ejecución y/o reversión de nuestras migraciones, básicamente funciona como un identificador de lote.

Las migraciones cuyo identificador de lote o batch es 1, son aquellas que ejecutamos por lo común al inicio de nuestro proyecto. La migración con identificador de lote 2, es la migración que recién ejecutamos para crear la tabla de publicaciones que pretendemos utilizar en nuestro proyecto.

Vamos a generar 2 nuevas migraciones: categorías y tags.

> php artisan make:migration create_categories_table
> php artisan make:migration create_tags_table

Ejecutamos nuestra suite de migración:

> php artisan migrate

Y obtenemos el siguiente resultado:

Las nuevas migraciones han sido ejecutadas y ahora poseen el identificador de lote 3. Básicamente cada vez que creamos y corremos nuevas migraciones sobre nuestro proyecto, se genera un identificador de lote propio.

Podemos observar que este identificador de lote se va generando de forma incremental en el caso de nuevas migraciones, de igual manera, si revertimos una migración, el identificador de lote irá disminuyendo. Probemos ejecutando el comando de reversión de migraciones previamente mencionado:

> php artisan migrate:rollback

El resultado es el siguiente:

Podemos apreciar que no todas las migraciones fueron revertidas, solo las últimas, las que tenían el número de lote 3, básicamente hemos vuelto un paso hacia atrás. Si nuevamente ejecutamos el comando de rollback, el resultado será:

Y si nuevamente revertimos nuestras migraciones con el comando anterior en este punto, solo nos quedaremos con:

absolutamente nada, nuestra base de datos no contiene tabla alguna a excepción de la tabla migrations.

Tal vez te preguntes ¿Por qué sucede esto?, nuevamente la respuesta se encuentra en el valor del campo batch.

El proceso de rollback solamente revierte un lote o conjunto de migraciones a la vez tomando como referencia el valor del campo batch, es por ello que tuvimos que ejecutar 3 veces el procedimiento de reversión a través del comando rollback en la consola de Laravel.

Si nuestra intención es revertir todas la migraciones sin importar el identificador de lote, simplemente lanzamos en la terminal:

> php artisan migrate:reset

Alternativamente, podemos ejecutar un rollback de forma selectiva:

> php artisan migrate:rollback --step=1

En este caso solo se eliminara la migración más reciente pero respetando el lote:

Reversión y Migración en un sola acción

Cuando nos encontramos en modo desarrollo es muy común borrar todas las tablas haciendo un rollback y recrearlas nuevamente ejecutando la migración. Para poder realizar esta tarea en un solo paso simplemente:

> php artisan migrate:fresh

Sin embargo, dado que esta acción es destructiva se desaconseja su uso en producción.

Adicionalmente, podemos agregar una acción más a este comando, y esto es, correr nuestros seeders:

> php artisan migrate:fresh --seed

Migrando sin perder la información

Probablemente te estes preguntando como alterar el esquema de una tabla sin perder la información que contiene.

Para poder alterar la estructura de una tabla sin perder la información que contiene simplemente creamos migraciones adicionales. Cada una de estas migraciones debe seguir una determinada convención que describe lo que hace.

Por ejemplo, digamos que necesitamos agregar una nueva columna a nuestra tabla de publicación para guardar la url de una imagen destacada, simplemente escribiríamos algo como esto:

> php artisan make:migration add_featured_image_url_to_posts_table

Si abrimos el archivo recién generado, podemos observar que el cuerpo de la Clase cambia ligeramente:

class AddFeaturedImageUrlToPostsTable extends Migration
{
  /**
  * Run the migrations.
  *
  * @return void
  */
  public function up()
  {
    Schema::table('posts', function (Blueprint $table) {
      // Deseamos agregar esta nueva columna a nuestra tabla 'posts'
      $table->text('featured_image_url')->nullable();
    });
  }

  /**
  * Reverse the migrations.
  *
  * @return void
  */
  public function down()
  {
    Schema::table('posts', function (Blueprint $table) {     
      // Debemos es explícitos e indicar que queremos hacer cuando esta migración sea revertida.
      // En nuestro caso, deseamos eliminar la columna previamente creada.
      $table->dropColumn('featured_image_url');
    });
  }
}

En el método up() en lugar de crear una nueva tabla, hacemos referencia a una existente, en este caso, a la tabla posts. De igual manera, dentro del método down() indicamos que deseamos eliminar una columna, en lugar de la tabla completa.

Ya simplemente queda ejecutar la migración, y listo, tendremos una nueva columna en nuestra tabla de publicaciones.

Hablar sobre la convención de nombres que debemos utilizar para agregar nuevas columnas, índices, restricciones daría para otro articulo en el futuro. Espero esta información te haya servido para entender un poco más sobre las migraciones en Laravel.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Introducción a la Notación Big O

404Room — Tue, 15 Sep 2026 04:23:59 +0000

¿Cómo evaluar el desempeño de un algoritmo?, ¿Qué queremos decir cuando el desempeño de un algoritmo es mejor que otro?, ¿Qué es lo que buscamos de la implementación de nuestro algoritmo?. Al desarrollar un algoritmo surgen estas interrogantes y la ambigüedad se hace presente.

Sea que busquemos rapidez en el tiempo de ejecución, ya sea en el orden de segundos e incluso en milisegundos.
Minimizar el uso intensivo de la memoria, definiendo menos variables y con nombres más compactos.
Maximizar la legibilidad de nuestro código para hacerlo más mantenible.

Cualquier decisión que tomemos siempre tendrá un tradeoff o costo de oportunidad, sin embargo, lo importante es saber realmente lo qué queremos o buscamos de nuestro algoritmo.

¿Deberíamos escribir código más compacto con el riesgo de que sea menos legible y por lo tanto más difícil de mantener? o por el contrario, ¿Deberíamos escribir código más claro y legible con el potencial de que ocupe mas espacio en memoria?.

Supongamos que nuestra intención es comparar la velocidad de ejecución entre estas 2 funciones:

Implementación de addUpToFirst():

function addUpToFirst(n)
{
  let total = 0;

  for( i = 1; i <= n; i++) {

    total += i;
  }

  return total;
}

Implementación de addUpToSecond():

function addUpToSecond(n)
{
  return n * (n + 1) / 2;
}

Procedamos a evaluar el desempeño de ejecución de cada uno y comparemos.

Resultados de addUpToFirst():

let t1 = performance.now();
addUpToFirst(1000000000);
let t2 = performance.now();

console.log("Tiempo transcurrido: ${(t2 - t1) / 1000} segundos");

Tiempo Transcurrido: 1.25750000000006985 segundos
Tiempo Transcurrido: 1.24369999999936985 segundos

Resultados de addUpToSecond():

let t1 = performance.now();
addUpToSecond(1000000000);
let t2 = performance.now();

console.log("Tiempo transcurrido: ${(t2 - t1) / 1000} segundos");

Tiempo Transcurrido: 0.00010000000004773 segundos
Tiempo Transcurrido: 0.00010000000004773 segundos

Evidentemente la segunda versión es muchísimo mas rápida en comparación con la primera versión en términos de velocidad de ejecución.

Sin embargo, esta evaluación de alguna manera sigue siendo ambigua, y esto se debe principalmente a la herramienta que hemos utilizado para evaluar el desempeño en el tiempo de ejecución del algoritmo en cuestión: un Temporizador.

Entonces, ¿Me estás diciendo que un temporizador es un mecanismo poco confiable al evaluar el desempeño del tiempo de ejecución de un algoritmo?, en definitiva, y esto se debe principalmente al hardware:

Diferentes máquinas registran diferentes tiempos dadas las especificaciones de hardware de cada máquina, lo que ocasiona que los resultados puedan variar.
Una misma máquina puede registrar diferentes tiempos cada vez que ejecutamos nuestra rutina. La variación puede ser poco significativa, pero aún así puede existir una falta de precisión.
La métrica de velocidad en el tiempo de ejecución puede no ser un indicador preciso y confiable en algoritmos que son muy veloces. Por ejemplo, podemos tener 4 algoritmos superveloces, tan rápidos que los temporizadores no lleguen a registrar los tiempos de ejecución de cada uno de forma precisa.

En lugar de intentar contabilizar el número de segundos (el cual es variable) que tarda una rutina en finalizar su ejecución, es mucho mejor concentrarse en contabilizar el número de operaciones que nuestra implementación debe realizar para llegar a un resultado.

El tiempo de ejecución de nuestro algoritmo depende del número de operaciones que realice, y este número es constante sin importar la máquina o hardware que utilicemos.

Tomemos como ejemplo la implementación de la función addUpToFirst():

y comparemosla con la función addUpToSecond():

¿Qué podemos concluir de esta comparativa?. La función addUpToFirst() ejecuta un número de operaciones que es proporcional al valor asignado a n, es decir, a medida que n aumenta, el número de operaciones que realiza este algoritmo crecerá en la misma proporción.

En contraste, la función addUpToSecond() lleva a cabo solamente 3 operaciones independientemente del valor que le asignemos a n, por lo que si n crece, el número de operaciones que realiza nuestro algoritmo se mantiene siempre igual.

En la práctica llevar un conteo de operaciones ejecutadas por un algoritmo puede parecer un enfoque poco intuitivo, sin embargo, existe una manera de llevar a cabo esto.

Debemos entender qué, lo importante no es llevar el conteo preciso y exacto en el número de operaciones ejecutadas, lo que realmente importa es observar el comportamiento general del número de operaciones ejecutadas relativas la variabilidad de n.

Esto básicamente significa que todo algoritmo posee un tendencia que puede ser plasmada en una gráfica, y es a través de esta gráfica que nos damos una idea general del desempeño de nuestro algoritmo, en este caso, relativa al tiempo o velocidad de ejecución.

Tendencia general de addUpToFirst(): a medida que n crece, el tiempo de ejecución crece de forma proporcional o lineal.

Tendencia general de addUpToSecond(): a medida que n crece, el tiempo de ejecución permanece casi constante.

En esta breve introducción tenemos los fundamentos necesarios para comenzar a entender lo que es la notación Big O y su significado. En el siguiente artículo nos adentraremos en mayor profundidad en el tema, espero les haya gustado. Saludos y Happy Coding.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.