Buenas pessoal, na minha humilde idéia e tendo como experiência
própria a questão sincronismo, hoje usamos soluções próprias na empresa,
claro, respeitando nossa estrutura de banco de dados e não algo genérico. Em
muitos de nossos clientes, mantivemos sim os bancos iguais. Ainda não
tivemos a coragem de ter um banco centralizado, pois acreditamos que não
possuimos infra pra isto, e também, os clientes, não querem pagar por um
serviço especializado, mesmo sendo empresas de porte grande. Pensar em um
banco localizado na web ou servidor em um local com acessos por vpns, ainda
ferem a performace dos sistemas, dando ao cliente algo lento e muitas vezes
duvidoso.
Em cada tabela nossa, criamos um identificador, juntando
informações que fisicamente fazem que o registro seja endereçado, ou seja os
movimentos de uma empresa vai para outra, mas, ficam dentro do banco/tabela
separada como se as empresas estivesse fisicamente no mesmo local. Algumas
tabelas, como cliente são unicas, os registros vão de um lado para o outro,
respeitando o estado a ser processado, insert ou update somente. Não foi uma
coisa dificil de fazer é mais complicado de se manter e lembrar que temos
que manter e criar as trigger cada vez que nova tabela é incluída no banco,
mas esta dando certo a muito tempo.
Marcos André G.A
Trabin Softwarre & Consulting
Em 9 de julho de 2010 10:09, Alexsandro Haag
<alexsandro.h...@gmail.com>escreveu:
> Sinceramente não vejo problema nas características informadas pelo
> Alexsander.
>
> On 08-07-2010 20:51, fabi...@wolaksistemas.com.br 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,<fabi...@wolaksistemas.com.br> 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
> >> pgbr-geral@listas.postgresql.org.br
> >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >>
> >>
> >
> > _______________________________________________
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
> >
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
