Jorge isso se chama banco de dados temporal. Eu tive a oportunidade ver 2 implementações disso. Uma delas foi um fracasso e a outra está nos atendendo perfeitamente até o momento.
Eu aconselho você a fazer da forma que temos aqui hoje. Para cada tabela que você quer temporizar crie um clone com um campo extra que vai ser a versão do registro. Esse campo extra não é obrigatório mas lhe ser muito útil no futuro. Em cada tabela temporizada tenha também um campo timestamp tipo "deletado_em". Assim você tem a funcionalidade de versionamento em seus registros e pode implementar até recursos como voltar um detrminado registro a uma versão anterior como fazemos aqui. On Tue, 5 Jun 2007 16:54:26 -0400, "Jorge Vilela" <[EMAIL PROTECTED]> wrote: > Olá pessoal! Há tempos eu estou precisando implantar nos meus sistemas > uma > forma de salvar os dados do update. > > Hoje eu tenho os logs das ações (ex: Fulano insert na tabela tal) e > também > não excluo nenhum registro, apenas marco uma flag "deletado". Isso já me > ajuda bastante, porém no caso 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. > > Pensei no seguinte: > > Salvar numa tabela de logs o SQL gerado no UPDATE. > OU > Mover o registro para um schema separado, e então executar o update no > registro da tabela original. > > > *.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). > > > Qual das duas seria a melhor forma? Ou alguém conhece alguma opção mais > adequada? > > O assunto dá muito pano pra manga, por isso acabo discutindo, discutindo > e > nada... > > > > []'s > > Jorge Vilela. > > -- Nabucodonosor Coutinho Costa Desenvolvedor de Bugs
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
