Cómo Doctrine convierte entidades en tablas reales

Crear una base de datos en Symfony deja de ser un misterio cuando entiendes cómo Doctrine traduce tus entidades en tablas reales. Aquí verás cómo configurar el archivo .env, generar migraciones y conectar tu proyecto a un motor local sin fricción, ideal si estás empezando con Symfony y quieres una estructura profesional desde el día uno.

¿Cómo se configura la conexión a la base de datos en el archivo .env?

El primer paso es abrir el archivo .env y decidir qué motor vas a usar. Comenta las líneas que no necesitas y descomenta la que sí, según tu motor. En el ejemplo de la clase se eligió un sistema local muy simple que guarda los datos en la carpeta var/, suficiente para desarrollo.

Esa línea de configuración tiene un nombre técnico: DSN, que se traduce como Data Source Name, es decir, el nombre del origen de los datos. Le dice a Symfony exactamente dónde viven tus datos [2:50].

¿Qué es un DSN en Symfony? Es la cadena de conexión que indica el motor, usuario, contraseña y ubicación de la base de datos. Symfony la lee desde .env para saber a qué fuente conectarse.

Si eliges MySQL en lugar de un motor local, la cadena cambia: incluye usuario, contraseña y nombre de la base de datos. Lo interesante es que el código que Doctrine genera después se adapta automáticamente al motor que declaraste.

¿Cómo generar una migración con make:migration?

Antes de tocar nada, revisa el estado de Git. Es un hábito que te salva: sabes exactamente qué archivos cambiaste y cuáles creó el framework por ti.

El comando para crear la primera migración es:

bash bin/console make:migration

Al ejecutarlo, Symfony lee tus entidades y genera un archivo PHP nuevo dentro de la carpeta de migraciones [1:30]. Ese archivo contiene las instrucciones SQL traducidas para crear las tablas: usuarios, fragmentos de código y comentarios, con sus relaciones de parent ID, autor y referencias cruzadas.

Si vuelves a correr git status, verás que el único cambio nuevo es ese archivo de migración. Nada más se tocó. Y aquí viene lo interesante: el código generado es específico del motor que declaraste en el DSN. Cambia de motor y el SQL cambia con él.

¿Cómo ejecutar migraciones y crear las tablas en Doctrine?

Tener el archivo de migración no significa tener tablas. La base de datos sigue vacía hasta que ejecutes la migración.

Primero revisa el listado disponible:

bash bin/console doctrine:migrations:list

Verás tu archivo marcado como no migrado. Para aplicarlo:

bash bin/console doctrine:migrations:migrate

Symfony te pregunta si deseas ejecutar la acción. Respondes que sí y todo el PHP del archivo se traduce en tablas reales dentro de tu base de datos [4:50].

¿Qué tablas se crean a partir de las entidades?

Con las entidades del proyecto se generan tres tablas relacionadas entre sí:

• Tabla de usuarios, con los campos definidos en la entidad correspondiente.
• Tabla de fragmentos de código, que incluye un parent_id y la referencia al autor.
• Tabla de comentarios, que pertenece a un autor y a un fragmento de código.

Después de migrar, si repites el comando de listado, verás que la migración aparece con la fecha y hora exactas en que se aplicó.

¿Qué pasa si la base de datos no existe todavía? Debes crearla manualmente con bin/console doctrine:database:create antes de ejecutar las migraciones. Sin base, no hay tablas que migrar.

¿Cómo inspeccionar parámetros y entornos en Symfony?

Un detalle que muchos pasan por alto: el nombre de tu archivo de base de datos local incluye el entorno actual. Si trabajas en desarrollo, verás algo como data_dev. Ese sufijo viene de la variable de entorno que Symfony resuelve en tiempo de ejecución.

Puedes inspeccionar todos los parámetros del contenedor con:

bash bin/console debug:container --parameters

Entre la información que aparece está la sección Kernel, donde se imprime el entorno activo (dev) y otras variables como PROJECT_DIR, que apunta al nombre de la carpeta donde vive tu proyecto, en este caso basic [3:30].

Entender estos parámetros te ayuda a leer mejor los nombres autogenerados y a depurar cuando algo no conecta como esperas.

¿Cómo visualizar la base de datos creada?

Una vez aplicada la migración, puedes abrir tu base de datos con una extensión gratuita del editor para ver las tablas, sus columnas y relaciones. Verás los campos que definiste en las entidades reflejados tal cual: claves foráneas, tipos de dato y restricciones.

Es el momento donde el trabajo abstracto de las entidades se vuelve tangible. Tu proyecto ya está conectado a una base real, con tablas funcionales listas para recibir datos.

Como reto, conéctate a otro motor de base de datos, por ejemplo MySQL o PostgreSQL, y deja en los comentarios cómo te fue al cambiar de tecnología y qué diferencias notaste en el SQL generado.