2008/12/11 José Mello Júnior <[email protected]>
> Se a proposta sempre for para pensar na complexidade do sistema maior,
> teríamos de modelar muito grande para pouca utilização. Concordo contigo
> quanto a proposta de 800 tabelas e 4000 chaves estrangeiras, mas não devemos
> engessar o pensamento achando que a solução sempre será tão grande, sob pena
> de mensurar uma carreta para levar uma caixa de sapato a um destino
> qualquer. Veja que se a solução se apresentar com poucas tabelas, é possível
> sim, manter as informações em schemas separados e elaborar algumas views
> para acesso globalizado.
>
> []´s
>
> 2008/12/11 Mozart Hasse <[email protected]>
>
>> 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
>>
>
>
>
> --
> José de Mello Júnior
> 41.9957-2007
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
Srs.,
Nós temos um sistema que está divido assim:
1 Schema para dados do dicionário do programa;
1 Schema para dados comuns a todas as filiais;
1 Schema de dados para cada filial.
Temos cerca de 2000 tabelas com fk, triggers, roles, etc... Tudo
funciona muito bem e rápido. No login da aplicação configuramos o
search_path para schema_dicionario, schema_dados_comuns,
schema_filial_ativa.
As consolidações são feitas através de triggers no schema de dados
comuns a todas as filiais.
--
°v° Ricardo Gonçalves
/(_)\ Dpto de Sistemas
^ ^ Multcont Informática Ltda
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
