Como eu iria usar uma trilha de auditoria para exibição os campos que já foram editados?

Question

Para um projeto que eu estou trabalhando, me pediram para criar uma trilha de auditoria de todas as alterações que foram feitas para os registros. Esta é a primeira vez que tive para criar uma trilha de auditoria, por isso tenho vindo a fazer um monte de investigação sobre o assunto.

O aplicativo será desenvolvido em PHP / MSSQL, e será de baixo tráfego.

De minha leitura, eu praticamente decidido a ter uma tabela de auditoria e uso de gatilhos para gravar as alterações na tabela.

Os dois requisitos para exibição na aplicação são os seguintes:

1. Ser capaz de ver um log de todas as alterações feitas em um campo (eu sei muito bem como fazer isso)

2. Ser capaz de ver, ao visualizar um registro na aplicação, um indicador ao lado de qualquer campo no registro que já foi alterado (e, possivelmente, outras informações como a data da última mudança).

Item # 2 é a que está me dando dor. Sem fazer uma consulta separada para cada campo (ou uma consulta muito tempo aninhada que vai levar séculos para executar), alguém tem sugestões para um melhor maneira de fazer isso? (Eu tenho pensado de adicionar um extra campo "ModifiedFlag" para cada campo na tabela, que irá funcionar como indicador booleano se o campo já foi editado, mas que parece ser um monte de sobrecarga.

Answer 1

Eu iria tratar as informações de auditoria em separado a partir da informação de domínio real, tanto quanto possível.

Exigência # 1: Eu acho que você vai criar tabelas adicionais de auditoria para gravar as alterações. Eric sugestão é boa, criando as informações de auditoria usando disparadores no banco de dados SQL. Desta forma, sua aplicação não precisa estar ciente da lógica de auditoria.

Se o seu banco de dados não suporta gatilhos, então talvez você estiver usando algum tipo de persistência ou camada de banco de dados. Este também seria um bom lugar para colocar esse tipo de lógica, como novamente a minimizar quaisquer dependências entre normais código do aplicativo e o código de auditoria.

Exigência # 2: Como para mostrar os indicadores: Eu não iria criar campos boolean na tabela que armazena o real. (Isso faria com que todos os tipos de dependências de existir entre o normais código do aplicativo e sua trilha de auditoria código.)

Gostaria de tentar deixar o código responsável por exibir o formulário também será responsável por mostrar dados de auditoria em nível de campo. Isso fará com que consulta em cima, mas isso é o custo para exibir essa camada extra de informações. Talvez você pode minimizar a sobrecarga banco de dados adicionando metadados para as informações de auditoria que permite a fácil recuperação.

Alguns grande aplicação Enterprisy que eu manter usos mais ou menos a seguinte estrutura:

• A tabela de cabeçalho alteração corresponde a uma alteração de um registro em uma tabela.

Os campos:

changeId, changeTable, changedPrimaryKey, userName, dateTime

-. Uma tabela campo mudança correspondente a um campo que é alterado

Os campos:

changeId, changeField, oldValue, NewValue

o conteúdo da amostra:

Alterar Cabeçalho:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

Alterar Item:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

Esta estrutura permite tanto a visualização fácil de trilhas de auditoria, bem como a recuperação fácil para mostrar os indicadores desejados. Uma consulta (junção interna na tabela de cabeçalho e itens) seria suficiente para recuperar todas as informações para mostrar em um único formulário. (Ou até mesmo uma mesa quando você tem uma lista de mostra de Id)

Answer 2

Como exigência geral sinalizar campo alterado "cheira" um pouco estranho. Se os registros são de longa vida e sujeito a mudanças ao longo do tempo, em seguida, eventualmente, todos os campos tendem a ficar tão sinalizado. Daí eu me pergunto como qualquer usuário pode fazer sentido de um simples conjunto de indicadores por campo.

Essa linha de pensamento me faz suspeitar que os dados que você armazenar necessidades para ser, como você descreveu, uma trilha verdadeira auditoria com todas as mudanças registradas, e o primeiro verdadeiro desafio é decidir como a informação deve ser apresentada ao o usuário.

Eu acho que sua idéia de preparar algum tipo de dados aggregateOfTheAuditTrail é provável que seja muito útil. A questão seria uma única bandeira per suficiente recorde? Se o acesso principal do usuário é através de lista, então talvez seja suficiente apenas para destacar os registros alterados para mais tarde drill down. Ou uma data de última alteração do valor recorde, de modo que somente os registros recentemente alterados são destacadas - tudo volta ao que as reais necessidades do usuário são. Acho que é difícil imaginar que os registros mudadas 3 anos atrás são tão intersting como aqueles mudou na semana passada.

Então, quando chegamos ao baixo broca para um único registro. Novamente uma bandeira simples por campo não soa úteis (embora o seu domínio, suas necessidades). Se for, então a sua ideia resumo é bom. Meu palpite é que uma seqüência de alterações em um campo e a seqüência de mudanças globais para o registro, são muito mais interessantes. Empregado teve aumento de salário, empregado moveu departamento, empregado foi promovido = três eventos de negócios separadas ou uma?

Se mais nada do que uma bandeira simples é necessária, então eu suspeito que você só precisa voltar todo (ou recente) a trilha de auditoria para o registro e deixar a figura UI fora como apresentar isso.

Então, meu pensamento inicial: Algum tipo de rolar de manutenção de um registro sumário soa como uma boa ideia. Se necessário mantidos em tópicos de fundo ou trabalhos em lote. Nós deisgn que para ser útil business-sem ir para a trilha de auditoria completa de cada vez. Então, para análises detalhadas que permitem que algumas ou todas a trilha a ser recuperado.

Answer 3

Pessoalmente, eu fazer o simples rastreamento, e funky relatórios.

Cada vez que um usuário insere um registro, você fazer uma inserção na tabela de auditoria para essa tabela

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

Isso está supor que a estrutura das tabelas não vai mudar ao longo do tempo (re. A quantidade de DataColumns)

Para obter atualizações, basta inserir

'U', 'Date', 'User', 'Data column1', etc

Inserir o que o usuário acabou de entrar como uma atualização.

Em seguida, após a inserção e atualização, você terá a seguinte

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

Então, é apenas um relatório de fácil mostrar que o recorde de pessoa única 'person005' teve uma inserção e uma actualização, em que seu departamento foi atualizado.

Devido ao baixo uso do sistema, ter uma simples inserção na mudança, em seguida, um processo de comunicação mais complexas não está indo para o desempenho efeito. Este estilo vai ainda trabalhar com sistemas de tráfego mais elevadas, como a carga extra sobre uma edição é mínimo, enquanto que a maior carga de trabalho intensidade da relatando as mudanças não é feito tão frequentemente como uma atualização, para que o sistema não vai cair.