Controlador de versão SQL

27/03/2019

15

Boa tarde a todos, como vocês fazem o controle de versão das alterações em banco de dados em projeto mais robusto?
Responder

Post mais votado

23/07/2019

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?


Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.
Responder

Mais Posts

Ei Glauco, acho que não entendi muito bem sua pergunta, está querendo dizer de Auditorias?
Geralmente cria-se uma tabela de LOG para registro de ações realizadas por usuários (Insert/Update/Delete)

Espero que tenha ajudado,

Abraço !
Responder

23/07/2019

Jothaz

Só completando a resposta da Stella Oliveira, a pergunta não esta clara ser for log ou trilha de auditoria o caminho é o indicado pela Stella.
E você pode utilizar triggers para facilitar sua vida.

Agora se for alterações estruturais, seria necessário ser mais claro e nos dar mais informações de seu ambiente.


Responder

23/07/2019

Glauco

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?
Responder
No caso se você está dizendo em versionar ações realizadas no banco (pelo usuário), se trata de auditoria mesmo.
Agora se são ações realizadas por desenvolvedores (versionamento) eu geralmente faço controle por uma tabela de log, cada ação do desenvolvedor só é permitida (em produção) depois de uma requisição liberada para o ID do mesmo.
Responder

27/07/2019

Glauco

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?


Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.

Onde eu trabalho,também é desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore
Responder

27/07/2019

Glauco

No caso se você está dizendo em versionar ações realizadas no banco (pelo usuário), se trata de auditoria mesmo.
Agora se são ações realizadas por desenvolvedores (versionamento) eu geralmente faço controle por uma tabela de log, cada ação do desenvolvedor só é permitida (em produção) depois de uma requisição liberada para o ID do mesmo.

Seria um pensamento de desenvolvedor.
Responder

29/07/2019

Jothaz

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?


Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.

Onde eu trabalho,também é desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore


Em bancos de produção os backups tem um periodicidade o que mantém a estrutura atualizada.

Normalmente em ambiente de homologação os backups são esparsos e como normalmente é um ambiente "sem dono", a probabilidade de dar merda é grande.
Normalmente faço um backup ou gero um script da estrutura do banco de dados e versiono.

Como o BD não sofre tanta modificações assim, acaba que não temo muitas versões.

Migrations é uma mão na roda, uso no Ruby e no .Net e facilita a vida, agora a equipe tem de estar ciente de como usar para evita problemas.










Responder

29/07/2019

Glauco

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?


Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.

Onde eu trabalho,também é desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore


Em bancos de produção os backups tem um periodicidade o que mantém a estrutura atualizada.

Normalmente em ambiente de homologação os backups são esparsos e como normalmente é um ambiente "sem dono", a probabilidade de dar merda é grande.
Normalmente faço um backup ou gero um script da estrutura do banco de dados e versiono.

Como o BD não sofre tanta modificações assim, acaba que não temo muitas versões.

Migrations é uma mão na roda, uso no Ruby e no .Net e facilita a vida, agora a equipe tem de estar ciente de como usar para evita problemas.












Quais problema, poderiam ocorre que vocÊ tem ciência?
Responder

29/07/2019

Jothaz

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?


Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.

Onde eu trabalho,também é desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore


Em bancos de produção os backups tem um periodicidade o que mantém a estrutura atualizada.

Normalmente em ambiente de homologação os backups são esparsos e como normalmente é um ambiente "sem dono", a probabilidade de dar merda é grande.
Normalmente faço um backup ou gero um script da estrutura do banco de dados e versiono.

Como o BD não sofre tanta modificações assim, acaba que não temo muitas versões.

Migrations é uma mão na roda, uso no Ruby e no .Net e facilita a vida, agora a equipe tem de estar ciente de como usar para evita problemas.



Quais problema, poderiam ocorre que vocÊ tem ciência?


Talvez eu tenha me expressado mal, o correto nem seria problemas, mas mau uso.

Em equipes pequenas é mais fácil disseminar o rito de manter tudo sempre atualizado e sempre buscar a última versão do que vai ser alterado, antes de efetuar qualquer mudança. E sempre efetuar os commits ou no caso das migrations o UpdateDataBase.
Em equipes grandes ou fábricas de software pode acontecer de algum meliante pular alguma etapa e gerar conflitos, por não ter seguido os passo acima. Ou mesmo excluir alguma migration na mão seja no BD ou no projeto da aplicação. E isto pode gerar vários transtornos, principalmente no ambiente de produção. Pois em algumas empresas a publicação em produção é bem burocrática ou mesmo limitada por processos quase ritualísticos.

No final é mais uma sintonia final no time e todos compreenderem que os processos devem ser seguidos.

Claro que tudo que foi exposto acima é contornável com o versionamento e restore de backup. Contudo, por experiência própria restaurar um backup dependendo do contexto é osso.

Só mais uma coisa o time tem de ficar experto com cascade delete, pois se usado de forma equivocada pode fazer um limpa nos dados indevidamente.

Como eu já disse seja prudente e faça backups de tudo, pois é mais fácil limpar backups inúteis que não tê-los em caso de necessidade.








Responder

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários. Para saber mais sobre o uso de cookies,
consulte nossa política de privacidade. Ao continuar navegando em nosso site, você concorda com a nossa política.

Aceitar