Melhor projeto para uma tabela de banco de dados changelog / auditoria? [fechadas]

Question

Eu preciso criar uma tabela de banco de dados para armazenar log de alterações diferente / auditoria (Quando alguma coisa foi adicionada, suprimida, modificados, etc). Eu não precisa armazenar informações particularmente detalhadas, então eu estava pensando algo ao longo das linhas de:

• id (por evento)
• user que desencadeou
• nome do evento
• descrição de evento
• timestamp do evento

Estou faltando alguma coisa aqui? Obviamente, eu posso continuar a melhorar o design, embora eu não planejo fazer isso complicado (criando outras tabelas para tipos de eventos ou coisas desse tipo está fora de questão, já que é uma complicação para minha necessidade).

Answer 1

No projeto que estou trabalhando, log de auditoria também iniciado a partir do design muito minimalista, como o que você descreveu:

event ID
event date/time
event type
user ID
description

A ideia era a mesma: para manter as coisas simples.

No entanto, tornou-se rapidamente evidente que este design minimalista não foi suficiente. A auditoria típico estava fervendo para baixo para perguntas como esta:

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

Assim, a fim de ser capaz de responder a tais perguntas rapidamente (usando SQL), acabámos por ter duas colunas adicionais na tabela de auditoria

object type (or table name)
object ID

Foi quando design do nosso log de auditoria realmente estabilizados (por alguns anos agora).

É claro, o último "melhoria" só funcionaria para tabelas que tiveram chaves substitutas. Mas adivinhem? Todas as nossas mesas que valem a pena auditoria tem tal chave!

Answer 2

Existem várias outras coisas que você pode querer de auditoria, tais como nomes de tabela / coluna, computador / aplicativo a partir do qual foi feita uma atualização, e muito mais.

Agora, isso depende de como auditoria detalhada que você realmente precisa e em que nível.

Começamos a construir nossa própria solução de auditoria baseada em gatilho, e queríamos auditoria tudo e também tem uma opção de recuperação na mão. Este acabou por ser muito complexa, então acabamos engenharia reversa do-gatilho base, ferramenta de terceiros ApexSQL auditoria para criar nossa própria solução personalizada.

Dicas:

• Incluir antes / depois os valores

• Inclua 3-4 colunas para armazenar a chave primária (no caso, é uma chave composta)

• Armazenar dados fora do banco de dados principal como já foi sugerido por Robert

• Passe uma quantidade razoável de tempo na elaboração de relatórios - especialmente aqueles que você pode precisar para recuperação

• Plano para armazenar o nome do host / aplicação - isto pode vir muito útil para monitorar atividades suspeitas

Answer 3

Nós também log valores antigos e novos e a coluna são de, bem como a chave primária do ser tabela de auditoria em uma tabela de detalhes de auditoria. Pense o que você precisa a tabela de auditoria para? Não somente você quer saber quem fez uma mudança e quando, mas quando uma má mudança acontece, você quer uma maneira rápida de colocar nas costas de dados.

Enquanto você está projetando, você deve escrever o código para recuperar dados. Quando você precisar recuperar, é geralmente com pressa, melhor para já estar preparado.

Answer 4

Existem muitas respostas interessantes aqui e em questões semelhantes. As únicas coisas que posso acrescentar a partir da experiência pessoal são:

1. Coloque sua tabela de auditoria em outro banco de dados. Idealmente, você quer a separação a partir dos dados originais. Se você precisar restaurar seu banco de dados, você realmente não quer restaurar a trilha de auditoria.

2. desnormalizar tanto quanto razoavelmente possível. Você quer que a tabela tem o menor número de dependências quanto possível para os dados originais. A tabela de auditoria deve ser simples e muito rápido para recuperar dados. Sem fantasia junta ou pesquisas através de outras tabelas para obter os dados.

Answer 5

O que temos em nossa mesa: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

Os pontos id genéricos em uma linha na tabela que foi atualizado eo nome da tabela é o nome que a tabela como uma string. Não é um projeto DB bom, mas muito utilizável. Todas as nossas mesas têm uma coluna de chave substituta único modo que este funciona bem.

Answer 6

Existem muitas maneiras de fazer isso. Minha maneira favorita é:

1. Adicionar um campo mod_user à sua tabela de origem (o que deseja fazer logon).

2. Criar uma tabela log que contém os campos que deseja registrar, além de um campo log_datetime e seq_num. seq_num é a chave primária.

3. Criar um gatilho na tabela de origem que insere o registro atual na tabela de log sempre que qualquer campo monitorado é alterado.

Agora você tem um registro de cada mudança e que o fez.

Answer 7

Na auditoria costume geral (criando várias tabelas) é uma má opção. gatilhos de banco de dados / tabela pode ser desativado para pular algumas atividades de log. tabelas de auditoria personalizado pode ser adulterado. Exceções podem ocorrer que vai derrubar aplicação. Não menciona dificuldades projetar uma solução robusta. Até agora eu vejo uma forma muito simples casos nesta discussão. Você precisa de uma completa separação de banco de dados atual e de quaisquer usuários privilegiados (DBA, Desenvolvedores). A cada RDBMSs tradicionais fornecem recursos de auditoria que mesmo DBA não capaz de desativar, adulteração em sigilo. Portanto, capacidade de auditoria fornecida pelo fornecedor de RDBMS deve ser a primeira opção. Outra opção seria a 3ª leitor de log de transações partido ou log personalizado leitor que empurra decomposto informações no sistema de mensagens que acaba em algumas formas de Auditoria Data Warehouse ou manipulador de eventos em tempo real. Em resumo: Solution Architect / "Mãos na Data Architect" precisa envolver em destinando tal sistema com base em requisitos. É o material geralmente muito grave apenas para entregar a uma desenvolvedores de solução.

Answer 8

De acordo com o princípio da separação:

1. tabelas de dados Auditoria precisa ser separado do banco de dados principal. Como bancos de dados de auditoria pode ter um monte de dados históricos, não faz sentido do ponto de vista de utilização de memória para mantê-los separados.

2. Não use gatilhos para auditar todo o banco de dados, porque você vai acabar com uma confusão de diferentes bancos de dados de suporte. Você terá que escrever um para DB2, SQLServer, MySQL, etc.

Answer 9

atrasado para a festa, mas eu recomendo o AutoAudit projeto .
É 100% livre e open source. É de autoria de SQL MVPs Paul Nielsen e John Sigouin. É muito estável e está atualmente na versão 3.30.

Simples de instalar. Basta executar o SP que eles fornecem. Ele vai criar um esquema de Auditoria, alguns SPs manutenção e os gatilhos necessários para fazer a auditoria. A partir daí, basta escolher as tabelas que você gostaria de auditoria e com que detalhe.