Sinceramente não vejo problema nas características informadas pelo Alexsander.
On 08-07-2010 20:51, [email protected] wrote: > 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? > Vejo que a diferença é que há um ponto central, porém este é replicado para as pontas. Com isso se o ponto central estiver indisponível as pontas continuam funcionando. > "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. > Hoje os frameworks de persistência estão muito maduros e trazem produtividade, além de permitir uma boa independência de banco de dados. Pessoalmente defendo o seu uso, principalmente em grandes projetos, como ERPs, CRMs e afins. Mas acho perigoso tentar atender mais que 2 bancos. Acaba deixando tudo muito complexo de manter com o tempo. > "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. > > "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. > > Aqui concordo com o Fabiano, pois os bancos de dados já provém soluções para replicação. Alguns até mais de uma, como é o caso do Postgres. > "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. > Vejo que existe sim a necessidade de centralizar para então distribuir novamente às pontas, porém novamente, poderia optar por soluções padrão do próprio banco de dados. > > 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 > > > > >> 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. >> >> Em 8 de julho de 2010 17:15,<[email protected]> escreveu: >> >> >>> PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar >>> independente. O que me referi foi a forma que você implementou o >>> sistema. >>> >>> Att, >>> Fabiano Machado Dias >>> >>> >>> >>> >> -- >> 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 >> >> > > _______________________________________________ > 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
