Melhor design para uma tabela de banco de dados de log de mudanças / auditoria? [fechadas]

Eu preciso criar uma tabela de banco de dados para armazenar log de alterações / auditoria diferentes (quando algo foi adicionado, excluído, modificado, etc). Não preciso armazenar informações particularmente detalhadas, então estava pensando em algo como:

• id (para evento)
• usuário que o acionou
• nome do evento
• Descrição do Evento
• carimbo de data / hora do evento

Estou faltando alguma coisa aqui? Obviamente, posso continuar melhorando o design, embora não planeje complicá-lo (criar outras tabelas para tipos de eventos ou coisas assim está fora de questão, pois é uma complicação para a minha necessidade).

No projeto em que estou trabalhando, o registro de auditoria também começou a partir de um design minimalista, como o que você descreveu:

event ID
event date/time
event type
user ID
description

A ideia era a mesma: manter as coisas simples.

No entanto, rapidamente se tornou óbvio que esse design minimalista não era suficiente. A auditoria típica se resumia a perguntas como esta:

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

Então, para poder responder a essas perguntas rapidamente (usando SQL), acabamos tendo duas colunas adicionais na tabela de auditoria

object type (or table name)
object ID

Foi quando o design de nosso registro de auditoria realmente se estabilizou (por alguns anos agora).

É claro que a última "melhoria" funcionaria apenas para tabelas que tivessem chaves substitutas. Mas adivinha? Todas as nossas tabelas que valem a pena auditar possuem essa chave!

Também registramos valores antigos e novos e a coluna de onde eles vêm, bem como a chave primária da tabela que está sendo auditada em uma tabela de detalhes de auditoria. Pense no que você precisa da tabela de auditoria? Você não quer apenas saber quem fez uma alteração e quando, mas quando uma alteração ruim acontece, você quer uma maneira rápida de colocar os dados de volta.

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

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

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

Começamos a construir nossa própria solução de auditoria baseada em gatilhos e queríamos auditar tudo e também ter uma opção de recuperação em mãos. Isso acabou sendo muito complexo, então acabamos fazendo a engenharia reversa da ferramenta ApexSQL Audit baseada em gatilhos para criar nossa própria solução personalizada.

Dicas:

• Incluir valores antes / depois

• Incluir 3-4 colunas para armazenar a chave primária (no caso de ser uma chave composta)

• Armazene dados fora do banco de dados principal, conforme já sugerido por Robert

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

• Planeje armazenar o nome do host / aplicativo - isso pode ser muito útil para rastrear atividades suspeitas

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

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

2. Desnormalize tanto quanto razoavelmente possível. Você deseja que a tabela tenha o mínimo possível de dependências dos dados originais. A tabela de auditoria deve ser simples e rápida para recuperar dados. Sem junções ou pesquisas extravagantes em outras tabelas para obter os dados.

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

O id genérico aponta para uma linha na tabela que foi atualizada e o nome da tabela é o nome dessa tabela como uma string. Não é um bom design de banco de dados, mas muito utilizável. Todas as nossas tabelas têm uma única coluna de chave substituta, então isso funciona bem.

Em geral, a auditoria personalizada (criação de várias tabelas) é uma opção ruim. Os gatilhos de banco de dados / tabela podem ser desativados para pular algumas atividades de log. As tabelas de auditoria personalizadas podem ser adulteradas. Exceções podem ocorrer para desativar o aplicativo. Sem mencionar as dificuldades em projetar uma solução robusta. Até agora, vejo casos muito simples nesta discussão. Você precisa de uma separação completa do banco de dados atual e de quaisquer usuários privilegiados (DBA, Desenvolvedores). Todos os RDBMSs convencionais fornecem recursos de auditoria que nem mesmo o DBA consegue desabilitar, violar em segredo. Portanto, o recurso de auditoria fornecido pelo fornecedor de RDBMS deve ser a primeira opção. Outra opção seria um leitor de log de transações de terceiros ou um leitor de log personalizado que empurra informações decompostas em um sistema de mensagens que termina em algumas formas de Data Warehouse de auditoria ou manipulador de eventos em tempo real. Em suma: O Arquiteto de Soluções / "Arquiteto Prático de Dados" precisa se envolver no destino de tal sistema com base nos requisitos. Normalmente, é uma coisa muito séria entregar aos desenvolvedores para a solução.

Há muitas maneiras de fazer isso. Minha maneira favorita é:

1. Adicione um mod_usercampo à sua tabela de origem (aquele que você deseja registrar).

2. Crie uma tabela de registro que contenha os campos que deseja registrar, além de um campo log_datetimee seq_num. seq_numé a chave primária.

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

Agora você tem um registro de todas as alterações e de quem as fez.

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

1. As tabelas de dados de auditoria precisam ser separadas do banco de dados principal. Como os bancos de dados de auditoria podem ter muitos dados históricos, faz sentido do ponto de vista da utilização da memória mantê-los separados.

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