Vamos por partes. Em 8 de julho de 2010 20:51, <[email protected]> escreveu:
> Treços do teu email: > > "Há tabelas "globais" onde apenas um servidor pode gravar" - Se esse > servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a > aplicação em um data center, ou seja se você depende de um central não há > porque ter as "locais" afinal não vai funcionar sem as "globais" não é? Ou > entendi errado? > Você entendeu errado. Estas tabelas "globais" são replicadas normalmente, mas as filiais não têm permissão de escrita em suas cópias. São tabelas cuja manutenção é centralizada -- como por exemplo, "estado da federação". Se o Congresso criar um novo estado, digamos o "Pará do Sul (PS)", somente um usuário logado no servidor central (e devidamente autorizado) vai poder criar este registro. Esta tabela não tem uma coluna "id do servidor" como parte da chave primária, que no caso seria obviamente a sigla do estado, "PS". Se a empresa começar a aceitar pagamentos em tampinhas de garrafa, o registro "tampinha de garrafa" com sigla e chave primária "TPG" poderá ser criada apenas na central. > > "Meu ERP usa um framework de persistência" - Opção de cada desenvolver, eu > por experiência recomendo passar longe desse tipo de coisa. Tomara que não > acontece com você mas o dia que resolver dar pau, reze. > > Eu mesmo desenvolvi o framework de persistência, além de uma ferramenta de engenharia reversa e um gerador de código. O framework está bastante otimizado (afinal, o código tem mais de 5 anos de uso em produção) e os comandos gerados por ele foram bem depurados, não há pesquisas desnecessárias nem exigência de OID. Ele atende perfeitamente a imensa maioria dos casos, mas para aquelas situações onde um SQL feito à mão é melhor existe suporte a views e stored procedures. > "grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE" - > Já citado antes a questão da integridade, mas como você falou dependendo > do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista. > Hoje já temos infra suficiente para manter um link decente e se a desculpa > for a rede que pode cair, vide a NFe e o SPED. > > Ainda não vi no mercado links perfeitos. Por outro lado já vi um Centro de Distribuição ficar mais de 24h sem Internet porque os fios de cobre de todos os links foram roubados. Não vejo como um servidor centralizado pode ser melhor, não imagino explicar para o cliente que um processo vital como o recebimento de mercadorias em uma filial tem que ficar parado, deixando faltar produtos na prateleira, porque a rede está fora do ar. No caso da NFe é diferente: o seu BD está funcionando, seu processo continua, apenas o servidor da Fazenda que está indisponível. Imagine se cada vez que fosse preciso emitir uma NFe em contingência, toda a empresa do cliente parasse. Isso é o que acontece quando você roda aplicações vitais em data centers remotos. > "um processo que roda no CRON das lojas envia estes comandos para o > servidor central" - No meu ponto de vista não é uma solução elegante. > > Elegância é subjetiva. > "O servidor central, por sua vez, envia para todas as lojas todas as > atualizações que recebeu, também minuto a minuto." - Você centraliza, > distribui e centraliza novamente. Se o teu servidor precisa mandar as > atualização para as filiais porque não centraliza tudo de uma vez e deixa > só o PDV de fora. > > O objetivo é manter os servidores idênticos: poucos minutos depois do final do expediente, todos estão iguais. Além disso, uma filial pode querer saber onde tem alguma mercadoria: por exemplo, pode chegar um cliente pedindo uma coisa que está em falta naquela loja mas tem disponível em outra. > > São apenas ponderações baseado no email que você mandou, não estou dizendo > que está errado, apenas que pode ser melhor e mais confiável. > > Abraço, > Fabiano Machado Dias > > > Agradeço seus comentários. > > > Pode dar um exemplo dos "muitos pontos de falha" que você mencionou? Eu > já > > disse: não dá pra pensar que uma replicação multi-master vai estar com os > > dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma > > modificação feita numa filial pode levar 2 ou 3 minutos para chegar em > > outra. > > > -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
