Se o servidor de produção for somente usado somente para consulta. Uma outra alternativa seria utilizar a replicação hot-standby+streaming replication do Postgresql 9.0.
Em 17 de novembro de 2010 01:07, Eden Cardim <[email protected]>escreveu: > >>>>> "Roberto" == Roberto Mello <[email protected]> writes: > > Roberto> A menos que seu banco de dados não tenha nenhuma chave > Roberto> estrangeira ou restrição, e se você não quiser dados > Roberto> repetidos, vai ter que usar um pouco mais de inteligência > Roberto> no seu processo se quiser fazer uma cópia incremental > Roberto> assim. Só com COPY direto não vai dar, a não ser que você > Roberto> apague tudo do de produção a cada nova rodada. > > Roberto> Provavelmente um programa que, sabendo dos nomes de todas > Roberto> as tabelas, e sabendo identificar os últimos registros, > Roberto> leiam e enviem para o de produção. > > Depende bastante da modelagem, se você fizer uma abordagem temporal, um > COPY serve. Uma forma simples para ilustrar o conceito é associar um > campo representando a data de criação de cada registro, a data passa a > fazer parte da chave primária e você passa a usar sempre usar INSERT > invés de UPDATE no banco de desenvolvimento. Para atualizar o banco de > produção, basta copiar todos os registros criados após a data da última > atualização do banco de produção, que você consegue obter com um > > SELECT max(data) FROM tabela_prod; > > Isso é claro, vai resultar numa explosão de registros e tabelas bastante > volumosas. Pra resolver isso, você pode particionar a tabela por data, > caso o espaço não seja problema. Outra alternativa é usar uma abordagem > de arquivo morto pra apagar os registros que não sejam os mais recentes > periodicamente, algo como: > > DELETE FROM tabela_prod > USING (SELECT MAX(data) AS data, > id > FROM tabela_prod > GROUP BY id) recent > WHERE tabela_prod.id = recent.id > AND tabela_prod.data != recent.data; > > Que deve rodar num tempo aceitável sem fazer lock nos registros mais > recentes. Claro que acrescentar um campo data em todas as tabelas tem > implicações de complexidade, a depender da modelagem. Pode ser que fique > complexo demais e valha a pena usar outra abordagem. > > -- > Eden Cardim Need help with your perl Catalyst or DBIx::Class > project? > Software Engineer http://www.shadowcat.co.uk/catalyst/ > Shadowcat Systems Ltd. Want a managed development or deployment > platform? > http://blog.edencardim.com http://www.shadowcat.co.uk/servers/ > > _______________________________________________ > 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
