Controlador de vers�o SQL

Question

Boa tarde a  todos, como voc�s fazem o controle de vers�o das altera��es em banco de dados em projeto mais robusto?...

Jothaz · Accepted Answer

[quote]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 f...

Stella Oliveira · Answer

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 !

Jothaz · Answer

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.

Glauco · Answer

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 ?

Stella Oliveira · Answer

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.

Glauco · Answer

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.[/quote]Onde eu trabalho,tamb�m � desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore...

Glauco · Answer

Seria um pensamento de desenvolvedor....

Jothaz · Answer

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.[/quote]Onde eu trabalho,tamb�m � desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore[/quote]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. ...

Glauco · Answer

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.[/quote]Onde eu trabalho,tamb�m � desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore[/quote]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. [/quote]Quais problema, poderiam ocorre que voc� tem ci�ncia?...

Jothaz · Answer

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.[/quote]Onde eu trabalho,tamb�m � desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore[/quote]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.[/quote]Quais problema, poderiam ocorre que voc� tem ci�ncia?[/quote]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 atualizad...