Valew pessoal!
Acho que talvez dê para unificar as duas idéias, duplicar cada tabela,
porém, sem chaves estrangeiras e uma nova chave primária. Assim posso salvar
somente os campos que realmente foram alterados, economizando espaço.

O problema agora é a trigger, pois meu banco não está preparado para
usuários, ou seja, acabo sempre por usar um mesmo usuário e nenhum controle
disso no SGBD.

Hoje todas as inserções/alterações/exclusões são feitas por procedures,
talvez seja melhor criar uma nova procedure que se encarregue dessa
comparação e salve os dados alterados na tabela temporal. Assim posso
chamá-la dentro das funções existentes.

Bom acho que é isso, novamente muito obrigado pela força! Vou dar uma
pensada e desenvolver :)


Jorge Vilela.

On 6/5/07, Leonardo Cezar <[EMAIL PROTECTED]> wrote:

On 6/5/07, Jorge Vilela <[EMAIL PROTECTED]> wrote:

> Olá pessoal! Há tempos eu estou precisando implantar nos meus sistemas
uma
> forma de salvar os dados do update.

> Gostaria de saber de vocês,  qual foi é melhor solução encontrada por
cada
> um, para que não se percam os dados antigos em um update.

Extrair apenas a informação necessária das tabelas envolvidas e
armazenar em local separado.

> Pensei no seguinte:
>
> Salvar numa tabela de logs o SQL gerado no UPDATE.

Essa solução é inútil. Pense para recuperar ou pesquisar neste
histórico daqui a 10.000.000 de inclusões.

> Mover o registro para um schema separado, e então executar o update no
> registro da tabela original.

Talvez, mas de fato é necessário, dentro de sua política de auditoria,
que *todos* os valores de todos os campos de seu registro sejam
copiados?

> *.Poderia criar uma trigger nas tabelas para que seja executada a opção
2,
> mas assim não poderei ligar isso ao ID do usuário que realizou a ação
(Não
> sei se estou certo sobre isso).

Pode sim. CURRENT_USER dá essa possibilidade pra você. Desta forma
você pode criar dentro de sua procedure uma verificação do usuário
conectado e então aplicar as regras pra ele.

> Qual das duas seria a melhor forma? Ou alguém conhece alguma opção mais
> adequada?

Aquela que melhor se enquadra dentro da política de segurança da
auditoria de sua empresa/cliente. Consulte-os.

Abraco!

-Leo
--
Leonardo Cezar
http://www.hostsystems.com.br
http://www.postgresql.org.br
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a