Caríssimo,
Atento o fim em vista eu decidir-me-ia pelo:1- Uso de trigger(via banco),
armazenando os valores em uma tabela de histórico.
Você também poderia faze-lo na mesma tabela, mas isso para além de aumentar
consideravelmente o tamanho da mesma tem a desvantagem de uma entual de
perda de desempenho.
De qualquer forma você teria ainda que criar dois campos: um RStat=
"I"nsert, "U"pdate ou "D"elete(se bem me lembro desviava o delete com "*do
instead*" para flagar o registo apenas sem o matar), e um outro, do tipo
smallint Histórico em que =0(zero) significa sempre registo em vigor e
1...2...3...4 etc registos alterados; depois
a Primary Key teria o Campo de Controlo+Histórico em que Histórico serve
exatamente para desempatar as chaves repetidas para o mesmo registo vivo.
Depois no SQL. você controlo o resto. Como uso Delphi não fazia o filtro no
SQL, mas no cliente, no evento OnFilterRecord: Accept:= CampoHistorico=0 e
no Botão
If DBNavTblX.DataSource.DataSet.Filtered Then
DBNavTblX.DataSource.DataSet.Filtered:=False
Else
DBNavTblX.DataSource.DataSet.Filtered:=True; // e é muito rápido
mostrar e esconder o Histórico.
Se fosse para o utilizador final ter acesso ao Histórico, se optasse por
faze-lo na própria tabela, você ganhava nos tempo de acesso, mas ainda
assim teria de ponderar isso muito bem face ao que ganha e perde em cada
abordagem...faça uns testes...
Muitas vezes aquilo que não é para o "utilizador final" ter acesso "hoje",
pode muito bem, "amanhã" ser uma necessidade real e concreta da sua
aplicação, até porque as aplicações com Histórico, em que o end-user pode
ver os erros que o próprio cometeu são em via de regra melhor aceites e
consideradas igualmente mais seguras ainda que isso seja, obviamente,
discutível.
Sendo esta a decisão, claro que terá ainda que guardar o "UserName" a
"Data" a "Hora"(timestamp) e quiçá a "Estacao" ou o respectivo IPAdress, ou
ambos!
Todavia, como faz algum tempo que não trabalho com o PostgreSql escute
outras opiniões.
Espero ter ajudo alguma coisa.
Abraços
Com os meus melhores cumprimentos
O Secretário Geral da ACRA
Mário Agostinho Reis
Esta mensagem contém informação de natureza confidencial e é
exclusivamente dirigida ao(s) destinatário(s) indicado(s). Se, por engano,
receber este email agradecemos que não o copie nem o reenvie e que nos
notifique do ocorrido através do email de resposta.
No dia 11 de Junho de 2013 às 16:29, Luciano Bierhals
<[email protected]>escreveu:
> Pessoal,
>
> Não trabalho a muito tempo com postgresql, e estou precisando implementar
> uma política de histórico de alterações em algumas tabelas. Em resumo, eu
> preciso guardar toda e qualquer alteração em um registro de tabela de
> produção.
>
> Fiz algumas pesquisas e vi como mais habitual, duas abordagens:
>
> 1- Uso de trigger(via banco), armazenando os valores em uma tabela de
> histórico.
> 2- Uso de arquivo XML(via aplicação) com todos os dados do registro,
> persistindo em uma tabela única. Poderia inclusive usar o tipo de dado XML,
> disponívels nas últimas versões do PG.
>
> Gostaria da colaboração de vocês para identificar prós e contras de cada
> abordagem, ou mesmo sugestões de outras abordagens.
>
> Informações adicionais:
>
> -A consulta nas tabelas de histórico não serão disponibilizadas ao usuário
> final.
> -Consultas nas tabelas de histórico, não serão frequentes. Servirão mais
> para auditorias, ou verificações pontuais.
>
>
> Agradeço antecipadamente pela colaboração.
>
> Abraços,
> Luciano Bierhals
>
> _______________________________________________
> 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
