Database Migrations vs Git Hooks

Pessoal, já questionei isso em outros lugares e agora queria saber a opinião de vocês também.

Ainda não usei o migrations, mas estudando ele percebi que é bem manual, conforme confirmado por outro usuário. Ou seja, não existe uma forma de ele automaticamente gerar as classes já com o código baseado no banco atual ou apenas com suas alterações atuais em relação às migrations anteriores.

Portanto, ou não entendi bem ou achei realmente manual ao extremo pois cada alteração no banco eu tenho que ter o cuidado de não esquecer de gerar o migration correto para aquela alteração, caso contrário, quem receber o código pode se deparar com diversos erros. Sem contar na delonga de ter que deixar de usar uma ferramenta de banco de dados para fazer as alterações manualmente no código, ou, continuar a usá-la e aí fazer trabalho dobrado.

Atualmente, o que fiz, já que uso Git, foi criar um script que ao dar commit se encarrega de automaticamente fazer o backup do banco, adicioná-lo ao commit e só então fazer realmente o commit. O arquivo (sql) gerado já é colocado em protected/data e vai sendo atualizado a cada commit. Ou seja, não tem como esquecer de algo, não preciso mexer em nada e não preciso aprender nada novo. Quando eu precisar de outra versão do meu código, receberei junto o sql exato do estado do banco naquela versão.

Obviamente daria pra fazer a atualização do banco automaticamente ao dar um checkout, mas por enquanto não achei necessário.

Então eu pergunto: será que entendi tão mal assim o Migrations ou dessa forma automatizada ‘onCommit’ fica realmente mais fácil?

Na opinião de vocês, quais são os prós e contras de cada método?

Obrigado.

Amigo creio que você compreendeu bem o Migration, mas ele é funcional cara… ainda mais com as ferramentas que possui.

Seu metodo com o git é mais fácil, mas também não resolve a questão como o Migration. Afinal é preciso refazer toda a base sempre que se altera a versão? E os dados? Tudo bem, ficou prática a solução, mas não é a mesma coisa.

Eu acho que database só se colabora bem se ela for única, como um banco de desenvolvimento online. Eu gostei do migration (sua solução tb, vai compartilhar? hehe) mas não sei se um dia vou usar… rs realmente annoying.


AH, já ia me esquecendo eheh uma solução interessante seria utilizar um ORM como o Doctrine ou RedBEAN. Eles geram sua base on the fly, a medida que você configura sua classe. Não é limitado não, nem tão pesado, mas sem dúvida não são todos os casos que são fáceis de implementar - vale a pena testar falou!

Ainda não vi uma integração com o Yii (em termos de model) iria ser interessante descobrir (antes que eu precise desenvolver!)

é isso

Saudações

Obrigado pela resposta, Panurge.

Poderia citar alguns exemplos pra que eu possa entender o que estou perdendo?

O Git não vai salvar o banco inteiro no commit, somente as diferenças. Por isso, mesmo que o banco seja enorme, se eu alterar uma única coluna, somente esta única coluna será salva no próximo commit. Quanto aos dados, o script já está salvando com os dados, mas uma pequena alteração já serve para ele salvar somente a estrutura, se for necessário. Em um ambiente de desenvolvimento o banco tende a ter muito menos dados que num ambiente de produção, somente os necessários.

Sim, já vou fazer um post explicando. Se tiver sugestões de melhoria seria interessante também.


Pois é, já usei bastante o doctrine, mas mesmo que usasse não vejo como isso resolveria a questão do migration ser tão manual.

Mas muito obrigado por sua opinião.

Já vou postar o script com uma breve explicação.

t+

O script está anexado.

Instalação:

[list=1][]Descompactar o arquivo dentro da pasta .git/hooks do projeto;[] Abri-lo e editar usuário, senha, host, banco e destino, conforme necessário;[*]Dar permissão de execução, caso não a tenha ainda;[/list]Uso:

  • Simplesmente continue a usar o Git. Antes de cada commit, o script fará o dump do banco na pasta indicada e automaticamente adicionará o arquivo ao commit que será feito.

Resultados:

  • Sempre que der um checkout de uma versão anterior do código, vá à pasta e recupere o SQL de seu banco, caso ache necessário.

O script é bem simples e bem personalizável. Se desejar poderá usar outro hook do Git para restaurar o banco automaticamente após um checkout.

Sugestões são bem-vindas.

T+ pessoal

Oi pessoal,

Ninguém mais usando o migrations?

Bom vamos lá :)

Como eu disse la na lista, ele é manual sim, mas isso está longe de ser um problema (pelo menos para mim).

