Aquí tienes un nuevo suscriptor hermano! Me gustaría preguntarte si podrías explicar algún método para hacer mirgaciones inversas desde una bd existente hacia un proyecto symfony vacío
Estimado @miguelcuevas3934, hasta finales del 2019 se podía a través del comando: doctrine:mapping:import sin embargo ya está deprecado, te comparto la documentación symfony.com/doc/current/doctrine/reverse_engineering.html
Hola, para este caso una relación manytomany generaría una 3° tabla, o tabla de paso. Para la perspectiva que se menciona en el vídeo "un usuario puede estar relacionado a muchas materias" , la tabla materias funciona como un catálogo. Te felicito por el comentario y te recomiendo practicar la relación que tú mencionas, posteriormente haz la migración hacia la base de datos, verás que potente es Symfony que en automático te crearía esa tabla usando el asistente make:entity
Hola. Sí que debería ser ManyToMany. Si no cada usuario genera diferentes materias cuando, en realidad, en un caso normal como este, lo que buscas es que un usuario se suscriba a materias que ya existen. Imagino que por fines didácticos conviene más practicar primer con una relación OneToMany, pero lo ideal aquí sería una ManyToMany. De no ser así, tampoco tiene sentido que las materias tengan un contador de alumnos, porque cada materia solo puede albergar a 1 alumno.
Mais uma vez, obrigado...aguardando novos vídeos....valeu.....vou maratonar novamente todos para entender melhor.........abs.....
Gracias por tus buenos comentarios! Saludos desde México.
Aquí tienes un nuevo suscriptor hermano! Me gustaría preguntarte si podrías explicar algún método para hacer mirgaciones inversas desde una bd existente hacia un proyecto symfony vacío
Estimado @miguelcuevas3934, hasta finales del 2019 se podía a través del comando: doctrine:mapping:import sin embargo ya está deprecado, te comparto la documentación symfony.com/doc/current/doctrine/reverse_engineering.html
Buenas! Una duda, la relación no sería manytomany??
Hola, para este caso una relación manytomany generaría una 3° tabla, o tabla de paso. Para la perspectiva que se menciona en el vídeo "un usuario puede estar relacionado a muchas materias" , la tabla materias funciona como un catálogo. Te felicito por el comentario y te recomiendo practicar la relación que tú mencionas, posteriormente haz la migración hacia la base de datos, verás que potente es Symfony que en automático te crearía esa tabla usando el asistente make:entity
Hola. Sí que debería ser ManyToMany. Si no cada usuario genera diferentes materias cuando, en realidad, en un caso normal como este, lo que buscas es que un usuario se suscriba a materias que ya existen.
Imagino que por fines didácticos conviene más practicar primer con una relación OneToMany, pero lo ideal aquí sería una ManyToMany. De no ser así, tampoco tiene sentido que las materias tengan un contador de alumnos, porque cada materia solo puede albergar a 1 alumno.