Mozart, concordo com você!!!Mas, como você mesmo, pode servir para alguem... No caso do Saulo, está na cara que trata-se de um caixa 2, e bla bla bla...
APARENTEMENTE!!!! digo APARENTEMENTE uma esquartejada de leve não vai trazer problemas.... Adriano 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 > 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
