Granularidade de migrations

Programação Ruby on Rails
#1

Olá pessoal, feliz ano novo a todos.

É comum que o lançamento de uma nova versão de um aplicativo contenha muitas modificações no banco de dados: algumas colunas adicionadas, outras removidas, novas tabelas criadas, etc. Como vocês costumam granularizar as migrations que envolvem essas alterações?

Por exemplo, vamos supor que uma atualização de um determinado aplicativo contenha a adição de dois campos a uma tabela e a remoção de um campo em outra. O mais adequado seria ter uma migration por tabela, uma migration por coluna ou apenas uma migration abrangendo todas as modificações?

Abraço.

#2

é barbada, é só não pensar nisto :smiley:
Um exemplo:
Te mandaram criar um cadastro novo, cria uma migration, implementa o cadastro e comita tudo.
Depois te mandaram remover um campo de um cadastro já existente
cria uma migration para fazer a alteração no banco
implementa a alteração e comita

assim tu tem migration por alteração no sistema, que é o mais correto na minha opinião, e não por versão do sistema, que normalmente inclui diversas alterações.

#3