Início / dba / Perguntas / 25695
Accepted
leeand00
Asked: 2012-10-10 09:20:56 +0800 CST

Como os logs de transações são inseridos?

  • 772

Eu tenho um banco de dados ms-access no trabalho que possui uma tabela que é um log de transações.

A tabela contém os seguintes campos:

Data - A data em que a transação ocorreu.

  • Table_Name - Nome da tabela na qual o campo foi alterado.
  • Table_Field - O campo na tabela que foi alterado.
  • Old_Value - O valor original do campo (se houver).
  • New_Value - O novo valor do campo que foi definido durante esta transação.

Agora, em uma tabela de log de transações como esta, esses registros normalmente são definidos pela API de programação do sistema que modifica o banco de dados, uma função do próprio banco de dados ou são acionados por algo como um gatilho de banco de dados? Ou isso depende do rdbms que está sendo usado?

rdbms transaction-log

1 respostas

  1. Best Answer

    Em primeiro lugar, o termo correto para isso é tabela de auditoria (ou talvez histórico de auditoria). O log de transações é algo totalmente diferente (que é uma parte central do DBMS que registra todas as transações ativas para garantir as propriedades ACID) - o log de transações do DBMS (que está em um formato binário muito difícil de ler) é reutilizado uma vez que é não é mais necessário ("uma vez que não é mais necessário" é um pouco vago, mas uma dissertação completa sobre a semântica do log de transações está um pouco além do escopo desta resposta), onde um histórico de auditoria permanece para sempre, contanto que você não limpe a mesa.

    Para responder à pergunta real - isso deve ser feito dentro do banco de dados (os gatilhos são a maneira mais fácil). A razão básica para isso é que você deseja que qualquer coisa que seja parte integrante dos dados (ou seja, restrições, regras de segurança, histórico de auditoria etc.) aconteça, não importa qual aplicativo esteja usando o banco de dados.

    Adicionalmente:

    • Que tipo de dados você está usando para os campos Old_Valuee ?New_Value
    • O estilo da tabela de auditoria que você está usando levará a uma linha na tabela para cada campo de cada linha que você inserir/atualizar/excluir, o que significa que sua tabela de histórico de auditoria crescerá tão rápido quanto todas as outras tabelas juntas (e mais algumas). Você precisará ficar de olho nele para garantir que não saia do controle (recomendo limpar a mesa periodicamente - somente depois de fazer o backup, é claro).
    • Outra opção (que eu provavelmente usaria se você precisar consultar o histórico de auditoria com frequência) é ter uma tabela de auditoria para cada tabela em seu banco de dados - portanto, se você tiver Person(ID, Name), terá audit_Person(whoChanged, whenChanged, ID, Name), e, em atualização ou exclusão, armazene o estado da linha antes da alteração (não precisa inserir porque basta procurar na tabela o estado atual), juntamente com o login do usuário que a alterou e a hora.
      • Isso significa que não há mais tabelas de auditoria com 2 bilhões de linhas e torna a consulta do histórico de auditoria significativamente mais intuitiva (você obtém linhas inteiras de volta em uma única peça, em vez de ter que ir campo por campo), mas tem a desvantagem de duplicar alterações de esquema ( se você adicionar uma coluna a Person, também precisará adicioná-la a 'audit_Person') e possivelmente sendo maior em geral do que a abordagem de tabela única.
    • 3

relate perguntas