Início / dba / Perguntas / 114580
Accepted
Schwarz
Asked: 2015-09-10 06:26:58 +0800 CST

Melhor maneira de projetar um banco de dados e uma tabela para manter registros de alterações?

  • 772

Eu preciso configurar um recurso de histórico em um projeto para acompanhar as alterações anteriores.

Digamos que eu tenha duas tabelas agora:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Exemplo: Tenho uma linha em notas e o usuário deseja alterar a mensagem. Eu quero manter o controle de seu estado antes da mudança e depois da mudança.

Qual seria a melhor abordagem para configurar uma coluna em cada uma dessas tabelas que dirá se um item é "antigo". 0 se ativo OU 1 se excluído/invisível.

Eu também quero criar uma AUDIT TRAILtabela de histórico ( ) que contém o idestado anterior, ido novo estado, a qual tabela esses ids se relacionam?

mysql database-design

2 respostas

  1. Ao projetar recursos de versão em seus dados, existem vários requisitos mínimos (eu acho):

    • Cada versão dos dados deve ser independente e independente de outras versões. Isso significa que nenhum sinalizador ou outro indicador mostra qual é a versão atual e quais são "históricos". Isso também significa que atualizar a entidade significa inserir apenas uma nova versão - sem necessidade de atualização de versões anteriores.
    • Evite o que chamo de dependência de extensão de linha. É aí que um campo (End_Date) de uma linha deve permanecer sincronizado com outro campo (Start_Date) de uma linha diferente. Isso torna o trabalho com os dados mais difícil e é uma excelente fonte de anomalias.
    • A versão atual e todas as versões anteriores devem estar na mesma tabela. Isso possibilita usar a mesma consulta para visualizar dados anteriores "a partir de" uma determinada data e visualizar os dados atuais.
    • As chaves estrangeiras para dados que foram versionados devem funcionar da mesma forma que os dados normais (não versionados).
    • O design deve ser tão simples ou universalmente entendido que a curva de aprendizado para novos desenvolvedores seja minimizada.

    Aqui estão os slides de uma apresentação que fiz algumas vezes em feiras de tecnologia. Abrange como todos os itens acima podem ser feitos. E aqui está um documento que entra em mais detalhes. Devo pedir desculpas pelo documento - é um trabalho em andamento e nem todas as seções estão concluídas. Mas ele deve fornecer todas as informações necessárias para implementar qualquer coisa, desde simples controle de versão até acesso bitemporal completo.

    • 16
  2. Best Answer

    Por favor veja

    http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

    É uma leitura muito boa sobre as abordagens para criar uma trilha de auditoria em seu design de banco de dados. Trilhas de auditoria são necessárias para a implementação de um banco de dados. Você deve sempre poder ver as ações dos usuários do banco de dados dentro do sistema.

    Podemos rastrear quais linhas foram alteradas quando em nosso sistema PTA (Point in Time) adicionando algumas colunas PTA (point in time) padrão a todas as tabelas de interesse do PTA.

    Sugiro o seguinte:

    DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.
    • 6

relate perguntas