Amigo, na ultima solucao do tipo que implementamos aqui isso a cargo da aplicação tambeém, pois estamos usando o rails nesse projeoit mais recenete e entao a logica que estaria no banco estah nos models
On Wed, 6 Jun 2007 13:39:26 -0400, "Jorge Vilela" <[EMAIL PROTECTED]> wrote: > 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 >> > > -- Nabucodonosor Coutinho Costa Desenvolvedor de Bugs
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
