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