Se você já possui um projeto, vai migra-lo para a versão 1.1.7 do framework e está pensando em utilizar migrations, é interessante gerar uma migration responsável por criar o schema do banco no estado atual. Sim, isso vai ter que ser manual, não há uma ferramenta que leia o banco e crie a classe. Mas também não é difícil de fazer. Essa será a única etapa de trabalho dobrado. A partir daqui, tudo será gerado por meio de migrations. A idéia é que você não crie mais nada diretamente no banco.

Se você está criando um projeto, não há retrabalho. Desde o começo você usara migrations para criar e alterar a estrutura do banco.

Você está acostumado a criar tudo diretamente no banco (usando phpMyAdmin, Workbench, adminer ou whatever)? Então tem duas opções:

  • Perca essa costume (e essa é a melhor opção)

  • Não use migrations, elas não são pra você

Simples assim ;) Mudar para migrations não é trabalho a mais. Você simplesmente vai deixar de criar no banco e criar no arquivo.

Agora vamos ao porque é mais interessante deixar de mexer no banco: Independência de Banco de Dados. A coisa mais legal de usar ActiveRecord e o Query Builder é essa indepêndencia de Banco de Dados. Escrevo meu código ,somente em PHP, e tudo funciona lindo (ok, talvez o query builder não funcione 100%) independente do banco de dados que eu utilizo. Utilizar migration é trazer essa mesma facilidade e independência para a tarefa de gerenciar o schema do banco.

Com a sua solução, como eu consigo isso? E se eu não quiser usar o MySQL? E se eu resolvo mudar de banco na versão 2 do sistema? Na verdade, com o seu script eu nem mesmo consigo trabalhar no windows! (ok, sei que o git no windows fede :( )

Entende qual a idéia de soluções como Migrations, ActiveRecord e etc?

Oi Davi, obrigado pela resposta. Acho que comecei a entender o migrations. Na lista sua resposta não havia sido abrangente mas agora foi.

Vou comentar o que considero sobre alguns bons pontos que você citou:

Vou considerar a ideia de começar a seguir a opção um quando eu estiver trabalhando em bds simples, com relacionamentos de pouca complexidade. Mas o banco que estou usando agora é um tanto complexo pra eu considerar a hipótese de abdicar de uma ferramenta visual de modelagem e ficar mentalizando códigos. Por isso, fico com a opção dois por enquanto.

Nisso concordo com você e esse ponto tinha passado despercebido por mim até agora. Mesmo assim, ainda questionaria o seguinte:

[list=1][]Quanto tempo eu gastaria pra usar o migrations em cada alteração no decorrer de um projeto longo?[]Quanto tempo eu gastaria se eu convertesse um sql do padrão MySQL para um PostGre por exemplo?[/list]Do meu ponto de vista, existe uma boa chance de a segunda opção tomar muito menos tempo (no somatório final) do que a primeira pois a grande maioria das alterações para adaptação não deverão ser complexas. Inclusive existem até ferramentas que fazem isso por mim.

O que quero dizer é: converter um sql do formato mysql para o formato X ainda parece ser mais vantajoso do que ter de fazer diversas alterações manuais no decorrer do projeto pelo principal motivo da compatibilidade.

Com uma conversão do sql atual do banco. Assim, como já dito, acredito que poupa muito tempo e trabalho.

Nisso você talvez tenha razão mesmo pois não sei se na versão do git for windows existem hooks e se funcionam bem como no linux. Mas deve ser contornável com um lotezinho [.bat].

Sim, o principal motivo então seria a compatibilidade com o código, e não o versionamento do banco em si.

Mais um motivo pra eu realmente optar por outra solução (a do script tem sido boa pra mim) em vez de usar o migrations.

Muito obrigado Davi por tirar tempo pra me esclarecer esses pontos.

Sinta-se à vontade pra discordar de algo que eu disse ou questionar, como fez.

Assim vamos compartilhando experiências e pontos de vista.

Forte abraço. :D

T+

Davi, vamos lá. Um colega da lista em inglês me trouxe o que acredito ser o ponto-chave do migrations e esse sim me parece primordial nos sites em produção, embora ainda prefira o script em modo dev, pois os dados já cadastrados não são de grande importância no estágio dev.

Eis a resposta que obtive:

					 						Cara, muito obrigado por ajudar também. Talvez você tenha tentado dizer o que ele disse e eu posso não ter captado mas o importante é que agora vejo um motivo real de usar migration, embora ainda creio que só usarei após o projeto entrar em modo de produção pois aí sim haveria dados sensíveis que não poderiam ser perdidos com um dump no banco.

Considero o assunto finalizado e agradeço aos que procuraram esclarecer os pontos. Mesmo assim, se alguém souber de algum outro aspecto fundamental sobre migrations, por favor, compartilhe.

Abraço a todos.