Existe um mecanismo de armazenamento de banco de dados de controle de versão?

Question

Eu estava me perguntando se existia um tipo de mecanismo de armazenamento que permitisse fazer o controle de versão no conteúdo em nível de linha.Por exemplo, se eu tiver uma tabela simples com ID, nome, valor e ID é o PK, posso ver que a linha 354 começou como (354, "zak", "test")v1 e foi atualizada para ser (354, "zak", "esta é a versão 2 do valor")v2 e poderia ver um histórico de alterações na linha com algo como selecionar histórico (valor) onde ID = 354.

É uma coisa meio esotérica, mas seria melhor do que ter que continuar escrevendo essas tabelas e funções de histórico separadas toda vez que uma alteração é feita...

Answer 1

Parece que você está procurando mais recursos de auditoria. O Oracle e vários outros DBMs têm recursos completos de auditoria. Mas muitos DBAs ainda acabam implementando a auditoria de linha baseada em gatilho. Tudo depende das suas necessidades.

O Oracle suporta várias granularidades de auditoria que são fáceis de configurar na linha de comando.

Vejo que você marcou como MySQL, mas perguntou sobre qualquer mecanismo de armazenamento. De qualquer forma, outras respostas estão dizendo a mesma coisa, então eu vou excluir este post, pois originalmente era sobre os recursos de flashback.

Answer 2

Obviamente você está realmente atrás de uma solução MySQL, então isso provavelmente não irá ajudá-lo muito, mas a Oracle tem um recurso chamado Total Recall (mais formalmente Flashback Archive) que automatiza o processo que você está executando manualmente.O Arquivo é um conjunto de tabelas compactadas que são preenchidas com alterações automaticamente e podem ser consultadas com um simples AS OF sintaxe.

Naturalmente sendo Oracle eles cobram por isso:infelizmente, ele precisa de uma licença adicional além da Enterprise Edition. Saiba mais (PDF).

Answer 3

Oracle e SQL Server chamam esse recurso Change Data Capture. Não há equivalente para o MySQL neste momento.

Answer 4

Você pode alcançar um comportamento semelhante com os gatilhos (pesquise "gatilhos para capturar todas as mudanças no banco de dados") - principalmente se eles implementarem o SQL92 INFORMATION_SCHEMA.

Caso contrário, eu concordo com Mrjoltcola

EDIT: O único Gotcha que eu mencionei com o MySQL e os gatilhos é que (na versão mais recente da comunidade que eu baixei) Requer que a conta de usuário tenha o SUPER privilégio, o que pode tornar as coisas um pouco feias

Answer 5

O CouchDB tem uma versão completa para todas as mudanças feitas, mas faz parte do mundo NoSQL, então provavelmente seria uma mudança bastante louca do que você está fazendo atualmente.

Answer 6

o Artigo da Wikipedia No BigTable mencionado do Google, ele permite a versão adicionando uma dimensão de tempo às tabelas:

Cada tabela possui várias dimensões (uma das quais é um campo para o tempo, permitindo o versão).

Também existem links para várias implementações que não são do Google de um DBMS do tipo BigTable.

Answer 7

Eu acho que a grande mesa, o mecanismo do Google DB, faz algo assim: associa um registro de data e hora a cada atualização de uma linha.

Talvez você possa experimentar o Google App Engine.

Existe um artigo do Google explicando Como a grande mesa funciona.

Answer 8

O livro Refatorando bancos de dados Tem algumas idéias sobre o assunto.

Mas também aponta que não existe uma solução real atualmente, além de fazer alterações cuidadosamente e gerenciá -las manualmente.

Answer 9

Uma aproximação a isso é um banco de dados temporal - que permite ver o status de todo o banco de dados em momentos diferentes no passado. Não tenho certeza de que responda totalmente sua pergunta; Não permitiria que você visse o conteúdo da linha 1 no tempo T1, enquanto simultaneamente permite olhar para o conteúdo da linha 2 em um horário separado T2.

Answer 10

"É uma coisa meio esotérica, mas seria melhor do que ter que continuar escrevendo essas tabelas e funções de histórico separadas toda vez que uma alteração é feita..."

Eu não chamaria as trilhas de auditoria (que é obviamente disso que você está falando) de "coisa esotérica" ​​...

E :ainda há uma diferença entre a história das atualizações do banco de dados e a história da realidade.As tabelas históricas do banco de dados deveriam realmente ser usadas para refletir a história da realidade, NÃO o histórico de atualizações do banco de dados.

O histórico de atualizações do banco de dados já é mantido pelo SGBD em seus logs e diários.Se alguém precisar consultar o histórico de atualizações do banco de dados, então ele/ela deveria realmente recorrer aos logs e diários, e não a qualquer tipo de construção em nível de aplicativo que possa NUNCA fornecer garantia suficiente de que reflete TODOS atualizações.