Tenho uma dúvida em relação ao V1 do migration, por exemplo quando uso o data modeler ou mysql workbench para modelar meu banco de dados, gero um sql com todas as tabelas, não seria possivel fazer do V1 um create de todas essas tabelas, e nas proximas versões ir colocando as modificações? Ou isso até é possivel mas não é indicado, ou não seria devido a organização ou padronização. Não seria tanto uma duvida tecnica, apenas curiosidade para manter o meu projeto dentro dos padrões.
Obrigado
hoje, com a Alura e o Google Gemini
Olá Gustavo. Tudo bem?
A ideia de criar um único script no V1 para todas as tabelas é tecnicamente possível, mas não é a prática mais recomendada por algumas razões importantes.
Organização e Clareza: Criar migrations separadas para cada tabela ou alteração no banco de dados ajuda a manter o histórico de mudanças mais organizado e fácil de entender. Se você precisar revisar ou auditar as mudanças no banco de dados, será muito mais simples entender o que cada migration faz quando elas estão separadas e bem nomeadas.
Imutabilidade e Controle de Versão: Ao manter cada migration imutável e específica, você segue um princípio semelhante ao controle de versão de código, como no Git. Isso significa que, se precisar adicionar ou modificar algo no futuro, você cria uma nova migration, preservando o histórico das alterações anteriores.
Dependências: Em muitos casos, uma tabela pode depender de outra. Criar migrations separadas permite que você controle a ordem de criação e modificação das tabelas, garantindo que todas as dependências sejam respeitadas.
Facilidade de Reversão: Se algo der errado com uma migration, é mais fácil reverter mudanças específicas sem impactar todo o esquema do banco de dados.
Por esses motivos, a prática recomendada é criar migrations separadas para cada tabela ou alteração. Isso não só ajuda a manter o projeto mais organizado, mas também facilita a manutenção e evolução do banco de dados ao longo do tempo.
Espero ter ajudado e bons estudos!