Sou novo na área de TI, e estou criando um projeto de um Sistema OpenSource,
para empresas de TI

mas com esta discussão acabei ficando curioso com uma coisa...

como se comportaria a sincronização de um banco multi-empresa, caso a
Internet ficasse indisponível? (sendo que o banco das filiais filiais
replicam entre si, e entre a matriz)...?

*quais as melhores ferramentas/ metodologias, para gerenciar "esta
replicação dos dados?*



a questão da indisposição da Internet deve ser levada em conta durante a
criação de um sistema deste porte (multi-empresa), certo?

*então deve ser um requisito que o sistema (base de dados) "sozinho", volte
a sincronizar os dados atrasados, sem a necessidade de um DBA, certo?*






2008/12/11 Alisson Viegas | Acsiv Sistemas <[EMAIL PROTECTED]>

> No meu caso também não. Fica muito complicado.
> Mas a idéia de permissões por registros, como no Veil, é bem interessante.
> Alguém da lista está usando, para nos passar feedbacks?
>
>
> At.te,
> Alisson Viegas
> [EMAIL PROTECTED]
> ---
> Acsiv Sistemas
> www.acsiv.com.br
>
>
> -----Mensagem original-----
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Em nome de Mozart
> Hasse
> Enviada em: quinta-feira, 11 de dezembro de 2008 12:59
> Para: [email protected]
> Assunto: Re: [pgbr-geral] Banco Multiempresa
>
> Bases separadas?!
>
> Para brincar até dá, mas... e se o teu banco tiver mais 800 tabelas?? O que
> é que se faz com as 2000 chaves estrangeiras e os 4000 índices?! Cria em
> todas as bases de filiais ?! Lindo, e aí "é só" configurar alguns
> arquivinhos super triviais do SLONY para sincronizar as míseras 200 tabelas
> de uso comum a todas as filiais.
>
> Vamos pensar *médio*. E se você quiser tirar um relatório gerencial das 30
> filiais do mesmo *estado* ? (Brasil inteiro não, que eu propus pensar
> *médio*!) Quantos UNIONs você vai ter de fazer se a consulta de uma empresa
> só você já precisa de umas 8? Quanto tempo você acha que o planejador vai
> gastar só descobrindo se ele dá conta de rodar um comando desse tamanho?
>
> Agora o divertido mesmo vai ser atualizar a estrutura desse negócio. Que
> tal
> rodar o mesmo script ALTER TABLE nas 30 filiais? Acha que um scriptzinho
> criado via cut-paste ou macros mirabolantes para usar na linha de comando
> quebram teu galho?
>
> Bom, o interessante vai ser explicar para o cliente que ele vai precisar de
> um
> DBA toda a vez que quiser cadastrar uma filial nova. Fico imaginando quanto
> tempo o cliente vai gastar com DBAs só monitorando o SLONY para garantir
> que
> ele atualizou as tabelas comuns em todas essas bases e que todas as tabelas
> estão com a mesma estrutura. O legal mesmo vai ser alguém precisar rodar
> (ou
> precisar de algo equivalente) um UPDATE em todas as filiais de uma vez,
> dentro
> de uma só transação...
>
> Sinto muito, essa idéia de esquartejar bases até pode servir para alguém,
> mas no meu caso, na-na-ni-na-não.
>
> Mozart Hasse
>
>
>
> > Sobre o assunto, eu *não* misturaria dados de empresas distintas em uma
> mesma
> > tabela sem utilizar um controle de permissões a nível de registros (como
> os
> > descritos acima) porque seria fácil, senão trivial, conseguir dados
> indevidos.
> > Como alguns colegas sugeriram, eu optaria por utilizar esquemas para
> separar
> > empresas e utilizaria a nomenclatura nomedomodulo_nomedoobjeto para
> designar
> > os objetos (tabelas, funções, visões, etc).
> >
>
>
> _______________________________________________
> 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
>



-- 
Lucas de Souza D'Ávila
Graduando em Sistema de Informação - Escola Superior de Criciúma, ESUCRI
(localizada em Criciuma, SC)
CV Lattes: http://lattes.cnpq.br/9245658982061645
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a