tabelas de histórico prós, os contras e Armadilhas - usando gatilhos, sproc ou a nível da aplicação [fechado]

Question

Atualmente, estou a brincar com a idéia de ter tabelas de histórico para algumas das minhas tabelas no meu banco de dados. Basicamente, eu tenho a mesa principal e uma cópia dessa tabela com uma data de modificação e uma coluna de ação a loja que ação foi realizada por exemplo, update, delete e Insert.

Até agora eu posso pensar em três lugares diferentes que você pode fazer o trabalho tabela de histórico.

• Triggers na mesa principal para atualização, inserção e exclusão. (Banco de dados)
• procedimentos armazenados. (Banco de dados)
• camada de aplicação. (Application)

A minha pergunta principal é, quais são os prós, contras e Armadilhas de fazer o trabalho em cada uma dessas camadas.

Uma vantagem que eu posso pensar, usando o caminho gatilhos é que a integridade está sempre mantida independentemente do programa que está implmentated em cima do banco de dados.

Answer 1

eu colocar desta forma:

• procedimentos armazenados: que está contornado se você modificar a tabela diretamente. Segurança no banco de dados pode controlar este
• aplicação: mesmo negócio. Além disso, se você tem múltiplas aplicações, possivelmente em diferentes idiomas, ele precisa ser implementado em cada pilha, que é um pouco redundante; e
• Triggers: transparente para o aplicativo e irá capturar todas as alterações. Este é o meu método preferido.

Answer 2

Os gatilhos são a maneira mais rápida e mais fácil de conseguir história simples. As informações a seguir assume um exemplo mais complexo onde o processamento história pode incluir algumas regras de negócio e pode exigir informações de registro não encontrado na tabela que está sendo rastreado.

Para aqueles que pensam que gatilhos são mais seguros do que sprocs, porque não pode ser ignorada eu lembrá-los que eles estão fazendo o seguinte suposição:

!

) Permissões que existem usuários de parada de executar DISABLE TRIGGER [mas depois permissões poderia também existir para limitar todo o acesso ao banco de dados exceto para EXECUTE em sprocs que é um padrão comum para aplicações empresariais] -, portanto, deve-se assumir permissões corretas e portanto, sprocs igual gatilhos em termos de segurança e capacidade de ser ignorada

!) Dependendo do banco de dados que pode ser possível para executar atualização declarações que não fazer gatilhos de fogo. Eu poderia tirar proveito do conhecimento de profundidade a execução do gatilho aninhada para ignorar um gatilho. A solução única certeza inclui segurança no banco de dados e limitar o acesso a dados usando mecanismos única aprovados -. Sejam estes gatilhos, sprocs ou camadas de acesso a dados

Eu acho que as escolhas são claras aqui. Se os dados estão sendo acessados ??por vários aplicativos, então você deseja controlar a história da camada mais baixa comum e isso vai significar o banco de dados.

Seguindo a lógica acima, a escolha de gatilhos ou procedimentos armazenados depende novamente sobre se o procedimento armazenado é a camada mais baixa comum. Você deve preferir o sproc sobre o gatilho como você pode controlar o desempenho, e os efeitos colaterais melhor e o código é mais fácil de manter.

Os gatilhos são aceitáveis, mas tente se certificar de que você não aumentar fechaduras lendo fora de dados das tabelas sendo atualizado. Disparadores limite para inserções nas tabelas log, apenas o que você precisa.

Se o aplicativo usa uma camada de acesso lógica comum e é improvável que isso iria mudar ao longo do tempo eu preferiria para implementar a lógica aqui. Use um Chain of Responsibility e uma arquitetura plug-in, dirigir isto de Dependency Injection para permitir a todos os tipos de processamento em você módulo de história, incluindo o registo completamente diferentes tipos de tecnologia, bancos de dados diferentes, um serviço de história ou qualquer outra coisa que você poderia imaginar.

Answer 3

Foram utilizando a abordagem baseada gatilho durante anos e tem definitivamente funcionou bem para nós, mas então você tem os seguintes pontos a ponderar sobre: ??

1. Triggers em um muito utilizada (por exemplo, uma aplicação de SaaS multi-tenant com base) pode ser extremamente caro

2. Em alguns cenários, alguns campos podem se redundante. Triggers são bons apenas quando estiver claro sobre os campos que estar conectado; embora usando um aplicativo que você poderia ter uma camada interceptor que poderia ajudá-lo a iniciar sessão certos campos com base na "configuração"; embora com a sua própria quota de despesas gerais

3. Sem o controle do banco de dados adequada, uma pessoa poderia facilmente desativar os gatilhos, modificar os dados e permitir que os gatilhos; tudo sem levantar quaisquer alarmes

4. Em caso de aplicações web, onde as conexões são estabelecidas a partir de uma piscina, acompanhando a usuários reais que fizeram as mudanças pode ser tedioso. Uma possível solução seria a de ter o campo "EditedBy" em cada mesa transação.

Answer 4

uma tarde, mas ele adiciona mais algumas opções que podem ser consideradas.

Change Data Capture: Este recurso está disponível no SQL Server 2008 R2 +, mas apenas em edição de empresa. Ele permite que você selecione as tabelas que você deseja acompanhar e SQL Server irá fazer o trabalho para você. Ele funciona através da leitura do log de transações e preencher tabelas de histórico com os dados.

log de transações de leitura: Se banco de dados está em modo de recuperação completa, em seguida, log de transações podem ser lidos e detalhes sobre quase transações podem ser encontrados.

desvantagem é que este não é suportado por padrão. As opções são para ler log de transações usando funções indocumentados como ferramentas fn_dblog ou terceiros, como ApexSQL Log .

Triggers: funciona muito bem para pequeno número de mesas onde não há também muitos gatilhos para gerenciar. Se você tem um monte de tabelas que você quer auditoria, em seguida, você deve considerar alguns ferramenta de terceiros para isso.

Todos estes trabalhos no nível de banco de dados e são completamente transparentes para aplicação.

Answer 5

Os gatilhos são a única maneira confiável de mudanças de captura. Se você fazê-lo em procedimentos armazenados ou a App, você sempre pode entrar e SQL afastado uma mudança que você não tem um registro de (inadvertidamente). Claro, alguém que não quer deixar um registro pode desativar os gatilhos. Mas você preferir forçar alguém para desativar o registro de esperança de que eles não se esqueça de incluí-lo.

Answer 6

Normalmente, se você escolher a camada de aplicação, você pode projetar seu código de aplicativo para fazer o registro em um único ponto, que irá lidar com consistenly toda a sua tabela de histórico. diferente gatilhos são uma abordagem mais complicado de manter, porque eles são (dependendo da tecnologia db) replicados para cada mesa: em caso de centenas de tabelas a quantidade de código para o gatilho ter precisado ser um problema.

Se você tem uma organização de apoio que irá manter o código que você está escrevendo agora, e você não sabe quem irá manter o seu código (típico para grandes indústrias) você não pode assumir que é o nível de habilidade da pessoa que vai fazer correção em sua aplicação, nesse caso, é melhor na minha opinião para fazer a tabela histórica princípio de funcionamento o mais simples possível, e a camada de aplicação é provavelmente o melhor lugar para esta finalidade.